bugMapOSMatic - Bugs: bug #36166, Index categories on two lines...


bug #36166: Index categories on two lines improperly supported

Submitter:  Thomas Petazzoni <tpetazzoni>
Submitted:  Fri 13 Apr 2012 01:01:31 PM UTC
Category:  ocitysmap Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Confirmed
Privacy:  Public Assigned to:  jvrnix
Open/Closed:  Open Release:  2012.04
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Tue 17 Apr 2012 10:16:43 AM UTC, comment #9: 

Just 'Public Buildings' was computed to need a rescale. Doesn't look that out of place to me. I'll render a larger area including more categories, to see what it looks like then.

(file #25668)

Jeroen van Rijn <jvrnix>
Group Member
Mon 16 Apr 2012 01:23:00 PM UTC, comment #8: 


I'll try and keep the impact to a minimum, but the main thing is for the headers to draw properly. My previous comment's suggestion that the impact might be do double the amount of drawing calls for the index wasn't entirely accurate; only the 27 headers would double, worst case.

Your suggestion might just be what I need to have it work in the straightforward low impact way I'd originally intended. The lack of an additional ctx.save and ctx.restore around the font measuring and change might have been what I was missing. I'll give it a try.

- J

Jeroen van Rijn <jvrnix>
Group Member
Mon 16 Apr 2012 01:13:07 PM UTC, comment #7: 


To get the size of some text, you can use code similar to label_drawing_width():

Also, do not forget to use ctx.save() and ctx.restore() to save and restore the cairo context before and after changing it.

Good luck!

David Mentré <dmentre>
Group administrator
Mon 16 Apr 2012 09:57:19 AM UTC, comment #6: 

This is turning out to be a little more complicated than I first thought.

Initially I believed that indexlib/commons.py:draw could be modified to use draw_utils:adjust_font_size before calling draw_text_center, which would've meant a nice short elegant patch.

It turns out this didn't scale the text the way I wanted and also didn't prevent the text from wrapping.

Then I tried saving the layout width, calling set_width(-1) before adjusting the font size - with a then slightly modified adjust_font_size that would scale down or up depending on an extra parameter. Sadly as soon as I restore set_width to its proper header width after changing the font size, the text wraps again like it did before.

Then I tried (from http://www.pygtk.org/docs/pygtk/class-pangofontmetrics.html) to get the approximate character width from a font metrics object, but soon found out that the PangoCairo context doesn't seem to have the required get_metrics method. Alas, foiled again.

I do have another idea to get the needed metrics to rescale the text properly:

draw_utils:draw_text and friends return the requisite information after drawing that could be used to scale with fd.set_size before making the draw_text_center call. Of course we don't want to draw the text twice, so I'm proposing this:

def draw_text(ctx, pc, layout, fascent, fheight,
              baseline_x, baseline_y, text, pango_alignment, draw = True):

When draw == False, it omits the last two actual draw operations and just returns the size tuple.

Back in indexlib:draw it would first measure the result by calling draw_text with draw set to false. If the result overflows the target area, the font description is retrieved, the font scaled. Only then is draw_text_center actually called.

So sadly no patch to fix at least the overflowing single-line yesterday. I'll work on implementing the solution outlined above to see if it actually has the desired effect. I'll try and get this done today, inbetween or after work work.

I do realise it effectively doubles the number of draw calls for the index, but luckily this is a very small part of the overall run time. Also, given that get_metrics doesn't seem to work, I don't seen another way. Ideas/comments welcome!

Jeroen van Rijn <jvrnix>
Group Member
Sat 14 Apr 2012 05:24:46 PM UTC, comment #5: 

To avoid duplication of effort, am assigning this task to myself.

I've been working on this and I expect to have a patch ready tomorrow for the case seen in the German cities.

After that case has been fixed, I'll work on proper multi-line support.

Jeroen van Rijn <jvrnix>
Group Member
Sat 14 Apr 2012 08:49:33 AM UTC, comment #4: 

Your option "2) Measure the translated text and if wider than the column, dial back the point size until it fits." is definitely the one that should be implemented, in addition to proper support for wrapping (i.e, when the category title is multiline).

Thomas Petazzoni <tpetazzoni>
Group administrator
Sat 14 Apr 2012 08:47:12 AM UTC, comment #3: 

The bug itself is a very tough one to crack, as to fix it properly you'd have to have an understanding of hyphenation rules for all supported languages. From what I gather, Knuth's hyphenation rules as used in Tex are elegant.

There is a PD implementation of that algorithm available for Python, see: http://nedbatchelder.com/code/modules/hyphenate.py

Unfortunately, trying it on the original 'Bildungseinrichtungen' gives: Bil-dung-sein-rich-tun-gen instead of Bil-dungs-ein-richt-ung-en

So rather than build a list of exceptions for all supported languages, I see two other possibilities:

1) Find shorter descriptions as we come across bugs
2) Measure the translated text and if wider than the column, dial back the point size until it fits.

Even though amenities don't change on a daily basis, to me 2 is a more elegant solution as it doesn't paper over the defect.

Jeroen van Rijn <jvrnix>
Group Member
Fri 13 Apr 2012 05:23:21 PM UTC, comment #2: 

For a related problem, see http://www.maposmatic.org/jobs/42430

There the street 'Enckevoirtstraat (Monseigneur van)' runs into the grid index column, causing 'AE53' to be hard to read.

Jeroen van Rijn <jvrnix>
Group Member
Fri 13 Apr 2012 01:29:34 PM UTC, comment #1: 

There is a similar, but slightly different problem when the name is too long and cannot be wrapped. For example, "Bildungseinrichtungen" is an index category name that did not fit properly on http://www.maposmatic.org/rendered//042407_2012-04-13_15-02_DelmenhorstDithmarschenLowerSaxonyGermany.pdf (page 68).

Thomas Petazzoni <tpetazzoni>
Group administrator
Fri 13 Apr 2012 01:01:31 PM UTC, original submission:  

The current code to generate the street index makes the assumption that the name of a category will fit on a single line. Unfortunately, this is not true for the german language where we can have "Öffentliche Einrichtungen".

See http://www.maposmatic.org/rendered//042402_2012-04-13_14-24_DahmeOstholsteinSchleswigHolsteinLandmasse23747Germany.pdf for an example of such problem (last page of the PDF, last column).

Thomas Petazzoni <tpetazzoni>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #25671:  2_citymap.pdf added by jvrnix (1MiB - application/pdf - Comparison of the same area with -L nl_NL.UTF8 for the 't / T sort curiosity)
file #25668:  1_citymap.pdf added by jvrnix (1MiB - application/pdf - Rescaling of individual headers, result)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by mpetazzoni (Updated the item)
  • -email is unavailable- added by dmentre (Posted a comment)
  • -email is unavailable- added by jvrnix (Posted a comment)
  • -email is unavailable- added by tpetazzoni (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-04-24 mpetazzoni CategoryNone ocitysmap
        StatusNone Confirmed
        ReleaseNone 2012.04
    2012-04-17 jvrnix Attached File- Added 2_citymap.pdf, #25671
    2012-04-17 jvrnix Attached File- Added 1_citymap.pdf, #25668
    2012-04-14 jvrnix Assigned toNone jvrnix

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code