gravitystorm / openstreetmap-carto

A general-purpose OpenStreetMap mapnik style, in CartoCSS
Other
1.53k stars 820 forks source link

Hangeul (Korean) font not readable #2204

Closed mxa closed 8 years ago

mxa commented 8 years ago

The labels in Korea written in Hangeul are hard to read or not readable at all. I did a quick mock-up in GIMP to see how other typefaces with a free license compare to the currently used on in carto.

This is the current situation: fontosm-original

This is with the font "Sans Serif" fontosm-sansserif

The Nanum font family is a font by the NAVER corporation published under a free license https://en.wikipedia.org/wiki/Nanum_font Font "Nanum Gothic" fontosm-nanumgothic

Font "Nanum Barum Gothic" fontosm-nanumbarumgothic

The Noto font family is by Google, published under SIL Open Font License https://github.com/googlei18n/noto-fonts Font "Noto Sans CJK KR Regular" fontosm-noto-sans-cjk-kr-regular

Font "Noto Sans CJK KR Medium" fontosm-noto-sans-cjk-kr-medium

Noto seems to have a bigger line height, that should be corrected. Noto is by far more readable compared to the currently used font. Noto aims to be a font with complete international language support, mabe pull request https://github.com/gravitystorm/openstreetmap-carto/pull/358 and issue #294 can be fixed with it too.

matthijsmelissen commented 8 years ago

See also #1067.

Am I correct in understanding that Noto Sans CJK KR Regular is the most readable of these fonts?

mxa commented 8 years ago

Both Noto variants are much more readable compared to the rest. The difference between Regular and the slightly stronger Medium is small. IMHO Medium is even a bit better than Regular. But: this may well be because of the way GIMP is doing the antialiasing.

matthijsmelissen commented 8 years ago

Using Gimp does not really give reliable results, I'd really recommend to test this in Mapnik (Kosmtik/Tilemill). Our text labels have a halo (similar to anti-alias) to make sure texts are also legible on busy backgrounds. It seems you didn't take this halo into account.

alimamo commented 8 years ago

Noto is much more readable, but if a halo is to be used, it would be nice to see a rendering with the halo first before making a change (or maybe just leave the halo off for Hangul).

gravitystorm commented 8 years ago

We need to see this rendered with mapnik. Also bear in mind that the "current situation" will be a rendering from mapnik2, so we need to see what the current fonts look like with mapnik3 too.

mxa commented 8 years ago

Who is mapnik and what is the current font?

matkoniecz commented 8 years ago

mapnik

See http://wiki.openstreetmap.org/wiki/Mapnik https://en.wikipedia.org/wiki/Mapnik

matkoniecz commented 8 years ago

Fonts are defined at https://github.com/gravitystorm/openstreetmap-carto/blob/master/style.mss, though I am not entirely sure how for given label font is selected (it is compiled to https://github.com/mapnik/mapnik/wiki/FontSet and AFAIK it means that Mapnik is using the first font where all symbols are available).

sommerluk commented 8 years ago

The place http://www.openstreetmap.org/#map=17/37.56412/127.00120 rendered with this style.mss

Map {
  background-color: @land-color;
}

@book-fonts:    "Noto Sans UI Regular", "Noto Sans CJK KR Regular";
@bold-fonts:    "Noto Sans UI Bold", "Noto Sans CJK KR Bold";
@oblique-fonts: "Noto Sans UI Italic", "Noto Sans CJK KR Regular";

@water-color: #b5d0d0;
@land-color: #f2efe9;

looks like this: screenshot 2

matthijsmelissen commented 8 years ago

Thanks @sommerluk !

Is the attached image easier to read for you than the original, @mxa?

mxa commented 8 years ago

The Hangeul in the attached image is indeed a lot more readable. It would be a huge improvement over the current rendering. However I notice there are two names in the example which have missing characters. When the name spans over multiple lines, the line height is much bigger, this should be compensated.

I made a gif animation for better comparison

osm_compare

matthijsmelissen commented 8 years ago

Note that part of this might be caused by Mapnik2 vs Mapnik3 (the new rendering is Mapnik 3). Could somebody perhaps also generate an image of this area in Mapnik2 with the old font rendering?

However I notice there are two names in the example which have missing characters.

Those are both bold fonts, it seems there something sill goes wrong.

mxa commented 8 years ago

Noto has a beautiful variety of different font weights. The line height of Noto is a bit too big. This also shows when using Noto in a text editor compared to other typefaces like DejaVu.

sommerluk commented 8 years ago

Note that part of this might be caused by Mapnik2 vs Mapnik3

The screenshot that I have posted is done with Mapnik2.

sommerluk commented 8 years ago

However I notice there are two names in the example which have missing characters.

Those are both bold fonts, it seems there something sill goes wrong.

The places are “CJ푸드월드 제일제당센터점” and “바다회집 (Bada Fish Restaurant)”. All of these characters are actually available in Noto Sans CJK KR family – in both the regular and the bold typeface. I’ve verified this. So this is most likely a rendering bug in Mapnik2.

sommerluk commented 8 years ago

Noto has a beautiful variety of different font weights.

Noto Sans CJK KR offers black, bold, medium, regular, demilight, light and thin. Noto Sans UI offers in the current release only regular and bold, but the next release will come with a big number of weights also (alpha release is available here: https://github.com/googlei18n/noto-fonts/tree/master/alpha/OTF/from-pipeline)

sommerluk commented 8 years ago

The screenshot shows a weight missmatch between the latin characters and the han characters: The han characters seems to be heavier (more bold). This applies for both the regular and the bold typeface.

However, I suppose that this is a Mapnik2 issue. Rendering the same text with the same fonts in scribus shows an (almost) identical font weight for latin characters and han characters.

sommerluk commented 8 years ago

The line height of Noto is a bit too big.

The designers of Noto probably wanted to make sure that also combining diacritics – maybe even multiple stacked combining diacritis – have enought space for rendering.

However, I fear that also here the Mapnik2 rendering makes some strange things…

mxa commented 8 years ago

The designers of Noto probably wanted to make sure that also combining diacritics – maybe even multiple stacked combining diacritics – have enough space for rendering.

I also assume that the line height in Noto is not an accident but intended to give space to the diacritics. However it is not needed for Hangeul. It is much higher than it was before and IMHO should be compensated for.

However, I fear that also here the Mapnik2 rendering makes some strange things…

Maybe not in this case.

mxa commented 8 years ago

@sommerluk would you mind making a comparison for Japan and China too? I think this would solve some issues there as well. #294

mxa commented 8 years ago

For testing purposes Some dense Hangeul compound words: 칡 뼘 뺨 삶 뚫어뻥 슭곰발 뿅 꿰뚫다 삶다 핥음 뷁 앉다 흙 값 닮다 핥다 꿱 꾀꼴철썩 붉으락 헐레벌떡 엎치락 꿰뚫다 뺑뺑 방긋 떼굴 딸꾹질 낚시 부엌 꽃 훨씬 깜깜하다 폐쇄 관광

And those are technically correct dense compounds, but they don't exist as words: 꿿 뛝 쐒 빯 쪯 뺿

sommerluk commented 8 years ago

It is much higher than it was before and IMHO should be compensated for.

Well, it is highter, but not so much.

The only option in CartoCSS about line spacing seems to be text-line-spacing. See https://github.com/mapbox/carto/blob/master/docs/latest.md for documentation. It seems that Mapnik uses by default the line spacing recommendation of the font (see https://www.microsoft.com/typography/otspec/recom.htm → “Baseline to Baseline Distances” for details). CartoCSS’ text-line-spacing may add additional space (add leading), by assigning a positive value. The documentation says that it must be an unsigned value, so negative values (=reduce line spacing) are not allowed, but actually negative values work nevertheless well.

sommerluk commented 8 years ago

Japan: http://www.openstreetmap.org/#map=17/35.68190/139.77480 screenshot 1

China: http://www.openstreetmap.org/#map=17/31.24077/121.38159 screenshot 2

sommerluk commented 8 years ago

@mxa What about Han unification?

mxa commented 8 years ago

@sommerluk Noto is available as either Chinese, Japanese, Korean or as one package containing them all. https://www.google.com/get/noto/help/cjk/ There is an FAQ entry on the Noto page:

"What about Han unification?

Whether or not Han unification is a good thing is really a moot point at this time. It’s a fact of life that needs to be worked with when designing fonts or text processing systems for the CJK languages. We are building fonts to be used in systems that exist now and that means working within the frameworks that exist.

If somebody would like to change those frameworks then they should get involved with the standards bodies and contribute to the development of the standard and change the direction they are going. "

sommerluk commented 8 years ago

The problem is: This map style renders the whole world with the same rendering rules, without any country-specific rules. That means particulary that the same rules apply to Korea, Japan and China. So probably we have to make a choise and support only one Han variant…

mxa commented 8 years ago

Is it not possible to use the Noto font that includes all the Han characters in one set for this and render CJK with that? I can't read Chinese and Japanese, but from what I see the difference and gain in clarity of the characters is the biggest for Korean.

sommerluk commented 8 years ago

Noto covers all of this.

The Han unification problem is independent from any specifig font. The question is: How to make the choise between the available glyph forms.

As it’s an independent issue, I’ve opened #2208 about this.