CJK containing highway numbers placed too low within their rectangular shields

[jidanni]

Examining e.g.,
https://www.openstreetmap.org/#map=13/24.0162/120.9521
closely shows if there is Chinese in a road number,
it causes the whole "投73" to render too low inside
its rectangular shield. Compare this behavior to the
correct placement of "21".

[jidanni]

(None of the other four layers on osm.org are affected. (Because none of them use highway numbers at all!))

[jeisenbe]

This is property of the font currently used, probably Noto Sans CJK JP Regular in this case. I don't think we have better options available for font styles which are consistent between many different scripts and languages.

fonts.mss:
"The used CJK font covers all CJK
languages, but defaults to the japanese glyph style if various glyph
styles are available. We have to default to one of JP, KR, SC, TC because
this carto style has no knowledge about what language the “names” tag
contains. As in Korea Han characters are not so widely used, it seems
better to default to either Chinese or Japanese. As Chinese exists in the
two variants SC/TC, it won’t be a uniform rendering anyway. So we default
to Japanese. However, this choice stays somewhat arbitrary and subjective.
See also #2208 "

[jidanni]

But unlike e.g., 澤 with three versions, 沢, 泽, 澤, there is only one 投. So maybe it is a simple centering issue.

[jidanni]

So you have the right character, no matter for use in CN, JP, TW. The only remaining problem is vertical centering.

[pnorman]

The ways are highway=tertiary, and the height of the "3" in one of them is 8px. Looking locally for a ref containing 3, I found one and measured it at 9px tall. There's other differences, one is 18px tall, the other 21px

[sommerluk]

@jidanni Thanks for the bug report. It's well written and describes clearly the problem.

Today's font files can have arbitrary defined positions of the base line and of the glyph height. Usually, the font designer follow roughly the nominal point size, but the exact height is always a design decision. You can test this out in your favourite word processor. Type the same word twice, and choose different fonts for each of the words, while maintaining the same nominal point size. Then, zoom in. You will observe, depending on the fonts you've chosen, bigger or smaller differences in the glyph height. In summary: The glyph height is an arbitrary design property of the font.

In openstreetmap-carto, for technical reasons (limitations of the rendering stack we are using), the highway shield background must be drawn in a different step than the font rendering. So, basically we make a sort of “best guess” of the expected glyph height at the moment when rendering the highway shield background. Often, this gives good results, but sometimes not. The shield might be too narrow, too wide, too height, too low, or not well centred. In summary: The shield position and size is a sort of “best guess”.

You observed that some highway shields are differently centred than other nearby highway shields. As @pnorman has observed, also the glyph height of the numbers is inconsistent within openstreetmap-carto. This is because it's not the same font! Compare in the original bug report image the form of “7” within the “投73” label to the form of “7” within the nearby “527 m” (mountain): It's clearly different. The former “7” belongs to Adobe Source Han Sans, while the latter belongs to Noto Sans. So how gets Adobe Source Han Sans in there when it's not even in the font list of openstreetmap-carto? Now it gets a little complicate: Google, the publisher of Noto Sans, does not design itself this font. Google commissions individual fonts for each script they want to support within Noto. Most of the scripts in Noto they have commissioned to Monotype. However, Noto Sans CJK not. It's a partnership with Adobe. Adobe develops its Source Han Sans, and Google has the right to publish this very same font in a re-branded version named Noto Sans CJK. Source Han Sans does not only contain CJK glyphs, but also Latin glyphs. And it also contains the numbers from 0 to 9. And these numbers have a different design then Noto Sans. This is quite different from most (all?) other Noto scripts: Noto Sans Hebrew, Noto Sans Myanmar and so on do not contain any Latin glyphs or numbers. The software stack has to detect this and fall back to Noto Sans when Latin glyphs are necessary. We have in our font list Noto Sans as the very first entry, so with higher priority than Noto Sans CJK. Why does the rendering engine take nevertheless the numbers from Noto Sans CJK inspite of its lower priority? Because Mapnik tries to find a single font for rendering the hole string, whenever possible. We cannot control this behaviour of Noto and Mapnik. In summary: In some cases, openstreetmap-carto inconsistently uses different font designs with different glyph heights for numbers and Latin glyphs, but this cannot be contolled by copenstreetmap-carto.

By the way we have position problems also for non-CJK situations. This is because not all the Noto scripts have the same glyph height. Myanmar glyphs are for example much higher than Latin glyphs at the same point size. This is because of the nature of the script. All scripts have their “natural” size. Noto makes sure a visually harmonic impression (at the same point size) across all scripts, but that means some glyphs are higher than others. This is a deliberate design decision of Noto. Varying glyph height means varying base line position, which means in return varying position of numbers. In summary: The exact glyph height, and therefore the position of the baseline, is somewhat unpredictable - even if it's pure Noto.

[jidanni]

OK, now all(?) that is left is to test what happens when a highway shield, instead of containing [投77], just contains [投]. It would take one minute to test, however I dare not make such edits on osm.org.

[jidanni]

https://phabricator.wikimedia.org/T198235 similar problems.

[pnorman]

@sommerluk has a good explanation of the causes and constraints we have on fixing it. I also reviewed the Freetype properties and concluded there's nothing we can set that would help, so there's nothing we can do in this style to fix the problem.