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

Japanese Fonts Too Small / Halo (Stroke) too small / Shields misrendered #294

Closed
javbw opened this issue Dec 18, 2013 · 38 comments · Fixed by #2349
Closed

Japanese Fonts Too Small / Halo (Stroke) too small / Shields misrendered #294

javbw opened this issue Dec 18, 2013 · 38 comments · Fixed by #2349

Comments

@javbw
Copy link

javbw commented Dec 18, 2013

A lot of the labels in Japanese are using a light stroke font instead of a bolded font when the English is rendered bold.

Train stations, amusement parks, motorways, and other important places have hard names to read in non-roman characters because they are rendered smaller than they should be for the kanji.

Examples:

Train Stations http://www.openstreetmap.org/#map=17/36.41395/139.33339
The Kanji for Nishikiryu is difficult to read.

Parks http://www.openstreetmap.org/#map=18/35.73297/139.74664
(The Rikugi-en Garden's complicated kanji is unreadable, for example)

Tokyo Disneyland http://www.openstreetmap.org/#map=15/35.6293/139.8818
Tokyo Disneyland's label (東京ディズニーランド) is impossible to see, let alone read. (thin stroke, no contrast, tiny size) The labels on the parking isles? totally visible. (A whole 'nother issue issue of not rendering labels on parking isles at lower zoom levels)

Motorway labels http://www.openstreetmap.org/#map=15/36.3551/139.1981

The shield labels for the motorways are rendered completely wrong, overlapping the kanji. The Kanji font is very feint. Contrast this to the trunk label (17) right above it.
Also the exit labels are not very readable either. Usually you need these labels when going to a new place, so it is difficult to guess complicated kanji or read faint ones


Most of these issues can be remedied by the choice of a better font that includes bolded characters for Japanese / Chinese. I assume you are using the same font for these features in all regions, but that font doesn't seem to have bold weight 6 characters (W6). The font choice is also a serif font (you can see the strokes in the characters) for some features, when that is unneeded and makes things very hard to read at the small level they are rendered, whereas a san-serif font (no strokes) which is used in other places, is perfect for this Job.

TL;DR : Japanese characters are faint / garbled / rendered incorrectly in some situations. Update the font to a san-serif with bold characters available, or at lease use only san-serif fonts for non-roaman languages, or increase the font size.

@javbw
Copy link
Author

javbw commented Jan 8, 2014

Anyone care to comment about this? there are some really ugly renderings, esp the shields as I note.

-Bad kanji renders / halos / size-alignment of the shield on the motorways - note the difference compared to the secondary road's shield.
shields

Which the name of the park?
gardens

Can you read 東京ディズニーランド in there? I can read all the parking lot isle numbers, but not the name of the 2nd busiest theme park in the world.

tokyo_disneyland

@pnorman
Copy link
Collaborator

pnorman commented Jan 8, 2014

Most of these issues can be remedied by the choice of a better font that includes bolded characters for Japanese / Chinese. I assume you are using the same font for these features in all regions, but that font doesn't seem to have bold weight 6 characters (W6).

What font would you suggest?

@gravitystorm
Copy link
Owner

There's a few separate issues raised in this ticket, and I'd like to see them all addressed. One big problem for me is that I (unfortunately) can't read any non-latin scripts, which often makes it hard to assess the output.

  • Shields. At the moment, shields are chosen based on the number of characters, but obviously the width of "1111" and "北関東道" can be very different depending on the font used. I've already opened a ticket with mapnik about this, see Shield width from width of rendered text mapnik/mapnik#2020
  • Font sizes. In general, the fonts in this style are too small, and I intend to increase the sizes of all fonts in the future. This will of course help with Japanese fonts
  • Font choice. At the moment we are using DejaVu Sans, with unifont as a fallback. https://github.com/gravitystorm/openstreetmap-carto/blob/master/style.mss The Japanese characters are coming from unifont, which is a font designed simply to have every character, not necessarily look nice. The latin characters are very simple and ugly, and I expect the non-latin characters might look similar! To solve this, as @pnorman says, we need font recommendations. The fonts should ideally be available on Ubuntu, but if not must be licensed under an open license. I can't tell which fonts are good or bad for Japanese characters.
  • Glyph placement. The latest development versions of mapnik use a new library for text placement, called harfbuzz. It would be useful to know if this improves the text rendering for Japanese characters, but again I can't tell.

So yes, I am interested in fixing all these issues, but for most of them I need expert help!

@javbw
Copy link
Author

javbw commented Jan 9, 2014

yea, as a Californian, I'm used to Street names and Freeway numbers. It's opposite in Japan. They used to name every important road (and still do), but in the last 20 years switched to numbering most primary and secondary roads (hence road names and shield numbers). But almost every motorway uses a name (北関東道 = North Kanto Expressway, or "Kita-Kanto") and is not associated with any number whatsoever.

I can research some fonts for you, however, I understand the idea of the license restrictions, but I am unfamiliar with the types needed for these projects. I assume something with a similar license as DejaVu Sans?

as an old graphic designer now tracing in OSM, I know when something looks wrong. I know of but I do not understand the underlying code/system/CSS/guts of the system. I will be happy to be the eyes to check things, or ask the others around me here to check how readable things are.

After looking over some royalty free fonts, 3 problems come up -

  • Chinese script fonts are time consuming to make, because there are thousands of characters needed, including old / outdated ones that show up in old place names rarely, so there are very few to legally choose from that are complete.
  • Although Japanese uses Chinese Kanji, the free Japanese fonts usually only have their additional phonetic alphabets and favorite characters - Korean and other non-roman scripts are usually unsupported by these free fonts.
  • The third problem affects all asian fonts - their Roman Alphabet sucks. They are usually spaced weirdly or look different than the Japanese characters, because they are afterthoughts, so they are not a substitution for english. The english looks great on OSM already. Modern fonts (like Helvetica) have good support, but alas we can't use them.

There are 3 types of fonts for generally used - brush, serif (mincho), and and san-serif (gothic), and of course a few stylized fonts thrown in too. Then there is their weight - usually a number. the bigger the number, the more "bold" the font is - 3 is light, while 5 is a little bolded. 6 and 8 are pretty rare. There are other letters that tell you about it's use.

Google led me to http://www.wazu.jp/gallery/Fonts_Japanese2.html, which has good examples of the 3 kinds of fonts, but most of them seem to be from inside other programs or packs.

Japanese Sourceforge has a listings for a couple different free fonts.(http://sourceforge.jp/magazine/09/04/27/0313213/3),

and one seems to be pretty good, called Ume (Uu-meh "plum")
http://sourceforge.jp/projects/ume-font/downloads/22212/efc-umefont_459.7z/

it has a lot of combinations available. Ume Gothic C4 or C5 looks pretty good at 13 pt, which would be good for the shields and theme-park / zoo / park / town hall place names

ume_c4
ume_c5

I'll keep looking for some fonts for you.

PS: the font rendered onto the roads themselves and labels for basic locations, and towns look very readable, no need to mess with those.

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

I think the first problem to tackle is the falling back to Unifont, a bitmap font designed for completeness, not looks. This is not restricted to Japanese, but effects any language that isn't covered by DejaVu Sans

I can research some fonts for you, however, I understand the idea of the license restrictions, but I am unfamiliar with the types needed for these projects. I assume something with a similar license as DejaVu Sans?

The most fundamental restriction is that we need to be able to get the font on a system running Ubuntu. I'm not sure there are any legal reasons that prevent someone from purchasing a completely proprietary font and using it for their tile server.

The best resource on Unicode fonts I found was Unicode Font Guide For Free/Libre Open Source Operating Systems

GNU FreeFont does not contain Chinese and Japanese glyphs.

The only two pan-unicode font that they mention which do not have a cost assocated with them are Bitstream Cyberbit and GNU Unifont. Bitstream Cyberbit 1.1 is under a single user license, which is definitely not ideal, although it might be usable.

A particular paragraph on the unifont page seems relevant for this

Secondly, the flexibility of Keith Packard's Fontconfig library allows the construction via simple XML-based configuration files of virtual font sets (such as "sans" and "serif") which can do a better job than any one Pan-Unicode font can at covering the Unicode code space with high-quality glyphs coming out of projects such as those highlighted in the previous paragraph.

Based on that, it sounds like a "virtual font set" is the best option, but frankly, I'm out of my depth here.

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

@gravitystorm Are you even happy with DejaVu as the default font? I know it's got reasonable unicode coverage, but is it a good map font?

Note to self: http://font.ubuntu.com/ looks to have bold japanese glyphs

@javbw
Copy link
Author

javbw commented Jan 9, 2014

As someone who is totally unfamiliar with linux (and honestly, PCs) I'm surprised the OS would have trouble with TTF (Truetype) files. They have been the basis for fonts for a long time now.

Ah, patent issues.

http://en.wikipedia.org/wiki/TrueType#Linux_and_other_platforms it looks like there was a serious issue with freetype and non-western fonts, but that has been resolved with version 2.4 - so we should be able to get standard TTF fonts on a linux box now - but as a long time Apple tech, thats way out of my depth.

@javbw
Copy link
Author

javbw commented Jan 9, 2014

What is the font being used for the park and building names? it seems to be different than the theme park names. Also, the City name font is pretty good too.

@javbw
Copy link
Author

javbw commented Jan 9, 2014

Should I try breaking down the other issues into other tickets? Im new to collaborative and ticket systems.

eg:
1

Parking isle names should be rendered 2-3 zoom levels below when the actual parking isles themselves are rendered (The Tokyo disneyland example has rendered isle labels, but no parking isles - this is a sea of unneeded labels.) I understand service roads names, but parking isles don't need labels at such a low zoom level. labels bigger than the parking lsle itself is not really useful for someone trying to find their car, and just makes clutter.

2

Theme park name color choice of tan with a thin white stroke (halo) is unreadable in any language when someone has actually mapped the theme park. As a tourist using a map, a Theme park should stand out above all things, similar to train stations, so it needs a more noticeable color/stroke combo. Magenta/ large white stroke? Magenta is strong, but there shouldn't be a lot of theme parks everywhere.

3

Theme park names need to be rendered a 1-2 higher zoom levels. they are usually the reason tourists are using a map, and are landmarks to people who live in the area.

4

Park, garden, zoo, and townhall names need to rendered with a larger font size (the font / color itself is fine) and appear at 1-2 higher zoom levels, again, landmarks / important public places.

5

Motorway Junction Refs need to be rendered bolded, similar to the junction names. Since the refs are usually sequential, the ref is more helpful for determining how much longer you have to drive to get to your exit than the unknown order of the names for travelers. I may not know where Komagata exit is in relation to Ashikaga exit, but I do know the relation between exit 2 and exit 6.

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

Should I try breaking down the other issues into other tickets? Im new to collaborative and ticket systems

One issue per ticket is best

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

As someone who is totally unfamiliar with linux (and honestly, PCs) I'm surprised the OS would have trouble with TTF (Truetype) files. They have been the basis for fonts for a long time now.

Ah, patent issues.

The reason we're falling back to a bitmap font isn't because TTF doesn't work, it's because unifont is bitmap. DejaVu is TTF.

@javbw
Copy link
Author

javbw commented Jan 9, 2014

oh, then any TTF font should work then, assuming it can prioritize which font to look for a character in first. I assume that is part of localization for large programs?

Ume => DejaVu => unifont.

I assume al the tiny road labels are unifont because there is no antialiasing whatsoever, so it is easy to read at 9pt, but if you use 13 or something for the larger labels, I imagine it looks really ugly.

@gravitystorm
Copy link
Owner

Yes, we can prioritise. the fonts. It's most likely to be

DejaVu -> [good japanese font] -> [good arabic font] -> [good thai font] -> [etc] -> unifont

... since as you mention above, often the good non-latin fonts will have poor latin characters. DejaVu is fine for all the characters that it supports, and it doesn't have any japanese characters at all.

Incidently, it's interesting to hear that different labels look good and bad, since they are all just unifont. I suspect since it's a bitmap font the glyphs are significantly different at different point sizes, rather than just scaling larger.

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

I suspect since it's a bitmap font the glyphs are significantly different at different point sizes

From what I can gather, it's got one size of glyphs.

DejaVu -> [good japanese font] -> [good arabic font] -> [good thai font] -> [etc] -> unifont

What happens if [good japanese font] has arabic glyphs, but not good ones? Admittedly almost anything is an improvement over unifont and we don't want to make perfect the enemy of good, but it's going to come up

@javbw
Copy link
Author

javbw commented Jan 9, 2014

@ gravitystorm I think you're exactly right.

Although I've been out of the font game for about 7 years or so, but if I remember the bitmapped fonts are going to look pretty good at low point sizes if it is something done en masse, simply because the characters have already had their pixels optimized for the point size. Maybe bending the bitmapped fonts will make them difficult to read, but whatever that tiny point size is (9? 8?) the bitmapped font looks pretty good when it is straight and inline with the pixels of the tiles. Trouble comes when they get tilted, as the pixels at such low point counts don't play along very well. 45 degrees plays havoc on the non-latin fonts, I think. the simpler Japanese phonetic alphabets have large and simple characters (like English or korean Hangul - "Disneyland" is written in that alphabet above) but the more complicated Chinese kanji ( like "Tokyo" and "Kita-kanto" above) are impossible to read cold when small and tilted, but some come out okay, since you know they are road labels and train labels.

I just realized this is probably a limiting factor for a lot of map labels.

Google handles this by mapping VERY few road names onto roads, and almost all labels are horizontal.

There is a difference between the "english labels" map and the Japanese only - the font size goes up 1-3 points, depending on the label. Train stations in particular get bigger (because they are very important landmarks, one of the few things everyone knows and can find.

edit: some of the caps are too wide and being squeezed, so they have viewed at full size to see the differences

english
english

Japanese
japanese

even at low zoom levels there are very very few non-horizontal mapped tags.

medium

everything that mapped to a road/train line is a 12-14 pt thick font in Japanese, and 10-11 bold in english. I'm guessing this is purely for readability.

only when you get to the highest levels of google's zoom (OSMs highest view) do a lot of diagonal place names show up. Google switches from their maps to Zenrins maps, which is unbelievably detailed for Japan - it puts the US maps to shame.

high

I'm guessing this is all about font issues with the generated tiles - otherwise it would make sense to show the user a bit more data, but making everything huge would make it a cluttered mess, and too small would be unreadable.

OSM shows a lot of non-horizontal labels mapped very frequently, even in a place with just a little data.
kiryu

a place like tokyo (which is still being labeled) has an amazing of non-horizontal labels.
osmtokyo

I know reducing the amount of labels rendered at lower zoom levels, spacing out the road and train line labels two to three times their current spacing and making certain ones bigger by default would make things a little more "google mapish" but I think they do all of that just because of the font limitations and the clutter it creates. OSM has a lt of information coded into the colored roadways - I can follow a road much easier visually than in google maps, so I wouldn't need so many labels (refs maybe, but not names)

@javbw
Copy link
Author

javbw commented Jan 9, 2014

What happens if [good japanese font] has arabic glyphs, but not good ones? Admittedly almost anything is an improvement over unifont and we don't want to make perfect the enemy of good, but it's going to come up.

Most of the freeware Japanese fonts I saw don't have many other glyphs, unless it is one of those like unifont. Ume has nothing but Chinese, Japanese, English, and the extra glyphs they like in Japan (it seems).

having crap Roman glyphs is the biggest worry - I guess having a good Roman English font first would be the easiest way to solve it - I imagine that would take care of most of Europe.

@pnorman
Copy link
Collaborator

pnorman commented Jan 9, 2014

Although I've been out of the font game for about 7 years or so, but if I remember the bitmapped fonts are going to look pretty good at low point sizes if it is something done en masse, simply because the characters have already had their pixels optimized for the point size.

Well, yes, bitmapped fonts can look good. Unifont doesn't, as it's optimized for coverage and speed of development of new glyphs, not for looks.

I know reducing the amount of labels rendered at lower zoom levels...

Although there's probably improvements to the labelling that can be done, let's try to get the fonts worked out first, because unifont looks terrible.

In the theme of "less terrible", I've installed the ttf-ubuntu-font-family package on my server, and I'm going to throw together a test. It's got good glyph coverage, so would probably make a good fallback before unifont, even if we go for better looking fonts where possible.

@javbw
Copy link
Author

javbw commented Jan 9, 2014

In the theme of "less terrible", I've installed the ttf-ubuntu-font-family package on my server, and I'm going to throw together a test.

I look forward to seeing the results =D I do think OSM has a definite advantage because of the color coding.

Less terrible is always better!

@pnorman
Copy link
Collaborator

pnorman commented Jan 11, 2014

In the theme of "less terrible", I've installed the ttf-ubuntu-font-family package on my server, and I'm going to throw together a test. It's got good glyph coverage, so would probably make a good fallback before unifont, even if we go for better looking fonts where possible.

So, I was mislead by my browser doing a fallback, giving the impression that it had CJK characters. I still do see some easy improvements, but we're going to have to look at other fonts to get proper CJK characters.

@pnorman
Copy link
Collaborator

pnorman commented Jan 11, 2014

So, there are four relevant fonts for Japanese according to the Unifont guide: Unifont, Bitstream Cyberbit, Sazanami Gothic ゴシック體 and Mincho 明朝體. Unifont is ugly, and Bitstream Cyberbit is not re-distributable, but makes a good reference.

Bitstream Cyberbit: bitstream_cyberbit

Sazanami Gothic: sazanami_gothic

Sazanami Mincho: sazanami_mincho

sazanamisample

Sazanami Gothic is a closer match to the sans-serif look of DejaVu, but there's an issue. After the Kochi Font controversy some fonts were regarded as non-free. Debian is recommending fonts-vlgothic or fonts-ipafont-gothic over ttf-sazanami-gothic

Wikipedia's list includes Droid Sans Fallback, IPA Gothic, Mona Font, and VL Gothic.

@javbw
Copy link
Author

javbw commented Jan 11, 2014

according to the wiki, they remade Kochi as kochi-substitute, and that is the basis for Sazanami. But (at least on my mac) Sasanami looks ugly compared to the others.

VL gothic looks the best out of all of them at 13,14,and 18 pt. 12 pt looses so much detail, so I would say 13pt is the minimum size for VL Gothic. VL P Gothic has a better Roman character set, the Kanji seem identical.

12
13
18

The "gothic" fonts are all san-serif, so it will always match the modern DejaVu, helvetica, Arial, Verdana, Gil Sans, etc.

The "Mincho" font's are all serif fonts, like Bitstream above, Times, Garamond, etc.

Sifting through the fonts is a bit easer when you can discount them by name alone. (Sans, gothic, modern, etc)

@pnorman
Copy link
Collaborator

pnorman commented Jan 11, 2014

VL gothic looks the best out of all of them at 13,14,and 18 pt. 12 pt looses so much detail, so I would say 13pt is the minimum size for VL Gothic

Keeping with one issue per ticket, let's try to focus on font selection for now

The current count of font-size in the stylesheet is

     23 text-size: 8;
     35 text-size: 9;
     35 text-size: 10;
     10 text-size: 11;
      4 text-size: 12;
      1 text-size: 13;
      1 text-size: 14;
      3 text-size: 15;

@javbw
Copy link
Author

javbw commented Jan 11, 2014

so we need fonts that look "good" down to 8 pt? that's a tall order =D

8
9
10
11
14

@pnorman
Copy link
Collaborator

pnorman commented Jan 12, 2014

so we need fonts that look "good" down to 8 pt? that's a tall order =D

Well, andy is looking at increasing font size, so 10pt might be more realistic, but I wouldn't think the stuff that's 8pt right now will go up to 13.

I take it IPA Gothic, Mona Font and Droid Sans Fallback aren't as good as VL Gothic?

@javbw
Copy link
Author

javbw commented Jan 12, 2014

yea, 8 =13 is too big of a jump. I oooked at IPA, and normal VL looked better. I'll check mona and droid shortly.

getting rid of 8pt should be a priority - there is a visible difference in the characters between 8 to 9. I'm wondering how they would look rendered in the tiles (instead of my mac) because of the anti-ailising difference. it looks like there is some attempt an anti-alising the fonts only when they are rotated, so they will look different than the screen caps above when actually in tiles.

@pnorman
Copy link
Collaborator

pnorman commented Jan 12, 2014

I posted to talk on the subject of fallback fonts: https://lists.openstreetmap.org/pipermail/talk/2014-January/068896.html

This is wider than just Japanese, but is related.

@javbw
Copy link
Author

javbw commented Jan 12, 2014

Droid is def better looking than unifont - it is a bit thicker, so it is easier to read the train station's names, for example. Without a fallback font, all the Japanese characters are missing.

because droid looks better, it opens up a possibility of using other softer colors for fonts (less jarring ones) because it is more readable and seemingly anti-aliased.

@javbw
Copy link
Author

javbw commented Jan 12, 2014

PS: if you want to check "readability" of these characters (or any of these asian scripts), look at how their horizontal lines are rendered. there is a big difference between 8 and 9 point in my little pictures of VL above. The "東京" in Tokyo disneyland is much easier to read at 9 pt than 8 pt because the horizontal lines and the empty space in the characters are blurred into grey at 8pt, while at 9pt they are distinct - black lines and white space.

even though I have no idea how to read Korean, just looking at the lines in the labels around downtown Seoul and Incheon (where most people are) shows droid is slightly better than than standard OSM because there is less blurring of the character into the stroke.

@javbw
Copy link
Author

javbw commented Jan 13, 2014

Mona and its related fonts are probably what is inside unifont - it is an old bitmapped font.

droid looks pretty good, but I'm having a hard time finding a unified TTF file with all the languages together.

https://github.com/android/platform_frameworks_base/tree/master/data/fonts

has the fonts broken up by language (which might be good for -carto, as we can specify a different font for each language?)

Comparing VL Gothic to Droid Sans, Droid is the winner until 13 pt. VL gothic looks a lot better at 13, at least here on my Mac.

test characters:

Tokyo - tesu
Rikugi-en

characters48pt

droid 9
droid9

VL 9
vl9

droid 13
droid13

VL 13
vl13

@javbw
Copy link
Author

javbw commented Jan 29, 2014

Any Further news / updates on this issue? I'm not sure I'm of much help anymore, but I'm interested in seeing the fonts get updated/ enlarged.

@pnorman
Copy link
Collaborator

pnorman commented Jan 29, 2014

Writing up what I've done is on my to-do list, but I haven't found the time yet

@pnorman
Copy link
Collaborator

pnorman commented Jan 29, 2014

I'm also working to CJK and starting with easier alphabets, because Han unification is going to be a pain.

@AndrewHain
Copy link
Contributor

Is the answer to use different text rules in China and Japan?

@pnorman pnorman self-assigned this Feb 21, 2014
@pnorman
Copy link
Collaborator

pnorman commented Feb 21, 2014

Is the answer to use different text rules in China and Japan?

I'd rather do something based on language detection from name:xx tags. I have some ideas in my head on how this can be done, but it's not trivial, hence me starting with Thai, a much easier language to do font selection for

@AndrewHain
Copy link
Contributor

That doesn’t work if name:ja and name:zh are the same, which may well make sense.

@pnorman pnorman mentioned this issue Feb 24, 2014
10 tasks
pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue Jul 3, 2014
Fixes gravitystorm#680
Fixes gravitystorm#203
Fixes gravitystorm#202 (mostly)
Fixes gravitystorm#146 (mostly)

Cross-reference gravitystorm#294 mapnik/mapnik#2020

Starts organization for gravitystorm#508

Replace existing PNG road shields with new SVG ones. This allows for easier adjustment of colour and width as well as sharper high-resolution rendering.

At the same time, a number of other shield related bugs are fixed.

To aid in organization, a new shields directory is created.
pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue Jul 3, 2014
Fixes gravitystorm#680
Fixes gravitystorm#203
Fixes gravitystorm#202 (mostly)
Fixes gravitystorm#146 (mostly)

Cross-reference gravitystorm#294 mapnik/mapnik#2020

Starts organization for gravitystorm#508

Replace existing PNG road shields with new SVG ones. This allows for easier adjustment of colour and width as well as sharper high-resolution rendering.

At the same time, a number of other shield related bugs are fixed.

To aid in organization, a new shields directory is created.
pnorman added a commit to pnorman/openstreetmap-carto that referenced this issue Jul 3, 2014
Fixes gravitystorm#693
Fixes gravitystorm#680
Fixes gravitystorm#203
Fixes gravitystorm#202 (mostly)
Fixes gravitystorm#146 (mostly)

Cross-reference gravitystorm#294 mapnik/mapnik#2020

Starts organization for gravitystorm#508

Replace existing PNG road shields with new SVG ones. This allows for easier adjustment of colour and width as well as sharper high-resolution rendering.

At the same time, a number of other shield related bugs are fixed.

To aid in organization, a new shields directory is created.
@matthijsmelissen
Copy link
Collaborator

Did anybody test whether Mapnik 3 improves the situation?

@dink-straycat
Copy link

That's my tileserver's output(CentOS7, Apache + mod_tile, mapnik v3.0.9).
Right-side is OSM (Maybe mapnik2?).

Nishikiryu:
mapnik3-001

The Rikugi-en Garden:
mapnik3-002

Tokyo Disneyland:
mapnik3-003

North Kanto Expressway:
mapnik3-004

Maybe, there is no problem about this issue,
but Japanese label's word-wrap seems to be worse on mapnik3.

@sommerluk
Copy link
Collaborator

As far as I see, the following things have been discussed here:

I’m not sure about the proposed feature/zoom level changes. But for the rest, I propose to close this issue and continue the work in the specialized issues.

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

Successfully merging a pull request may close this issue.

7 participants