Strange fonts height in GNU/Linux

[s8321414]

My environment: Chakra GNU/Linux using KDE Using Source Han Sans OTC 1.004 (Source Han Sans TC variant) It's screenshot: But for 1.002 (Source Han Sans TC): I think something is wrong between 1.002 and 1.003, can you figure it out and fix it?

[zerng07]

Is that a problem of the font, or the problem of the rendering engine?

It should be cleared out first. Needs some investigation though.

[s8321414]

@zerng07 I just downgrade otc-source-han-sans from 1.004 to 1.002. And all fine here. I don't do any other changes on my PC, so it should be font issue. Qt and Gtk toolkit apps both have the same issue, so it should not be toolkit issue.

[s8321414]

@felixonmars How do you think about this issue?

[kenlunde]

Font vertical metrics requirements—or, perhaps more accurately, assumptions—are clearly different for UIs in that a much tighter line spacing is necessary or expected.

Ignoring the harmonization across all seven weights that was done in Version 1.003 and carried forward in Version 1.004, the Version 1.002 fonts effectively had two sets of vertical metrics, and it seems that which set was used depends on the client. One set was those specified by OS/2.sTypoAscender and OS/2.sTypoDescender, which specified a 1000-unit em-box by using values of 880 and -120, respectively. These same values were also reflected in the hhea.Ascender (880) and hhea.Descender (-120) fields (this is default AFDKO makeotf behavior). The other set was those specified by OS/2.usWinAscent and OS/2.usWinDescent, which was calculated by first removing excessively tall vertical-use glyphs from the calculation (but not yet harmonized across all weights).

For the Version 1.003 fonts, the hhea.Ascender and hhea.Descender values were simply overridden to match the OS/2.usWinAscent and OS/2.usWinDescent values (and harmonized across all weights). This is the same practice that is employed for the other Source families (Source Sans Pro, Source Serif Pro, and Source Code Pro), and results in much more consistent cross-platform vertical metrics for general use.

UI use is a whole new beast, and has very unique requirements, which is why most fonts that are intended for UI use special values that result in the desired effect, or the layout engine of the UI is intelligent enough to do the right thing. In my opinion, The Right Thing™ for UIs is to use the OS/2.sTypoAscender and OS/2.sTypoDescender values, ignore the OS/2.sTypoLineGap value, and pick a very modest values, say 200, for the line gap.

In summary, a single set of vertical metrics settings cannot possibly satisfy all possible usage scenarios, especially those for UIs that require very tight inter-line spacing, so this is either a DIY (Do It Yourself) project, or use a derivative project, such as @ShikiSuen's OriginHanSansUI, for your purposes. Also, because general use far outweighs UI use, I am flagging this As Designed.

[ShikiSuen]

I have to explain something:

1. Due to bad access stability between GitHub and myself while I am in PRC, I migrated my OriginHanSansUI into https://originhansansui.codeplex.com/ , which reflects all changes @kenlunde asked me regarding 'Source' trademark. These changes will not apply onto its GitHub repo until this late August.
2. Origin Han Sans UI is absolutely not a choice for GNU Linux's GUI fonts. You have to fork something for your own. I initially let Origin Han Sans use (HHEA: Asc=1000, Desc=-234) in all 7 weights, but that would cause problem like https://github.com/adobe-fonts/source-han-sans/issues/102 . Thus, in the most-recent update "Aiza Nagi" (commited just now at its CodePlex website), I apply SHS's factorial (HHEA: Asc=1160, Desc=-320) metrics onto Origin Han Sans UI's Heavy and Bold weight. This MUST cause troubles like @s8321414 encountered & shown in his screenshots.

P.S.: I will appreciate it if @kenlunde could tell me the minimum compatible metric sets of HHEA Ascender & Descender for SHS only.

[ShikiSuen]

One more thing: I don't know whether GNU Linux could handle the lineGap metrics, but I at least know OS X couldn't handle it correctly in most cases. Just want to let myself not to be misunderstood.

[zerng07]

No problems with GNOME desktop with 1.004R. KDE-only problem doubted.

[zerng07]

Though the line gap does change, but there is no problem with rendering as an UI font with GNOME.

[ShikiSuen]

Thanks, then that might be KDE's problem.

[zerng07]

By the way, the new line gap in 1.004R looks better than 1.002R in gedit (a text editor in GNOME). The line gap in 1.002R is too close to read in gedit, and the new line gap works very well!

[ShikiSuen]

That's not line-gap-determined enhancement, please read Adobe official update description thoroughly.

[zerng07]

I mean the displaying result as referred to the line gap.

[ShikiSuen]

@zerng07 You said:

By the way, the new line gap in 1.004R looks better than 1.002R in gedit (a text editor in GNOME). The line gap in 1.002R is too close to read in gedit, and the new line gap works very well!

Based on what Adobe claimed among their official SHS update histories:

• 1.002R use linegap=0 in both HHEA and OS/2 tables;
• 1.003R change Ascender & Descender in HHEA table from [880, -120] to [1160, -320];
• 1.004R only fixed some glyph problems regarding Japanese version of SHS 1.002R & 1.003R.

Even though you are talking about the display result, you still should use "the gap between lines" (not the terminology "lineGap") to avoid misleading your possible readers.

You make comparison between 1.002R and 1.004 (regarding their display effect in gedit), but their lineGap metrics are all zero. You should realize that it's because of the update made in 1.003R (as what I mentioned above).

[ShikiSuen]

Key translation regarding my last reply:

1. 是說 LineGap 一詞乃術語。
2. 您說「思源黑體 1.004R 相對 1.002R 而言，在 gedit 當中的行間距更舒服」，這是因為 1.003R 在 HHEA 表當中啟用了全新的 Ascender & Descender 數值所致（注意我在這裡只說了 HHEA 表，1.003R 對該參數組的修改僅限 HHEA 表當中）。
3. 1.004R 僅包含了對日文版思源黑體的縱排假名 Glyph 修正（該問題始於 SHS 1.002R，沒能在 1.003R 當中得到修正）。

[zerng07]

Hi, I know the difference between 1.003R and 1.004R, so there is no difference here. I also follow the issues here, so I know what had happened.

And sorry for the terms misleading here, I apologize for that. I was just trying to convey that the result is even better with the new metrics in GNOME. And that's all.

[ShikiSuen]

to @zerng07 >

The fact you claimed could be a good reference to Ken Lunde, so that he could still insist on thinking of "It's still because of reading wrong metrics from the target font".

It's time to send a bug report to KDE team to let them take a look at this thread.

[kenlunde]

One of the advantages of Source Han Sans is that it pushes the limits in a variety of ways, in terms of the number of glyphs (at the architectural limit), broader coverage of Unicode, broader coverage of vertical glyphs, and so on. The result is that poor assumptions are being exposed. Conventional fonts may also expose such poor assumptions, but in more subtle ways, meaning that they are more difficult to notice.

The excessively tall vertical glyphs in Source Han Sans, in particular, are very useful in exposing environments that use the FontBBox (as expressed by head.xMin, head.yMin, head.xMax, and head.yMax) for line-layout purposes, which is a huge no-no. These are U+2E3A, U+3E3B, U+3031, and U+3032.

The Latin glyphs for Vietnamese, which use multiple accents, are primarily the reason for the ascender values.

[s8321414]

hmmm, so it shoule be KDE or Qt specific bug, should report it to their bugtracker.

[ryuanlu]

This is my screenshot. I have no idea if it's the same problem or not.

fontconfig is configured to use Liberation Sans for Latin and Source Han Sans for CJK.

[ShikiSuen]

@ryuanlu If you are using GNOME, you met another issue. If you are using KDE, probably you met the same issue.

[zerng07]

@ryuanlu What version of Source Han Sans you use? And how do you set the fontconfig configuration? What is your Audatious version? There is a Qt version of Audatious now, are you using it?

I don't think this is much related to Source Han Sans. You'd better report to Audatious instead.

[ryuanlu]

@ShikiSuen Yes, I'm using GNOME 3.14 (Debian Jessie)

@zerng07 1.004R

/etc/fonts/local.conf https://gist.github.com/ryuanlu/2c90dfdf554215f6257c

Audacious 3.5 by Debian, not Qt build. Not only audacious, but also gnome-shell (clutter), steam.

Maybe it's related to pango ?

[zerng07]

It seems that you don't have the font height cutting problem in the second screenshot.

I don't see any problem in the second screenshot, could you please just point out? What have you done between these two screenshots?

Note: You have specified Liberation Sans before Source Han Sans for Sans, and please remember that Liberation Sans doesn't share the same metrics with Source Han Sans.

[ryuanlu]

In the first screenshot, I set font size to 16 to emphasize the difference. In the second screentshot, font size is reset to 10.

In some cases, CJK glyphs are a bit lower than Latin ones.

[zerng07]

Yeah, remember that according to your fontconfig configuration your Latin ones are set to Liberation Sans.

The problem might be caused by that the app is using the matrix from Liberation Sans to display the box, and Source Han Sans is using another different matrix. That's what your binding configuration section asks fontconfig to do.

I suggest you using Source Han Sans directly and removing all the bindings to see if it fixes your problem.

[ryuanlu]

Ok, just curious why most cases are not effected.

[zerng07]

What cases are not infected?

Some programs such as the ones written in Qt will only pick the most preferred font in your fontconfig conf according to its internal rule, and neglecting those binding sections and fallback sections. They only use one font for UI, so you won't see the CJK glyphs a bit lower than Latin ones.

[ryuanlu]

VLC works with my fontconfig conf (Liberation Sans + SHS TW)

[zerng07]

What do you mean "VLC works"? I guess you have the same problem with "700 個區塊".

Qt might fix something relating to fontconfig that it may result like GTK does. Anyway, using Source Han Sans for sans-serif directly and removing the binding section might save you from this problem and you can try.

The last but not the least, I still don't think there is much to do with Source Han Sans in this case.

[ShikiSuen]

@ryuanlu This is not fine. At least I could see terrible issue of misaligned horizontal-axis among fallbacked glyphs and unfallbacked glyphs. I met this issue by using both Gnome / Cinnamon with default western font "Source Sans Pro" and its fallbacked font "Source Han Sans TC", this issue still exists. The font layout engine in Linux at this moment is extremely ridiculous since Source Han Sans and Source Sans Pro share the same metrics (refer to what @kenlunde claimed in the release notes of SHS 1.004).

(I tried both Fedora 23 and Ubuntu 15, recent stable builds.)

[ShikiSuen]

@kenlunde Would it be a good idea to suggest Fedora development team to use Source Sans Pro as their default UI font? This could probably make them realize the issue of their layout engine regarding misaligned horizontal-axis, while they are currently using Source Han Sans regional subsets for Chinese UI fonts as default in Fedora (I know nothing about Red Hat Enterprise Builds).

[ShikiSuen]

One more thing, the screenshot attached in the 1st post proved that KDE (Is that KDE Plasma 5?) also has the issue of its layout engine regarding misaligned horizontal-axis. (See the upper-right date and time elements, they are not aligned horizontally. Note that this is definitely not a matter of font size.)

[s8321414]

@ShikiSuen no... it's KDE4

[ShikiSuen]

@s8321414 Would it be convenient for you to test KDE Plasma 5? (It may not necessary if KDE use the same font rendering solution (Pango) as what GNOME 3 used) Thanks.

[s8321414]

@ShikiSuen OK I may do it later.

[s8321414]

1.002 on KDE Plasma 5: 1.004 on KDE Plasma 5:

[s8321414]

hmmm... So it should be freetype issue.

[kenlunde]

If it is an alignment issue, I don't see how it can be a FreeType issue, but rather it's more likely to be a layout engine issue in the app or in a library.

[ShikiSuen]

@kenlunde I prefer to think that it's an issue of a shared library since I saw such issue in different apps and shell solutions (incl. Cinnamon desktop).

[ShikiSuen]

@s8321414 Note that the align issue may not be able to show up since you let Source Han Sans be default western UI font in its highest priority. (i.e. The current western font is Source Han Sans, no kanji fallback triggered)

[ShikiSuen]

@s8321414 Could you please tell me that which version of Source Han Sans are you using in your screenshot of KDE Plasma 5? Thanks.

[s8321414]

@ShikiSuen Both are on Plasma 5.5.5 in latest Chakra GNU/Linux, I have the same issue on BBSFox in Firefox on Windows...

[ShikiSuen]

@s8321414 Thanks for your screenshot. After comparison to each other, I am still wondering whether you have initial issue in KDE Plasma 5.5.5 with SHS 1.004. Looks like some layout method towards date & time gadgets are changed in KDE 5.

[s8321414]

I don't know, but it's really weird...

[ShikiSuen]

Ubuntu 16.04 LTS adopts Noto Sans CJK as default CJK UI font. In such case, any font layout error SHALL be appealed to the font layout engine used.

[kenlunde]

@ShikiSuen: Thank you. I appreciate the heads up.

[s8321414]

Well, this still happened in 5.14 series... I have no idea if SHS 2.000 resolves this issue.

[s8321414]

@ShikiSuen BTW, where is your Origin Han Sans UI repo now?

[kenlunde]

@s8321414 As this is clearly not a font issue, the Version 2.000 fonts are unlikely to resolve this.

[ShikiSuen]

@s8321414

This project (origin han sans) is temporarily dead.

In these years I gave up waiting for SHS (also due to my satisfaction with PingFang family) and was focusing on my school studies. Now I graduated as a Bachelor of Music and is busy studying Nihongo to fit my needs of further-studying music in Japan in the next two years.

If you have interests in it, you can copy the changed parameters in the hhea table and apply it into Source Han Sans 2.0 builds. Remember, you have to change the font name before distributing your modified fonts (I forgot the reason but I guess Dr. Lunde can explain).