Baseline of Noto Sans Khmer UI variable font is not aligned with Latin script

[TidharC]

SUMMARY

With Noto Sans Khmer UI variable font, the Khmer baseline is rendered higher that the Latin script baseline.

REPRODUCTION STEPS

0. Install the appropriate font and modified fonts.xml file, then reboot.
1. Navigate through system settings, looking for lines with a mix of Khmer and Latin script (e.g. developer options, network connectivity etc.)

OBSERVED RESULTS

Khmer baseline is higher than Latin baseline (see screenshots).

EXPECTED RESULTS

Same baseline for Khmer and Latin script.

ADDITIONAL INFORMATION

Font name: NotoSansKhmerUI-GX.ttf Version: 1.900

Platform: Android

[punchcutter]

The baseline shift was intentional to allow for full Khmer shaping. Two options were proposed and this version was chosen knowing that the baseline would be different in exchange for getting proper shaping.

[xiangyexiao]

good to know. I am closing this bug as it is working as intended.

@marekjez86 @jungshik

[KatMomoi]

This is an important point and so let me re-confirm this point. I had thought that variable fonts are re-packaging of the same font info in a more compacted format such that essential font dimensions for non-variable and variable fonts are the same. Your are saying that this is not a correct assumption such that there could some differences such as the baseline position between the 2 different format fonts -- presumably built from the same source?

[KatMomoi]

I checked with Tidhar and it turns out that the static Khmer UI font he tested is not from the source as the variable version. Can someone confirm that the design change was made recently?

[marekjez86]

@KatMomoi : we, Google, when presented with the design choices chose the one that was described by TidharC. Both static and variable fonts in Phase III have the same properties. However, in this bug the static font was from Phase II and the variable font was from Phase III.

[jungshik]

Hmm.... I'm afraid we have to revisit the design decision.

To me, the screenshot (the right half) in the bug report seems to be pretty bad. I'd not claim that Noto Sans Khmer UI is harmonous with Roboto (or Noto Sans LGC) with a rather large mismatch in their baselines.

[jungshik]

Obviously, there's a trade off between baseline matching and a better shaping (given that Khmer glyphs tend to have rather tall descenders), but ....

[jungshik]

I checked with Tidhar and it turns out that the static Khmer UI font he tested is not from the source as the variable version.

For testing, we may as well consider doing a 3-way comparison:

1. The current Khmer font (production android): Phase 2
2. Noto Sans Khmer (UI) VF from the pipleline (phase 3)
3. Noto Sans Khmer (UI) static instances from the pipeline (phase 3 )

Comparing 1 and 3 would be used to find any potential issue arising from changes between Phase 2 and Phase 3.

Comparing 2 and 3 would be used to see if there's any issue with static and VF.

Currently, only 1 and 2 are compared.

[jungshik]

@roozbehp for his take on the baseline mismatch.

[marekjez86]

@roozbehp , @xiangyexiao , @jungshik : IMHO, we made the right decision in October of 2016 (but thank you Jungshik for disagreeing with this today). The choice was between (1) the Latin baseline matching and difficult readability for the native readers/speakers (diacritics not stacked but listed side-by-side on one line below or above) [that's what the previous UI font also implemented; I wonder why we ever approved it] and (2) what you see above where characters stacked just like for the document font (although with "parts" a bit smaller). The readability won :-)

NotoSansKhmerUI_proposal (1).pdf

[marekjez86]

Old UI font (note lack of stacking in the first character [single bottom line arrangement]; it's possible that this kind of re-arrangement is very readable in Arabic, but it was considered less readable in Khmer)

New Sans Khmer UI font and followed by the Serif Khmer

[I've learned that Serif Khmer above is the old one; I guess I didn't uninstall it from my Mac].

[jungshik]

Thank you, @marekjez86 , for sharing the design document.

As I mentioned earlier, there's certainly a trade-off between 'looking natural' and 'easy-to-read' on the one hand and matching the baseline with Latin and 'looking more harmonious' in the UI (where Latin-Khmer mix is common) on the other hand.

Given that Latin-Khmer mix is rather common in the UI (and we're not the first to do the trick in option 1 in the design doc - WIndows UI font does the same), it seems to me that baseline matching is more important, but I'm not a Khmer speaker.

Adding @tiroj for his input. (obviously, it's a pity that we have to fit everything into a single UI metric, but we have to find the best within that constraint).

[tiroj]

This sort of issue won't go away until the dimensions of UI metrics become localisable and able to flex to accommodate the natural proportions of different writing systems. Until then, there are always going to be trade-offs and some kind of violence done to the typography of the languages of many millions of users.

Personally, I would aim to make the trade-off in favour of native readability, which I think means trying to come as close as possible to the normal representation of a writing system in terms of proportions and arrangement of elements. This does sometimes mean scripts might need different scaling, varying baselines, etc., which I agree looks like a real mess, and inevitably generates some complaints. But the trade-off to make the mixed-script UI text look prettier is to undermine the normal representation of one or other of the scripts, preventing readers from recognising familiar patterns in the arrangement of elements.

Over the years, trying to force various scripts into restricted vertical metrics for UI fonts, I've sometimes used methods to maintain a common baseline that have undermined the normal representation of a language. I've always regretted it (which is not to say I won't do it again if a client insists — as they sometimes do — on that common baseline).

[punchcutter]

@marekjez86 The Serif Khmer you show is the old one. It doesn't really change anything for this discussion, but just wanted to point out that it's not the new one.

[marekjez86]

quoting @tiroj from the e-mail he sent out on exactly this topic on 24/Oct/2016: "My opinion is that software makers should stop restricting the height of UI elements based on Latin-centric assumptions and should start localising the design grid.

In terms of the options proposed, I personally think it is best to preserve the orthographically correct arrangement of elements whenever possible, because this aids readability. So that would favour Option 2, raising the baseline. But I am aware from Microsoft's experience that whenever baselines are raised in this way they do get complaints from users, because of misalignment of European numerals and punctuation. If such misalignment could be minimised, then Option 2 would seem to me the best option."

[xiangyexiao]

None of option 1 and option 2 are perfect. and Option 2 has better native readability. I would vote for option 2 too.

@roozbehp, want to make sure you are aware of this.

[jungshik]

Thank you, @tiroj and @marekjez86 for the replies.

I am aware from Microsoft's experience that whenever baselines are raised in this way they do get complaints from users, because of misalignment of European numerals and punctuation.

As shown in the screenshots above, Android UI tends to mix not just European numerals and punctuation but also Latin letters with Khmer making the issue even worse.

One way to get out of this (well, it requires changes in Android) would be shifting up Roboto's ASCII-baseline dynamically or per UI language, but it'd not happen right away.

Another would be transplant Roboto's ASCII-range character glyphs to Noto Sans Khmer UI with a baseline shifted-up and use Noto Sans Khmer UI as the primary UI font in Khmer UI. Again, this wouldn't happen right away because it requires a change in Android.

For both of the above, it's assumed that ASCII-range character glyphs can be shifted up without being clipped.

[marekjez86]

@roozbehp : here's a suggested solution to https://github.com/googlei18n/noto-fonts/issues/853 (hamza issue) that is consistent what we have in phase II fonts for Khmer UI (see the rightmost glyphs). I do not think it is acceptable, but I'm not a native speaker/reader of the language:

[tiroj]

If the vowel sign were placed beside the hamza, then they should be to the left, not to the right.

A concern would be that a sequence like this could precede another letter also carrying an above mark, leading to collisions.

[TidharC]

I see a potential inconsistency in the Khmer variable fonts: it seems the baseline is raised for the UI font only. The baseline for the non-UI font is level with Latin script. I am attaching a screenshot of the difference between Gmail message preview mode (baseline is raised; does it use the UI font?) and full message read mode (baseline is level with Latin).

[marekjez86]

This is as intended.

On Wed, Mar 8, 2017, 12:51 TidharC notifications@github.com wrote:

I see a potential inconsistency in the Khmer variable fonts: it seems the baseline is raised for the UI font only. The baseline for the non-UI font is level with Latin script. I am attaching a screenshot of the difference between Gmail message preview mode (baseline is raised; does it use the UI font?) and full message read mode (baseline is level with Latin).

[image: gmailkhmer] https://cloud.githubusercontent.com/assets/16353803/23723397/de7df514-03fd-11e7-9d06-5fa6c8914cac.png

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/googlei18n/noto-fonts/issues/846#issuecomment-285165244, or mute the thread https://github.com/notifications/unsubscribe-auth/AMtJf6QvEjI12CdbXcylNONQuSKHqiDrks5rjxTmgaJpZM4MEv40 .

[hrhatada]

See below screenshot. I compared Khmer baseline shift problem to other tall font:Myanmar & Thai. You can see the Latin chars(parentheses) baseline in Khmer is shifted and unbalanced

[xiangyexiao]

@marekjez86 @jungshik is there a conclusion here?

[csvan]

I am seeing the same issue with noto sans thai. The following is a sample of the output when using Apache FOP to generate a PDF which uses both noto sans thai and noto sans for characters on the same line:

The "boxes" are glyphs which are not present in either font set, but the problem persists without them.

I would also very much like to see a resolution to this.

[marekjez86]

@csvan : which versions of Noto Sans Thai and Noto Sans are you using? Alternatively where did you get these fonts?

[ohbendy]

See below screenshot. I compared Khmer baseline shift problem to other tall font:Myanmar & Thai. You can see the Latin chars(parentheses) baseline in Khmer is shifted and unbalanced

I'd say that image makes a good case for including parentheses in the Khmer fonts, and raising them with the Khmer baseline. Same with other Latin punctuation, full-stops, commas, quotes, hyphens etc, which can all be used with Khmer but look bad if they're on a different baseline.

[simoncozens]

The Khmer UI font is admittedly a design compromise, and arguably an unfortunate one, but that is the point of the UI fonts; it is a compromise and things get squished into metrics that ideally they shouldn't have. I don't believe that the fix here is to juggle more things around, but to deprecate the concept of UI fonts and make the application layout work better for tall and deep scripts. That's what we have proposed to the Android team, and we are not planning to make any interim changes to the UI families other than obvious bug fixes.