Scrambled rendering with NotoSansTC-Regular.otf

[edouard-lopez]

related: #243, notofonts/noto-cjk#81
block: parlr/ruby-font-creator#29

I met rendering problems when using text-to-svg (shrhdk/text-to-svg#22, shrhdk/text-to-svg#23) with the NotoSansTC-Regular.otf.
Drilling down it appears text-to-svg is based on opentype.js.

Expected

This is for reference, I find that DroidSansFallbackFull.ttf worked fine.

key	value
font	DroidSansFallbackFull.ttf
text	㐅㐆丰wǔyǐnfēng

Actual (with NotoSans)

I tested on opentype.js online demo and the result is scramble too (see below):

key	value
font	NotoSansTC-Regular.otf
text	㐅㐆丰wǔyǐnfēng

[brawer]

The same font renders fine with FontView so this looks like a problem of OpenType.js.

[edouard-lopez]

Noto Serif has been released on April 2017 but still has the issue. From googlei18n/noto-cjk#81 the issue come from OpenType.js.

Could you give some feedback?

[brawer]

Same for Noto Serif — the font renders fine with FontView (which is just a GUI wrapper around HarfBuzz and FreeType), so this looks like a bug in OpenType.js. If someone figures out what exactly is triggering this bug, would you mind contributing a test font (with just 2 glyphs) to Unicode? If you send a pull request to Unicode’s text rendering test suite and accept Unicode’s contributor license agreement, I’ll gladly add a test case that uses your font. By doing this, you will help to make all OpenType implementations towards more compliant with the spec.

[fdb]

It seems the advanceWidth values are messed up. I'll try to figure out why.

[fdb]

It seems like this is a CID-keyed font, which we do not yet have support for. I'll see what I can do.

[brawer]

Indeed, OpenType.js runs into the same problem with this test font:

Instead, it should look like this.

[fdb]

We now parse CID-keyed fonts correctly!

The new version 0.7.0 includes the fix (with a big thanks to @tshinnic for the initial implementation).