IBM
IBM Plex Sans JP is bigger than other Plex Sans fonts
IBM Plex Sans JP slightly bigger(or not hinted properly?) than other fonts.
All texts are styled with font-size: 20px;
fonts used in image above are:
- hinted truetype IBM Plex Sans JP
- hinted truetype IBM Plex Sans KR
- truetype IBM Plex Sans
- hinted truetype IBM Plex Sans Arabic
- hinted truetype IBM Plex Sans Hebrew
- hinted truetype IBM Plex Sans Devanagari
This is intentional – all Latin glyphs in Plex Sans JP have been scaled to 105% to mix better with the Japanese character set.
@BoldMonday that's really not ideal; makes it much harder to work with bilingual content. KR and JP glyphs should be the same size... do you have examples of other fonts such as Noto doing this?
@johnnyshields I cannot comment on any specifics since we did not make the decision. The scaling was proposed by the Plex Sans JP designers at Sandoll. I assume they considered mixing Hangul with Japanese but I leave this up to them to answer.
Oddly enough Noto Sans CJK JP (and other CJK) appears to use different alphabet glyphs but they aren't significantly larger.
Noto CJK does also have a larger line height, which is identical between Noto JP and KR.
Based on this I would suggest:
- Use same size alphabet glyphs in all fonts. (If you absolutely must make Plex JP larger, then Plex KR should be too.)
- Use identical line height for JP / KR / SC / TC. (Plex KR seems to have slightly taller line height than JP)
This may all seem pedantic but it's this attention to detail which led us to use Plex in the first place.
Sorry, closed by mistake.
Use same size alphabet glyphs in all fonts.
I agree. It's difficult to use fonts with partially different glyph sizes.
How about a merged font option like Noto sans CJK?
The Latin glyphs in Noto Sans CJK are from Source Sans, they’re also larger than the original Source Sans.
How about an merged font option like Noto sans CJK?
Will raise this as a separate ticket
This may all seem pedantic but it's this attention to detail which led us to use Plex in the first place.
@johnnyshields But this very matter is all about attention to detail. The Plex project team looked at multiple tests of Japanese mixed with Latin, where the latter was scaled in different percentages. The team wanted to guarantee that all glyphs contained in Plex Sans JP were perfectly proportioned with each other. Several scenarios were considered including change of UPM, and vertical proportions of Japanese glyphs.
The decision to scale all Latin glyphs was not taken light-heartly and it took significant effort to check and correct all outlines that had rounding errors after scaling. All these glyphs were then hinted again as well. It was the main reason why the release of the JP fonts were delayed.
It was the main reason why the release of the JP fonts were delayed
🤦 This is really unfortunate there was not more community consultation. We had no idea why there was a delay and I get the sense that if this was put to a vote among actual JP users very few would want alphabet to be 105% scaled.
@BoldMonday I'd like to make sure we're not talking cross purposes. Japanese charsets do include full-width (全角) alphabet chars:
Normal: ABCDEFG
Full-Width: ＡＢＣＤＥＦＧ
Is it possible Sandoll commented to 105% scale these chars specifically?
@johnnyshields No there is no mix-up. Sandoll made all proofs and modifications to the Latin glyphs themselves. Here is an example how the project team tested Latin with Japanese:
As you can see vertical typesetting was considered as well.
Therein lies another problem. Alphabet characters are typically written upright when Japanese is written vertically, for example the Nikkei newspaper or magazines. Although both ways are possible, upright alphabet feels more common.
That is not a problem – instead it is a typographical refinement that Plex is offering and it does not rule out upright setting of Latin characters. The fact that the latter might be more common can be due to technical constraints in the typesetting environment, or in the fonts themselves.
Great! I've been checking magazines around my house and longer words do tend to be written sideways. So it's likely that "IBM", "2021", etc would be upright but "OpenPOWER Foundation" would be sideways in the same publication. FYI.
@johnnyshields Some comments:
From Adobe Source Han/Google Noto CJK:
The Latin, Latin-like, Greek, and Cyrillic glyphs in Source Han Sans are based on Source Sans Pro, but have been adapted for use in Source Han Sans, which mainly involved scaling. In the case of the Normal and Bold weights, the Source Sans Pro glyphs were scaled to 113% and 115%, respectively. ... The long answer is that the Latin and Latin-like glyphs in a CJK font represent a minority, and when it comes to harmonizing glyphs, the minority are modified to better harmonize with the majority, and not vice versa. Source
As Sandoll have been involved in the making of Adobe Source Han/Google Noto CJK, I would believe they had already noticed this issue and scaling the Latin glyphs is an appropriate action.
@NightFurySL2001
- If we're going to scale, shouldn't the alpha glyphs be scaled in IBM Plex Sans KR as well then? Presumably a KR hangul glyph should be the same bounding box as a kanji/hanja glyph. How about SC / TC?
- I can see the argument for 115% scaling on Source Sans Han, but 105% seems so close to 100% (no scale) it really feels that its not worth the extra time/effort or the break in consistency. As an web implementer dealing primarily in Japanese, English, and other CJK I now have to be thinking about two different font scales depending on the language.
I'm really curious what alternatives were discussed here. I know the team has put in a ton of work and my comments are not meant to disparage. I'm just surprised and considering how long we've waited it would have been good to get some color in advance on this.
- That is true, however KR doesn't have hanja and thus hangul glyphs did not have a relative alignment with hanja glyphs; instead the hangul glyphs are directly designed with respect to Latin glphs (notice the width of hangul in IBM Plex Sans KR is 892 while Source Han Sans K has 920; both have the same UPM value).
- A few other articles from Adobe mentioned about scaling Latin parts anywhere from 105% to 119% (https://ccjktype.fonts.adobe.com/2016/10/a-new-face-for-adobe-redux.html), and also IBM Plex had a large ascender/descender ratio to begin with and thus doesn't need as big of a scaling compared to Source Sans Pro.
There is also some techinal limitations considering the nature of han characters (hanzi/kanji/hanja) which takes up the whole bounding box from ascender to descender. Scaling down han characters to match Latin characters is not suggestable as it will break the font when typesetting vertically: most software by default take the ascender-descender range as the default vertical height range, if vmtx table is present then the value will be taken starting from ascender height. The height value by default is equal to UPM of the font, changing it will require vast changes to vmtx table when not all softwares support vmtx. (Reference) The other way would be to modify the UPM value but this is probably not suggestable too.
My point is, I think the scaling glyphs is the right action to do in IBM Plex Sans JP. KR version could be scaled up if cross CJK is required; however it is ok to remain the current scale for KR if no hanja is planned to be added.
@johnnyshields Sandoll encouraged this scaled increase and as you probably know they have designed and implemented many CJK fonts into the world. The 110% increase just seemed too large and 100% was indeed too small as a relationship in JP. We all agreed that the 105% was a good choice. The scale relationships between KR and Latin were more aligned and felt comfortable so the need to scale was never a deep discussion and also over a year in advance to the discussion for JP scaling. It was discussed early on in KR development that JO would likely need to be scaled up as that was a typical move to make. When the time came we opted for 105%. It makes a pretty significant difference even though 105% does not seem like it would.
Agree with @NightFurySL2001. The KR did not need scaling so we did not do it. JO does require scaling so we did it. Although minimal, it makes just enough difference.
JP's alphabet glyphs are bigger because 105% alphabet glyphs looks good with kana and kanji. I see.
What I want to know is: What size should I use when I use JP and KR fonts together?
- 100% alphabets look good with JP
- 105% alphabets look good with KR
Then what % of hangul look good with JP? Should I set KR 105% and JP 100%, or 100% : 100%?
Also worth noting Adobe is scaling by different % for different weight. Looking at this proof I can see why they did it... thin alphabet somehow feels larger relative to the others.
@plastic041 Using KR and JP together at 100% each will work. Sandoll also looked at those relationships as well.
Our design and development support for IBM Plex KR and JP is Sandoll. They are experts at CJK and have helped Apple, Google, Adobe and many international enterprises to development bespoke CJK typefaces. I have asked some of the designers to chime in on some of these issues as I think they can provide greater insight on the details and strategies they recommended for Plex CJK. http://www.sandoll.co.kr/works.html
Just a little note: even though the scale between JP and KR works, I think the baseline is slightly lower for KR compared to JP. From the font files, KR had an ascending value of 780 and descending value of -220, while JP had an ascending value of 880 and descending value of -120. The values for JP is normal for CJK fonts (and mainly the reason why scaling the Latin part is required) and I would guess the values for KR is reasonable for hangul fonts with no hanja. However, mixing both together would make KR looks slightly sunk than JP.
Line height and Baseline is affected by hhea table(ascender/descender/linegap), win table(ascender/descender), and stypo table(ascender/descender/linegap). In KR, win, hhea table (ascender/descender) is generally set as an area where glyphs will not be cut. while JP's win and hhea table are set according to the operating system of OTF and TTF. OTF is based on Adobe's basis font, Kozuka, because it generally postulates and sets figures for use in Adobe programs. Line height difference occurs because this value is different from KR. Priority consideration in IBM Plex KR and JP was based on individual usability in each language. However, as suggested in #388, We think line height and baseline should be provided with the same value if considering the environment where CJK characters are used together as the top priority. We will discuss this issue with IBM and BoldMonday.
Some things i think is confusing from sandoll's reply:
stypo table(ascender/descender/linegap)
Should be OS/2 table with stypo prefix (ascender/descender/linegap).
However, as suggested in #388
Should be https://github.com/IBM/plex/issues/392.
I was asked by @davelab6 to review the Plex Sans JP font in preparing to onboard it to Google Fonts and I would like to join @johnnyshields, @plastic041, and others in voicing concern about this issue.
As discussed in this thread, it is not uncommon for Latins to be modified to better fit with CJK ideographs and syllables—Adobe did it with the Source Han Sans fonts. However, they did so consistently across all of the CJK fonts as they share the same em-square height, so users can always know what to expect when they type any non-CJK characters, particularly numbers, punctuation, and symbols.
By taking a different approach for the KR and JP versions, in any scenario where both Japanese and Korean characters (and Chinese?) need to be used, there is a high risk of the "wrong" version of a given non-CJK glyph appearing.
A couple of examples off the top of my head:
- Any sort of document where Japanese and Korean are mixed (annual report, powerpoint presentation, website, etc). This will be particularly problematic in business scenarios, but could also appear in essays and other such documents.
- Font-fallback where the KR version is listed first, and the JP version listed second (or visa-versa), such that numbers / punctuation are pulled from one version when used with the other.
In my previous life as a font PM, I recall reports of user frustration due to the Korean and Japanese glyphs not aligning in design. While that specific issue doesn't apply here, it demonstrates that these sorts of cross-language documents are definitely not uncommon.
Finally, we cannot forget that at present some 1800 Hanja are still being taught to Korean school kids. While that doesn't necessarily mean that IBM Plex Sans KR will definitely include those Hanja in the near future, but their future inclusion is certainly a possibility. And scaling the non-Hangul glyphs at that point will likely cause document reflow (due to the increased width of non-Hangul forms), which is problematic anywhere IBM Plex KR is used.
I'd strongly recommend reconsidering this approach and instead align the non-CJK glyphs present in the CJK fonts.
To align JP with KR, the scaling of non-CJK glyphs is not the problem; the main problem lies in the em square height (i.e. ascender/descender) values of CJK (mainly kanji and hangul) characters. KR has the range of 780/-220 while JP has the range of 880/-120, so if IBM is to align them, the better course of work is to move KR up 100 funits instead of moving JP down as the values of JP is more reasonable for CJK font.
However, values from KR matches the natural height of IBM Plex and do not require extensive modification to non-CJK characters. Also, there is the fact that KR came out first before JP and changing KR might break some displays that are using IBM Plex KR.
Thus, the IBM Plex team will need to determine what really is the use case of IBM Plex fonts (as a document typesetting font [which should use JP values) or web branding display (which can use KR values)?) and take appropriate action to it.
P/S: Chinese font might use other em square height too such as 850/-150 and 800/-200.
@NightFurySL2001 An additional fun wrinkle to consider:
The sTypo metrics in the GoogleFonts version of IBM Plex KR aligns with the Google requirements for CJK which is 880/-120/0. So there's already a mismatch there between the GF version and the version here that should be resolved.
Also, as the useTypoMetrics flag is not set in the font, we can generally assume that the hhea and winAscent / winDescent values are the primary mechanisms for determining vertical metrics. In both this repro and on GF, these are set to 1085 / -415, so even if the KR syllable positions are changed, the overarching font metrics may not need to be modified.
I'd also like to reiterate this is important for app designer's sanity when working in multiple languages. If we can keep ascenders/descenders/bounding boxes the same across CJK it makes things a lot easier.