Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/image/font/sfnt: not all tables begin with four byte boundries #46384

Open
marguerite opened this issue May 26, 2021 · 4 comments
Open

x/image/font/sfnt: not all tables begin with four byte boundries #46384

marguerite opened this issue May 26, 2021 · 4 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@marguerite
Copy link

marguerite commented May 26, 2021

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 Output
$ 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

@gopherbot gopherbot added this to the Unreleased milestone May 26, 2021
@seankhliao seankhliao changed the title x/image/font/sfnt not all tables begin with four byte boundries x/image/font/sfnt: not all tables begin with four byte boundries May 26, 2021
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label May 26, 2021
@seankhliao
Copy link
Member

cc @nigeltao

@marguerite
Copy link
Author

If anybody likes I can help implementing the parseBDF and parseFFTM functions, but I think they’re useless for truetype rendering and no one cares them...so it’s enough if we unlimit the table boundary check

@nigeltao
Copy link
Contributor

I don't think we need parseBDF or parseFFTM functions, but https://docs.microsoft.com/en-us/typography/opentype/spec/otff clearly says "All tables must begin on four-byte boundaries".

Two questions:

  1. Do you know if wqy-zenhei.ttc is usable on Microsoft Windows?
  2. Do you know where in the C freetype code they enforce (or don't enforce) four-byte boundaries?

@marguerite
Copy link
Author

marguerite commented May 28, 2021

@nigeltao

  1. Sure wqy-zenhei supports Windows...but due to the popularity of simsum.ttc( which I doubt has the same problem since it’s also a bimap embedded truetype), it’s hard to see it installed
  2. These C codes do the table identification job in freetype2:

https://github.com/aseprite/freetype2/blob/master/src/sfnt/sfobjs.c#L451-L469

I even see the same “o&3” check like yours. but they apply such check on the whole font, not individual table

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Development

No branches or pull requests

4 participants