Reduce vertical spacing in labels #2358
Comments
|
https://material.google.com/style/typography.html#typography-styles has suggestions for line height. We don't need to follow them and we've got a different use case, but they'd be a good place to start. I'm not sure what values they suggest since I'm on airport wifi. |
|
See also #2204 (comment) about line spacing. Notos default line spacing is okay (or even narrow) for normal text bodys (about 60 characters per line). In general, in typography you would use a bigger line spacing when your lines are very large, and a narrower line spacing when your lines are very short. In cartography there are no text bodies, but only labels, and they are horizontially rather short. So a rather narrow line spacing would be good. The limit might be either tall scripts (#2349 (comment) and for a list also https://material.google.com/style/typography.html#typography-other-typographic-guidelines) or latin scripts with high characters (all capital characters, f, k, h…) with one or more combining diacritics (thought it’s rather seldom to have more than two combining ciacritics at the same letter). |
|
Here is a screenshot (500%) with some example data: I agree that a smaller baseline-to-baseline distance would much improve the situation for latin scripts. But I don’t know how to do this without accepting some (seldom?) collisions in non-latin scripts or when using many diacritics. |
|
A real-world example for not-too-large spacing: |
|
How does the non-UI Noto look like? The usage of the UI-variant seems logical ("constrained space") but I never saw example renderings of non-UI. |
#2349 (comment) has an example. There is no difference on common latin characters, but SE Asian languages do show the difference
|
|
Thanks, this was actually linked in first post, sorry. |
|
Some example pictures from notofonts/gujarati#18 "Frankfurt am Main" has very wide spacing, the second line looks very unconnected to the first. "Frankfurt am Main" and "Freiburg im Breisgau" (left-bottom) have very wide spacing, the second line looks like a city on it's own. |
|
A solution for “Freiburg im Breisgau” might be to increase the necessary distance from label to label. But this would reduce notably the number of labels that appear on the map, which would not be really practical. |
|
Notos baseline-to-baseline distance (vertical spacing) seems to be script/font-file specific: https://github.com/googlei18n/noto-fonts/issues/764#issuecomment-252778567 |
except
Sounds like some experimentation is needed. |
|
See also this test page on the wiki (edit it to complete the text samples for missing scripts). It shows the full set of fonts used in the Master stylesheet for CartoCSS (in the same order, and for its three supported styles: book, bold and oblique). https://wiki.openstreetmap.org/wiki/CartoCSS/fonts All fonts are set to 10pt and drawn in black (with a small white glowing shadow) over a green background typical for the map, their name is displayed (along with a ISO 15924 script code from which they are designed, and followed by a suitable line-height for that script). The font size and the line-height for each script is set in this: https://wiki.openstreetmap.org/wiki/CartoCSS/fonts/text which is used as a template used in the previous page. Currently, the following line-heights are determined by As far as I see, the maximal value is 1.6 if we ignore the script used. That value 1.6 is the one implemented by default in Mediawiki. But it is only needed for Myanmarese/Burmese (whose Noto font still has no "UI" version with a smaller value around 1.4). |
|
What I'm really interested in is how the examples like မြော look with a an adjusted line spacing. Remember, the property we set is text-line-spacing, not line height. |
|
"text-line-spacing" is a cartoCSS specific property which is simply the difference: There's no such "text-line-spacing" in standard CSS, this is an invention of cartoCSS. When I mean a "line-height"=1.6, it means that the text-line-spacing is simply 0.6em (relative to the current font-size which is "1em"), so substract 1 to the relative line-height to get the desired "line-spacing" for cartoCSS. However cartoCSS does not allow you to specify the "line-spacing" value directly, it uses a line-spacing from the font metrics property, and text-line-spacing will be a relative adjustment to the font metrics: "text-line-spacing:0" is exactly the same setting as "line-height:normal" which is the default for HTML and CSS. cartoCSS contradicts here everything that is defined in the CSS standard (identically for HTML or SVG or all web standards), by defining it relative to the "normal" line-height, instead of relatively to the font-size.
In my opinion cartoCSS is broken here: it probably uses the incorrect font-metrics or performs just a very weak hinting not really based on font-metrics, or based on the "em-height" with en estimated offset. (the em-height is the vertical extent of the "M" relative to the baseline, it is found in font metrics, and is about 0.8em in Latin fonts; in Asian fonts, the em-height is not defined because they use another baseline). CartoCSS has not followed what was standardized in CSS for defining font-metrics and defining a common line-height independantly of scripts and baselines. CartoCSS is even broken here with its own definition of "text-label-position-tolerance" for defining the line-box (but only for the "placement:line") which is arbitrarily set to text-spacing/2.0 in order to define its own "shield". standr CSS uses a much more consistant "line-box", where all baselines can be placed. the cartoCSS metrics are broken here and do not even work correctly with Asian fonts: to compensate this defect and avoid collisions of text in Asian scripts, the default line-boxes produced by cartoCSS are much higher than expected and this is the reason why Latin scripts have excessive baselines. I do think that cartoCSS should be extended to support all standard CSS metrics and baselines. CSS will certainly not be changed to support any cartoCSS metrics. But it's true that CSS would require an additional measurement unit for its "normal" line-height (e.g. "nh", so that "line-height: normal" in CSS would be exactly the same as "line-height: 1.0nh" in all scripts and all fonts and all baselines). |
|
@verdy-p I really appreciate your input, but it does not make sense to talk about plain CSS here. We use CartoCSS and while both have CSS in their name they don't have so much in common. It also does not make sense to talk about em. This unit is not available in CartoCSS. We cannot go beyond our renderer. For additional clarification: CartoCSS is just a preprocessor. It transforms a CSS-like syntax into Mapnik XML. As such it cannot do much things differently. It is the same thing with LESS/SASS and CSS. I'm sure there are improvements possible to the text rendering but these are out of scope here and have to be discussed at the renderer library repository which is Mapnik. |
|
Speaking about CSS, it has all these things docmumented, but not supported at all in CartoCSS and this is a problem of CartoCSS, which then impacts the effective rendering of multiline labels. Note: this discussion has been forwarded several times to other bugs/issues. Apparently no one want to support it anywhere. Discarding it here will not solve the problem. But someone must accept it, there's no appropriate place where to put it if every dependant project says this is not their problem and says this is "out of scope" or "non relevant". But moving CartoCSS forward to use properties as they are used in standard CSS would really help everyone (for all renderers: Mapnik, JOSM, iD, SVG/PDF generators, online vector rendering, including those using 3D extensions...), instead of reinventing the wheel. |
|
CartoCSS is already abandoned: https://www.mapbox.com/blog/the-end-of-cartocss/ Yet the code can still be updated and released: |
...
If different properties for line spacing are needed, this should be reported to Mapnik or CartoCSS issue trackers. We can't do anything about it here. |
|
You suggest reporting to CartoCSS, they forward the issue to here, for its use in Mapnik, and here "openstreetmap-carto" uses both CartoCSS (abandoned?) and Mapnik (they don't care about it). |
|
Did you try to contact the CartoCSS project? Deviating from it or replacing it could be a huge problem. |
|
@verdy-p JOSM and overpass-turbo use mapCSS which is not at all related to cartoCSS. |
|
@verdy-p You are still mixing up several things as @HolgerJeromin also explained. I'm also a maintainer at CartoCSS and I could not implement something like you suggest, because I can only take some input and map it to some Mapnik XML value. Mapnik would have to provide more finegrained options for anything to make sense in CartoCSS. Similarly, CSS' power is also not defined solely by its specification but by the rendering engine which implements it. But that does not mean we cannot improve things here. Nobody really said that we don't want to improve the line spacing. It's just not as easy as with CSS. |
|
@verdy-p : @HolgerJeromin makes an important point - MapCSS and CartoCSS are completely different things and we should not mix them up. Moreover, CartoCSS is not a "cartography version of standard CSS" or anything like that, so any comments about what font features are available in regular CSS are pretty much irrelevant. CartoCSS is simply an alternative way to describe Mapnik XML stylesheets. We have only the font handling options available through Mapnik. If we want to do something that Mapnik doesn't support, then we need to add the feature to 1) Mapnik and then 2) to CartoCSS. @verdy-p I would strongly encourage you to experiment with font handling within Mapnik, by using Kosmtik or Tilemill. This is much more practical than using unrelated technologies like mediawiki or html. And please stop referring to things as "broken", it's quite disrespectful to the people who work on them. |
|
Things can be said "broken" without loosing any respect to anyone. Anyway if it is broken becauise of Mapnik, then Mapnik is broken there and should be modified. This does not change the fact there's a "problem" to solve. If you don't like the term "broken", you will also not like the term "bug", but why is there any bug tracking system for those projects ? We admit that there are and will be problems to solve and it's independant of people that have already worked on these projects or will work on it to find solutions (and discover or create new problems/bugs/broken things). It's natural in any project with incremental evolutions. If all was already perfect, there would no longer be any project, everyone would use it "as is" without sending any criticism If there are developers on these projects, it's exactly because there are problems to solve gradually or new requirements or features to implement. Are you saying that Mapnik and CartoCSS are completely finished projects ???? |
|
I also feel this term is pretty neutral, but word games will not lead us anywhere. The most important thing is that Mapnik is a place you could start to get this problem solved, as Andy wrote. I appreciate the work you've done searching for a solution. Do you need some help with it? |
|
Note: "unrelated technologies" are not so unrelated. OSM data will be rendered via various technologies but for many things we already have widely supported standards (with many developers involved for many other projects). Using HTML (even indirectly via a MediaWiki page) showns what can be done, and allows experimentation. Experimentation/demonstrations are very useful to know what can be done. I don't think that Mapnik or CartoCSS have to be "isolates" creating their own standard, this would not be productive and a loss of time for many developers that all want convergence with standards for more openness and for easier integration of other features. These projects don't have to become proprietary by rejecting those standards: "CartoCSS" resued the term "CSS" in its name but it is defective when it is not really an extension but a complete rewrite ignoring the standard (and the ongoing evolutions that are continuing fast in CSS: keeping away from this standard will cause later more and more work to follow what is desired and needed, and actually implemented in other solutions; in fine, you'll loose developers support that will prefer developing for something else, because it is has more features, has more possibilities of integration, is becioming more and more performant, and has many more tools to work with them). But here you just want to promote a separate standard (that has comparatively a lower global support, even if for now it is having some success in some corners, but which is still not as mature as what competitors are doing, notably Google, Bing, MapBox... that will sell there own solutions) Just consider that MapBox has abandoner the project to use soemthing else: it is a clear sign that the current state of CartoCSS will not be scalable and adaptable to newer projects that really want to do more with cartographic visualisations. So don't loose time, and think about reconverging with the standard solutions. Otherwise this project will be slowly loosing its current supporters. Mapnik will need to evolve (another desrired thing in Mapnik is to support more zoom levels instead of the current levels based on integral powers of 2. Already others are already using quarter-levels and also implement now vector rendering and multiple projections (not just WGS84), and maps not necessarily oriented to the North. but for now Mapnik renders single tiles combining a background and oriented texts and icons that are not usable for rotating the generated maps. Probably later Mapnik will have to support multiple layers, and in fact generate many labels (for cities) and icons separatetly from tiles for the background: this layer of text and icons should probably become vectorial and will be able to support translations without having to generate everything: tiles will need to become transparent. If later we want to reuse our languages for vectorial rendering, we'll need to have style properties working with other n,on-bitmap renderings. And almost all vectorial renderers are now using standard CSS (or fully equivalent properties, with only a difference of syntax, but not os semantics, so the conversions of formats can be more easily implemented and automated.) |
|
Let's keep this issue on topic. Your remarks are far beyond this ticket and even this project - whatever Mapnik should/will do, is outside of our scope. We can however change the underlying technology, but that's a story for a new ticket, if you want. @pnorman even mentioned he would like to make a switch, but didn't say anything more specific yet. |
|
@verdy-p I have not fully read your lengthy discourse about other projects and general things because it's far beyond this project. Please stay on topic and accept the fact that there are things beyond this project that cannot be solved and discussed here. This is not a general issue tracker about OSM rendering but about this style specifically. If you continue to derail this discussion I will lock this ticket. |
|
But you propose no solution at all for handline line-heights correctly. This ticket is open for finding solutions, even if it involves finding cooperations with other projects from which you depend. It's a real problem since the begining, and I've just answered all your oppositions. And I don't see any reason why cartoCSS (or Mapnik) or other pseudo-CSS (MapCSS and other styling "protocols" like Mapnik-XML, or even the new styling protocol used now by MapBox) needs to deviate with standards by not supporting them at least with some equivalences and why OSM would even need to support two competing (and incompatible with each other) deviations. Convergence is needed. Internationalisation of text rendering is a very huge problem that cannot be solved alone in this isolate project. You need to track here how you'll solve this problem (which is in fact a problem of interoperability which has been imho irreasonably ignored). This ticket about handling line-height is a perfect example of the havoc that can happen, where everyone involded in this project ignores the real and constant need for convergence with standards, and rejects his own responsability. Others will take on if you don't want to solve it yourself, or even if you close this ticket, as it will reemerge (and will become even more urgent and complex to solve later when developers will start abandoning this CartoCSS project (something that has already happened with MapBox abandoning it). If you cumulate such ignored problems, the project will gradually fade out of use and will no longer receive any interest of developers: they'll have chosen something else (OSM itself already thinks about switching). |
|
As this discussion turned out to be non-productive I'm locking it temporarily. This does not mean that this is not an issue that should be solved. In fact this is a rather important problem on lower zoom levels that should be solved sooner than later. Just a few remarks: Even if you feel there is immediate need to solve a specific problem it does not mean that someone will immediately jump to it. This is a volunteer-driven project. Even if there are interdependencies with other projects it does not mean that someone here has the power or the capacity or time to influence that projects. Largely, we have to work with what we have. I appreciate your initial efforts but they where not immediately useful for the technology used here as there is little overlap with CSS. This is not something we could change overnight. If you feel this is wrong, feel free to do something against it. I'm also suggesting that you familiarize yourself with this project more to be able to come up with possible solutions in scope for this project. Everybody is happy to help you if you have problems with the setup and the first steps. |
|
Unlocking again that the discussion can proceed, hopefully on-topic. |
|
Some thoughts about vertical line spacing:
|
|
There's still a problem: even if you use the "correct line spacing for This can easily explaing why a multiline label appearing above another The vertical position of boxes for multiline labels is not correct with 2016-11-22 21:52 GMT+01:00 Lukas Sommer [email protected]:
|
|
Some basics about Dejavu and Noto font metrics using ftdump from freetype package. The text height value is the most interesting. When divided by EM size the line height in em is calculated. Dejavu (DejaVuSans.ttf) 2384/2048 = 1.16 I prepared an overview of the height of all Noto fonts: |
|
I get error 404 with this gist link. |
|
Here is one example of a place in Myanmar which just is just touching now, so no space for -0.15 em. This is because Noto Sans Myanmar UI just uses all space of the general Noto UI height of 1.36. For Myanmar one could try to use non-UI variant which is much taller but may give more wiggle room. I can't test myself because there's no Geofabrik extract of Myanmar. |
|
You can probably make it on your own by clipping Asia data: https://wiki.openstreetmap.org/wiki/Osmconvert#Applying_Geographical_Borders |
|
I fixed the gist link |
|
@jojo4u Thanks for the table! Great work! |
|
The Myanmar example with −0.15 em: |
|
The Myanmar UI collision is just the effect of an UI font version still not fully debugged. Ideally it should fit in 1.36em, with a small reduction of size for descenders and ascenders. However this is clearly not a problem of OpenStreetmap Carto, but should be reported to Noto developers. The UI fonts in Noto are still in their first trial release, they've been published in an express way because of demands, even if they are still not ideal (notably for South-East Asian scripts) The UI fonts are not ideal for Arabic Kufhi. But should even Arabic Kufhi be used in UI ? In my opinion only standard (western) Arabic, or Nasthalik (Eastern Arabic for Persian/Pashto/Urdu would seem needed (Kufhi is much more a "decorative" variant for Eastern Arabic... just like we have "swashed" versions of Latin also requiring huge line-heights, but normally not suitable for use in UI or labels on maps). I'm not convinced that Kufhi is useful for us (or even useful and really needed in Noto UI collection: it should not have been released at all, leaving only a non-UI version, usable for typesetted word processor documents, or possibly the presentation of long paragraphs of text on the web, or for special titling on book covers). |
|
The Myanmar -0.15 rendering seems acceptable. |
You refer to my screenshot and not line-height reduced by sommerluk?
There is no UI variant for Kufi. Have a look at #2485. |
|
What I meant is that you used the huge Kufi font by default for rendering Arabic on Map, instead of more conventional (and UI!) fonts. Kufi however is best suited for rendering on traffic signs on roads, for easier reading by drivers, or for indoor signals in public areas, or for advertizing and titles of books. In all cases they are only short texts, but isolated on a clear background. |
|
Myanmar with non-UI and UI both with -0.15 em. Non-UI looks better alone but not when mixed with latin.
|
Noto has a lot larger vertical spacing than the old font. This looks rather ugly for cartography (at least for Latin script).
Before/after:
We can use a negative text-line-spacing attribute to reduce the vertical spacing by a couple of pixels.
The text was updated successfully, but these errors were encountered: