What version of Go are you using (go version)?

$ go version
go version go1.15.3 linux/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

$ go env
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/zhou/.cache/go-build"
GOENV="/home/zhou/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/zhou/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/zhou/go"
GOPRIVATE=""
GOPROXY="https://goproxy.cn,direct"
GOROOT="/usr/lib64/go/1.15"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib64/go/1.15/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/zhou/test/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build508378831=/tmp/go-build -gno-record-gcc-switches"

What did you do?

https://play.golang.org/p/0_ESQiUzpHy

/usr/share/fonts/truetype/wqy-zenhei.ttc is "WenQuanYi Zen Hei", the primary Simplified Chinese font for many Linux distributions for many years before Noto Sans CJK. nowadays many distributions still provide it, and some of them still don't have Noto Sans CJK fonts and didn't switch their default SC font yet. BTW, fontconfig project set it as the default SC font for programs relying on it without tweak.

In one word, if you want to print something Chinese with golang/x/image/font infrastructure, "wqy-zenhei.ttc" may come to your mind definitely.

What did you expect to see?

nil error

What did you see instead?

sfnt: invalid table offset

I print the tag with:

func tag2string(u uint32) string {
  s := strconv.FormatUint(uint64(u), 16)
  decoded, _ := hex.DecodeString(s)
  return string(decoded)
}

And find a weird tag "BDF" and "FFTM" , after some research I found they are fontforge specific tables, and are non-standard extension for opentype specification.

https://fontforge.org/docs/techref/non-standard.html#non-standard-bdf

the offset for previous BDF tag is 956, the length is 845.
the offset for FFTM tag is 8659, the length is 28.

if o&3 != 0 || n&3 != 0 {
  fmt.Println(u32string(tag))
  fmt.Println(o)
  fmt.Println(n)
}
// We ignore the checksums, but "all tables must begin on four byte
// boundries [sic]".
/*if o&3 != 0 {
  return nil, 0, false, errInvalidTableOffset
}*/

tag: BDF 
offset: 956
length: 845
tag: cmap
offset: 1801
length: 6854
tag: cvt 
offset: 8655
length: 4
tag: FFTM
offset: 8659
length: 28
tag: gasp
offset: 8687
length: 16
tag: GDEF
offset: 8703
length: 32
tag: glyf
offset: 8735
length: 12302984
tag: GPOS
offset: 12311719
length: 32
tag: GSUB
offset: 12311751
length: 248
tag: head
offset: 12311999
length: 54
tag: hhea
offset: 12312053
length: 36
tag: hmtx
offset: 12312089
length: 179544
tag: loca
offset: 12491633
length: 180092
tag: maxp
offset: 12671725
length: 32
tag: name
offset: 12671757
length: 2467
tag: OS/2
offset: 12674224
length: 86
tag: post
offset: 12674310
length: 451503
tag: vhea
offset: 13125813
length: 36
tag: vmtx
offset: 13125849
length: 179326

because BDF table contains a string table, which is raw ASCII bytes. so it is hard to controll the 4 byte boundaries.
but seems fontforge do the byte alignment by itself as a whole.

so, I think, as many old "bimap embedded" trutype fonts exist, can we skip this boundary check? simple comment it out saves wqy-zenhei.ttc