-
Notifications
You must be signed in to change notification settings - Fork 587
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
IBM Plex Sans JP is bigger than other Plex Sans fonts #388
Comments
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. |
Sorry, closed by mistake.
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. |
Will raise this as a separate ticket |
@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. |
🤦 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:
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: |
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:
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. |
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. |
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 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?
Then what % of hangul look good with JP? |
@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 |
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. |
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:
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 Also, as the |
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. |
Here, as a native Korean, I have something to tell you. Shortly, Hangeul, Kana and Chinese characters are different script, so they can have different size. Korean is written in Hangeul (seldomly with Hanja), Japanese is written in Kana and Kanji and Chinese is written in Hànzì. With above reasons, Hangeul character is assumed as a squared character so long time. However, as Korean are adopting Hangeul as major script and discarding Hanja, the tradition has been changed. Now, a good fit with Hangeul and Hanja is not major topic. Many Korean fonts put effort for rendering of Hangeul itself. A good fit with other scripts are second one. However, even that case, Hanja and Kana are not in higher priority because the second majority script in Korean community is Latin, and Latin is more*100 frequently used than Hanja or Kana. So I strongly agree with Sondoll's approach. There may be changes for IBM Plex Sans CJK, but not for IBM Plex Sans KR. |
@y-kim I think we should also consider "plex-ness" here. For example, the width of all number glyphs (0, 1, 2, 3, etc) in Plex are the same (in other words, they are monospaced vis-a-vis each other.) I think these kind of consistent touches make Plex easy to work with. |
@y-kim No one is saying that the Hangul needs to be changed to align with the Chinese or Japanese characters. In fact, the Hangul already appear to be designed on the same size em square as the Chinese characters. So there's already no issue about sizing between Hanja and Hangul (except for the different positioning of the em-square within the font, which would result in odd alignment should Japanese and Korean be used in the same line). If IBM Plex KR was a font designed purely for Korea and Hangul, then it is perfectly fine as is. However, it is part of a larger font family which supports a wide range of scripts and languages. Thus, like pretty much all other such large font families, it should (and I'd say must) consider cross-language use. The current implementation does not and creates unexpected alignment issues for users when used in conjunction with either the Chinese or Japanese versions of IBM Plex. |
For examples, IBM has the following to say about this font:
Instead, Google has the following to say about Noto:
I will lean to your side when I am talking with Noto because they are aimed at the harmonious. However, I don't read such purpose yet from the designer. In addition, I believe that the decisions and details exist for each language family alongside decisions and details for IBM Plex Sans itself. I wrote previous comment because you said that "KR and JP glyphs should be the same size". I didn't know what the size you exactly referred for, so I thought it as basic items of size -- width and height. Basis on this assumption, I told you that Hangeul and Hanja/Kana can have different width. Could please let me know I am incorrect? |
@y-kim The width is not a problem, hangul syllable in Source Han Sans/Noto Sans have different width with hanja and kana too. The problem here is the vertical placement of hangul in KR is lower than kanji and kana in JP, which makes UI design a lot harder to aligned vertically. Notice the middle section which is typesetted in JP floats higher than of KR. |
(And also the scaling of the Latin 🙂) |
@NightFurySL2001 Thank you for correcting what I misunderstood. However IBM Plex Sans KR is designed harmonized with Latin characters. I think it is very important because latin is the first companion of Hangeul. Movement of vertical position may looks better mixture text of Hangeul, Hanja, or Kana, but majority of the text will look worse. I think this kind of problem can be solved by IBM Plex Sans KR adopts Kana and Hanja in its repertory. This is not uncommon. Many Korean fonts already have glyphs in KS X 1001. If the vertical aligning is needed, then how about make IBM Plex Sans CJK rather modifying individual fonts? Note: It's my response to your first comment. The second one was written when I was writing it. |
If the hangul part is shifted to be at the same height as kana/kanji in JP, then the Latin part in KR will be scaled to the current JP size so it will still look harmonize but just taller (compared to the current KR). IBM Plex CJK will be too large of a project to be done, and serving smaller font files is faster on the web. Also, the current KR height will make combining the fonts into CJK a lot harder unnecessarily. I have asked if IBM Plex KR will make KS X 1001 and the answer in this repo is there is no plan for it, see #334 (comment). |
One of the well known problems in Korean fonts is relationship between Latin characters. It is normally good with uppercase but when length of lower characters are pretended before common particle (-으, -로) then Latin words and Hangeul looks like waving. It is difficult to solve this problem with traditional box model, vertical height or position of 으/로 may be adjusted, but they are not harmonized with other Hangeul characters. IBM Plex Sans KR might adopt one of other solutions to solve it -- adjust the lowest line of 으/로 to the baseline of Latin-1 characters. With this alignment, Hangeul and Latin-1 mixture text can be read more straightly. |
@BoldMonday has there been any further strategic thinking on how to standardize sizing across CJK? |
@johnnyshields Not from our side since this is a matter between Sandoll (the makers of Plex Sans JP) and IBM. |
Any updates on this discussion? |
A wild idea: instead of modifying KR which currently has the same size for the Latin part, maybe IBM Plex can choose to shift JP lower. KR vertical metrics match Latin version but JP vertical metrics referenced traditional Japanese font. To harmonise JP and KR, one of them must be changed. The previous argument I provide is to shift KR glyphs up and then scale the Latin glyphs such that JP kanji/kana and KR hangul can match up. However, the vertical metrics is not a fixed thing, there is no reason why JP must use the traditional vertical metrics (880/-120). Guaranteed that the height of the em box is still 1000, it is possible to shift JP kanji and kana down 80-100 font units (800/-200 or 780/-220) such that it can harmonise with Latin and KR vertical metrics. A similar issue can be found on googlefonts/googlefonts.github.io#45. Also, Chinese fonts uses anything in between 800/-200 to 850/-150 so the shifted vertical metrics could be a bit more natural to Chinese too. (However, SC is already in progress so any decisions to change JP will probably affect SC) Do be noted that there might be compatibility issues with modifying "standardised" metric values as some softwares mighr have hardcoded the value in the software. This well require consultation with Sandoll. Edit: shifting JP down will also need to consider if the original Latin will stay roughly vertically centered to the kanji/kana, or else it might make the Latin text appeared floating/sunken in between kanji and kana. |
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:
The text was updated successfully, but these errors were encountered: