Skip to content
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

Open
plastic041 opened this issue Jul 24, 2021 · 44 comments
Open

IBM Plex Sans JP is bigger than other Plex Sans fonts #388

plastic041 opened this issue Jul 24, 2021 · 44 comments

Comments

@plastic041
Copy link

IBM Plex Sans JP slightly bigger(or not hinted properly?) than other fonts.

image
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
@BoldMonday
Copy link
Collaborator

This is intentional – all Latin glyphs in Plex Sans JP have been scaled to 105% to mix better with the Japanese character set.

@johnnyshields
Copy link

johnnyshields commented Jul 25, 2021

@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?

@BoldMonday
Copy link
Collaborator

@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.

@johnnyshields
Copy link

johnnyshields commented Jul 25, 2021

Oddly enough Noto Sans CJK JP (and other CJK) appears to use different alphabet glyphs but they aren't significantly larger.
image

Noto CJK does also have a larger line height, which is identical between Noto JP and KR.
image

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.

@plastic041
Copy link
Author

plastic041 commented Jul 25, 2021

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?

@Buernia
Copy link

Buernia commented Jul 26, 2021

The Latin glyphs in Noto Sans CJK are from Source Sans, they’re also larger than the original Source Sans.

@johnnyshields
Copy link

How about an merged font option like Noto sans CJK?

Will raise this as a separate ticket

@BoldMonday
Copy link
Collaborator

BoldMonday commented Jul 26, 2021

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.

@johnnyshields
Copy link

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.

@johnnyshields
Copy link

johnnyshields commented Jul 26, 2021

@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: ABCDEFG

image

Is it possible Sandoll commented to 105% scale these chars specifically?

@BoldMonday
Copy link
Collaborator

@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:
image
As you can see vertical typesetting was considered as well.

@johnnyshields
Copy link

johnnyshields commented Jul 26, 2021

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.

image

@BoldMonday
Copy link
Collaborator

BoldMonday commented Jul 26, 2021

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.

@johnnyshields
Copy link

johnnyshields commented Jul 26, 2021

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.

@NightFurySL2001
Copy link

@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

image

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.

@johnnyshields
Copy link

johnnyshields commented Jul 26, 2021

@NightFurySL2001

  1. 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?
  2. 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.

@NightFurySL2001
Copy link

NightFurySL2001 commented Jul 26, 2021

  1. 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).
  2. 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.
    image

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.

@mjabbink
Copy link
Contributor

@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.

@mjabbink
Copy link
Contributor

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.

@plastic041
Copy link
Author

plastic041 commented Jul 26, 2021

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%?

@johnnyshields
Copy link

johnnyshields commented Jul 26, 2021

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.
image

@mjabbink
Copy link
Contributor

@plastic041 Using KR and JP together at 100% each will work. Sandoll also looked at those relationships as well.

@mjabbink
Copy link
Contributor

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

@NightFurySL2001
Copy link

NightFurySL2001 commented Jul 27, 2021

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.
image

@sandoll-inc
Copy link

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.

@NightFurySL2001
Copy link

NightFurySL2001 commented Aug 3, 2021

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 #392.

@aaronbell
Copy link

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.

@NightFurySL2001
Copy link

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.

@aaronbell
Copy link

@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.

@johnnyshields
Copy link

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.

@y-kim
Copy link

y-kim commented Nov 8, 2021

@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?

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ì.
Traditionally all characters in CJK scrips were considered to have the same characteristics. It may come from design simplicity, a fact that they share Chinese characters (Hanja, Kanji, Hànzì), or other reasons.

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.

@johnnyshields
Copy link

johnnyshields commented Nov 8, 2021

@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.

@aaronbell
Copy link

@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.

@y-kim
Copy link

y-kim commented Nov 9, 2021

@johnnyshields

For examples, IBM has the following to say about this font:

As the new typeface for our diverse and global brand, Plex® is just as important as our name or our logo. It fine-tunes the tone of our words. It represents who we are and what we believe—as a company and as designers. Every decision was made with purpose; every detail has a reason for being.

Instead, Google has the following to say about Noto:

Read and write text in any language
Nearly half of the 6,000 languages spoken in the world are endangered. Noto includes fonts for nearly all of the world's writing systems (scripts): from Latin, Chinese, Arabic, Hebrew, and all Indic scripts, to Egyptian hieroglyphs and emoji.
The designs are harmonious across scripts but retain the authentic flavors that make each script special. The fonts use Unicode and OpenType (ISO Open Font) international standards for accurate, professional-quality rendering of all orthographies.

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?

@NightFurySL2001
Copy link

@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.

image

image

@aaronbell
Copy link

(And also the scaling of the Latin 🙂)

@NightFurySL2001
Copy link

(Well that's a side effect with the different scaling I'd say, since the current Latin part is good enough to match each language perfectly but doesn't harmonize together)
image
image
Note: ⬆️ same font size and line height for both line, but JP looks slightly larger

Also attached a pic of mix typesetting; notice the JP kanji floats slightly unlike SHS.
image

@y-kim
Copy link

y-kim commented Nov 9, 2021

@NightFurySL2001 Thank you for correcting what I misunderstood.

ibm plex sans

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.

@NightFurySL2001
Copy link

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).

@y-kim
Copy link

y-kim commented Nov 9, 2021

compare

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.

@johnnyshields
Copy link

@BoldMonday has there been any further strategic thinking on how to standardize sizing across CJK?

@BoldMonday
Copy link
Collaborator

@johnnyshields Not from our side since this is a matter between Sandoll (the makers of Plex Sans JP) and IBM.

@johnnyshields
Copy link

Any updates on this discussion?

@NightFurySL2001
Copy link

NightFurySL2001 commented Aug 5, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

9 participants