Updated glyphspackage and build system

[aaronbell]

Thanks again for uploading the .glyphspackage source. I've gone through and edited the source file as necessary to resolve a number of fontbakery items as well as issues that were causing the build to fail.

Changelist (partially copied from #46):

• Updated the smart components to follow a simpler model with extremes in the designspace (tall wide, short wide, tall narrow, short narrow) and re-implemented _part.thread and _part.thread2alt (replacing _part.thread2) in all glyphs where the smart component was used. There may be some slight differences, but should look pretty close to the original.
• Added a Iansui-build.glyphspackage file as, unfortunately, fontmake cannot fully support corner components and cap components so the source needs to be decomposed before it can be built on the server. Hopefully as the technology improves, this limitation can be removed.
• I made corrections to various glyphs that had improperly-placed beziers or contour order causing loops, overlaps and other problems. Some glyphs appear to only get these problems due to the decomposition of the cap components, though, and I am not familiar enough with that system to resolve them. FB is only returning a WARN though, so I think it can be left alone.
• Updated metadata in the fontinfo panel as well as elsewhere (like the OFL) to follow conventions for GF.
• Removed filters from the fontinfo panel as they were confusing ufolib. Irritatingly, even if something is not "active" in Glyphs, it can still be read and processed by the fontmake toolchain, so best to remove it if not necessary.
• Set a number of unreachable glyphs to "non-exporting". These are glyphs that do not have an assigned unicode slot, nor can be accessed via OT features. As they will not be usable in most scenarios, they only serve to bloat the file size, and thus can be removed. These are marked in black in the source.
• Set "soft hyphen" to "non-exporting" per GF recommendation
• Removed the "documentation" folder I added previously, and associated code from the makefile as unnecessary.

I tried to break up the changes into meaningful commit chunks—removal of old files, smart component fixes and new build system, then FB-related fixes, etc. so it would be easier for you to step through the changes and see what's different, but if you have any questions or there's anything you don't like, please don't hesitate to ask! I'm happy to discuss.

[aaronbell]

As a separate issue, would you be open to consider updating the metrics on Iansui to follow the guidelines of the discussion from here?

For Iansui, this would mean:

Field	value
sTypoAscent	960
sTypoDescent	-200
usWinAscent	1160
usWinDescent	288
hhea.ascent	960
hhea.descent	-200
USE_TYPO_METRICS	Enabled

I've used the values that you'd entered in the hhea ascent/descent in the source as the guide for this, but if you want to make sure than Pinyin is fully covered, you might want to consider 1048 / -175 instead. That would cover the top of the Ǘ as well as the depth of the g, though it doesn't encapsulate the rarer Hanyu Pinyin patterns like Ecircumflex_caroncomb. Thoughts?

[ButTaiwan]

As a separate issue, would you be open to consider updating the metrics on Iansui to follow the guidelines of the discussion from here?

For Iansui, this would mean:

Field value
sTypoAscent 960
sTypoDescent -200
usWinAscent 1160
usWinDescent 288
hhea.ascent 960
hhea.descent -200
USE_TYPO_METRICS Enabled
I've used the values that you'd entered in the hhea ascent/descent in the source as the guide for this, but if you want to make sure than Pinyin is fully covered, you might want to consider 1048 / -175 instead. That would cover the top of the Ǘ as well as the depth of the g, though it doesn't encapsulate the rarer Hanyu Pinyin patterns like Ecircumflex_caroncomb. Thoughts?

Since Iansui's glyphs is based on Ministry of Education Taiwan, lots of users of Iansui are teachers, and they always use Microsoft Word.
So, I want to keep the default line height as one-line height in Word.
(WinDescent > 200 will get two-line hegiht result in default settings when the text is 12px.)
I need to test in Windows + Microsoft Word more, and decide the metrics.

PS.
We also need to care of the vertical layout issue when decide the metric values.
My original values 960 / -200 was defined as (880 + 80) / (-120 - 80), where the offset both ascender and descender are 80.
That is because the sideway glyphs in vertical text are align to the center of horizontal axis.

Like this sample:

If I set values as 1040 / -180, the text will be displayed as:

where half-width characters and some sideway symbols are not aligned to the center.

So I know the ascender value 960 is not enough for some Pinyin symbols.
However, if I set ascender value to 1040, the descender value need to be set as -280 to make glyphs align in vertical text correctly.
But the line height will be to large in Microsoft Word.

[aaronbell]

Yeah, this was a bit of a concern of mine wherein not setting the vertical metrics related to the emBox could result in odd behavior. It might be that the USE_TYPO_METRICS flag could solve this problem since you'd be able to preserve the 960 / -200 values but allow the clipping values to be larger to enable Pinyin support.

Definitely want to test to ensure that it works as intended, but if the primary use case is MS Word, then the USE_TYPO_METRICS flag should do the job. I can provide you with a test file if that'd be useful.

[ButTaiwan]

I tested some values.
It looks like USE_TYPO_METRICS flag works in MS Word (in Windows).
But sTypo 960/-200 will get 2-line height space, values 940/-180 worked.

And the vertical alignment will also take sTypo values. That's good.

Currently the best values are...

Field	value
sTypoAscent	940
sTypoDescent	-180
usWinAscent	1060
usWinDescent	200
hhea.ascent	940
hhea.descent	-180
USE_TYPO_METRICS	Enabled

[aaronbell]

Excellent! The only suggestion I would make is to increase the usWin metrics to 1066/273 which will make sure to cover the full range of the font's yMin / yMax values. I don't think that should have any impact on the way it is rendering in Word.

[aaronbell]

I've updated the font metrics per your recommendation. Also fixed another minor issue (set overline glyph to be spacing rather than non-spacing)

[davelab6]

Thanks @ButTaiwan :)

[ButTaiwan]

@aaronbell @davelab6
Iansui is tagged as Traditional Chinese (Hong Kong) now. Please change to Traditional Chinese (Taiwan) in next update.
Thank you.

The default sample text is Cantonese:

It's categorized as 香港中文 is Google Doc:

[aaronbell]

Thanks @ButTaiwan. We noticed that yesterday and are investigating.

cc, @chrissimpkins

[ButTaiwan]

@aaronbell

It looks like lots of accent letters and Hanzi can not be displayed correctly with web font.

https://codepen.io/Ki-n-tiong-T-n/full/ogNwWoV

These are important characters for Taiwanese language text.
https://en.wikipedia.org/wiki/T%C3%A2i-u%C3%A2n_L%C3%B4-m%C3%A1-j%C4%AB_Phing-im_Hong-%C3%A0n
https://en.wikipedia.org/wiki/Pe%CC%8Dh-%C5%8De-j%C4%AB
https://en.wikipedia.org/wiki/Written_Hokkien#Chinese_characters

Google Doc supports better, but ó͘ and ò͘ are shown as zero-width in Google Doc.

[aaronbell]

@ButTaiwan Oh boy. It looks like there's a host of odd issues going on.

1. The accent letters are driven by the ccmp feature which should be enabled by default. But per this page it appears that it doesn't always get turned on in web browsers. That's pretty irritating! Using mark and mk2k are more reliable I think, so a solution for these would be to implement anchors into the relevant diacritics and base glyphs to ensure that everything is positioned as it should be. If you're not familiar with that process, I can assist with it.

I'm also seeing some of the substituted glyphs receiving a zero width, which is super weird, while others are not. All I can guess is that there is a misunderstanding of the glyph by the build system and it is thinking that that glyph is a combining diacritic rather than a glyph with advance width. No idea why it happens on some of them but not others. But hopefully the anchor system I discuss above will solve both these problems.

2. The Hokkien glyphs are definitely in the font, so there must be a subsetting problem going on that is causing them to not be rendered. I see the same issue on the Google Fonts website. The GF team will need to investigate. I'll file a bug for it.

[ButTaiwan]

@aaronbell

Thanks for your reply.
But I think the accent letters problem is also a subsetting problem.

https://codepen.io/ButTaiwan/pen/YPzQBQg

There shows that the glyphs of U+0301, U+0300, U+0302 and U+0304 can be displayed, and ccmp feature also works correctly.
But the glyphs of U+030C, U+030D, U+0306 and U+0358 are missing. So their accent letters certainly can not work.

PS. When I use a full Iansui ttf file as web font, it works well. So it seems that ccmp works by default.

--

Due to a historical reason, there're usually 3 possible series in POJ's "o͘".
For a sample, ó͘ can be wrote as o U+0358 U+0301, o U+0301 U+0358 and ó(U+00F3) U+0358. (Different IMEs outputs different series.)
They're Unicode equivalence, some great applications like Chrome can display them correctly even if there is only one series defined in the font file.
Unfortunately, many software do not process Unicode equivalence well. I always need to support all three series for MS Word.
That is easy be implemented by ccmp, but very difficult by mark and mk2k.

[aaronbell]

Thanks @ButTaiwan! I definitely still think that adding the marks would help ensure that these things render properly in the absence of ccmp, but I'll make sure these codepoints are part of the subset.

On the mark btw, it looks like the main issue was the lack of a topright anchor on the dot and the base O / o. I've added those locally. Will see if it sorts the advanced width issue.