Hard Copy Map Utility (wxPython wrapper for ps.map) text overlay is broken

[cmbarton]

Trying to add text to an output cartography window in the hard copy map utility raises the following error:

Traceback (most recent call last):

File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-

darwin10.8.0/etc/gui/wxpython/gui_modules/psmap_dialogs.py", line 1677, in OnOK

ok = self.OnApply(event)

File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-

darwin10.8.0/etc/gui/wxpython/gui_modules/psmap_dialogs.py", line 1670, in OnApply

self.parent.DialogDataChanged(id = self.id)

File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-

darwin10.8.0/etc/gui/wxpython/gui_modules/psmap.py", line 763, in DialogDataChanged

extent = self.getTextExtent(textDict = self.instruction[id].GetInstruction())

File "/Users/Shared/grass_dev/grass70_dev/dist.i386-apple-

darwin10.8.0/etc/gui/wxpython/gui_modules/psmap.py", line 681, in getTextExtent

dc.SetFont(wx.FontFromNativeInfoString(textDictfont + " " + fontsize))

File "/Users/Shared/grass_dev/grass70_dev/macosx/dist/GRAS

S-7.0.app/Contents/MacOS/etc/python/wx/_gdi.py", line 2309, in FontFromNativeInfoString

val = _gdi_.new_FontFromNativeInfoString(*args, kwargs) wx._core

[cmbarton]

This construction is raising an error:

wx.FontFromNativeInfoString(textDictfont? + " " + fontsize)

I think that the argument to wx.FontFromNativeInfoString needs to be the kind of information returned by the wx.FontDialog

Perhaps it would be better to just use wx.FontDialog than to try to create a custom font dialog here.

Michael

[cmbarton]

I see now why a custom font dialog is being used--to match the font commands of ps.map. I've managed to fix the original problem in this report, but now there is a further related problem.

ps.map seems to use special font names like "Times-Roman" that are perfectly understandable but which do not match the relevant font name in wxPython. These are listed in the ps.map manual and hard coded into psmap.py. For example, the font "Times-Roman" is one of the fonts listed in the ps.map manual but this is not the way this font face is referred to in wxPython. On the Mac, this font is called "Times New Roman" (with the word "New" and lacking hyphens).

If we are supposed to use real font names (i.e., those appropriate for a given platform) and those in the manual are just generic suggestions, they we can use wx.FontDialog with some translation of font attributes like color and pointsize. But if the font names listed in the ps.map manual are the only forms that are recognized, we need to somehow map between these hard coded font names in the ps.map module and their equivalents in wxPython across all 3 major platforms.

Michael

[hamish]

Replying to cmbarton:

ps.map seems to use special font names like "Times-Roman" that are perfectly understandable but which do not match the relevant font name in wxPython. These are listed in the ps.map manual and hard coded into psmap.py.

AFAIU these are hardcoded in your printer / the PostScript definition, which is why they differ from whatever fonts are installed in your system. The two sets are completely independent, any overlap in names is just coincidental.

ps.map man page:

  font font name
       The  name  of  the  PostScript font.  Fonts present in all Post-
       Script implementations are: ...

depending on your make/model of postscript printer you may have access to more options...

embedding a truetype font from the OS into a PDF is another matter, I'm not sure if that is possible given our ps2pdf distilling method.

Hamish

[cmbarton]

OK. That means we need to use the font names in the manual or find a Python command that will reveal the names of any installed PS fonts.

The code that is breaking here is trying to use the PS font name as a TrueType font to estimate the size of the text box for placement in the graphical page representation. This won't work. It only seemed to work because of the fact that some TrueType fonts and some PS fonts have the same name.

So we need a different way to estimate the size of the text box.

Michael

[hamish]

Replying to cmbarton:

The code that is breaking here is trying to use the PS font name as a TrueType font to estimate the size of the text box for placement in the graphical page representation. This won't work. It only seemed to work because of the fact that some TrueType fonts and some PS fonts have the same name.

So we need a different way to estimate the size of the text box.

hmm, well we know exactly how tall the text will be (10/72" for 10pt, 12/72" for 12pt, ..) but not how wide for proportionally widthed fonts. We can probably figure out the aspect ratio for a fixed width font like Courier and just use that knowing it won't be any wider. (???)

Hamish

[cmbarton]

I think I've found a way to solve this.

[cmbarton]

OK. I think I've fixed this. Please test. It is r48193 in trunk only right now. Especially check to make sure that Times displays correctly. It works on my Mac but I'm not positive that it works on other systems (hopefully so).

There is one issue remaining. I've fixed it so that it recognizes multiline text. This works for the box outline drawn in the layout window and in the preview too. But the layout window also shows the text itself and not just the text box outline. The text being printed to the layout window somehow is not getting line breaks, even though they seem to be in the original text string stored for display.

The relevant line here is 1558 of psmap.py if anyone wants to see why the layout text is not breaking correctly.

[cmbarton]

Any interest in renaming the "Hard Copy Output Utility" to something like "cartography layout", "print layout", or "map layout"? Other suggestions?

Michael

[hamish]

"cartographic composer" ??

as for newlines being respected I think that's dependent on the various commenting instructions, some want '\n', some can use real newlines, not sure, would need to go through and see what's implemented and what works which way before coming up with a general solution.

Hamish

[glynn]

Replying to cmbarton:

OK. That means we need to use the font names in the manual or find a Python command that will reveal the names of any installed PS fonts.

PostScript fonts are installed on the printer, not the computer. There is no guarantee that it's possible to read information from the printer (there might not even /be/ a printer; you might just be generating a file).

The code that is breaking here is trying to use the PS font name as a TrueType font to estimate the size of the text box for placement in the graphical page representation. This won't work.

The only way to do this is to have AFM/PFM (font metrics) files for the fonts in question, and to use the data which they contain. This is made more complex by the fact that PostScript uses kerning by default, so you can't just sum the widths of the individual characters.

[cmbarton]

The main question is how close does this need to be for text placement. Also, we don't want the module to raise an error when it's only trying to figure out the size of a layout box.

The way I've got it set up now is that it will try to use typefaces with names Times, Helvetica, or Courier, depending on which one of these ps.map fonts is picked. If it can't find one, it will revert to the "default" font family for the system. This can be fine tuned.

Perhaps it would be better just to pick the corresponding font family from wxPython (e.g., wx.FONTFAMILY_SWISS for Helvetica) and not worry about finding a particular typeface.

[cmbarton]

I've been trying to work out the issues with management of color for text objects (including the 'map info' text object). The behavior is as follows:

1) If border or background color is enabled but a color is not explicitly set, it raises the error of 'ps.map exited with a 1' (NB: this is a really useless error).

2) If a background color or border color is set for a text object it seems to show up in the preview and final output pdf.

3) If a background color or border color is set of a map info object, it may or may not show up in preview and output. I've yet to come up with a sequence of steps that make this happen or not.

There are 2 sets of dictionaries of settings maintained by the ps modules. 1 set is a dictionary for each class of function (text, legend, map info, etc); the other is a single large dictionaries of "instructions" that are used to build a ps.map script. AFAICT, the problems in # 1-3 above are probably a result of incomplete or incorrect updating between these two dictionary sets, and possibly between the dictionaries of settings and the actual interface controls.

Nothing is standing out to me that is incorrect so far. So I'm recording this in case another set of eyes wants to take a look sometime. I'm not sure whether it is worth it yet to backport the changes to the GRASS 6 branches I've done until these other issues are solved or not. It is working better than it was, but there are still these inconsistencies.

Michael

[annakrat]

Replying to cmbarton:

The way I've got it set up now is that it will try to use typefaces with names Times, Helvetica, or Courier, depending on which one of these ps.map fonts is picked. If it can't find one, it will revert to the "default" font family for the system. This can be fine tuned.

Thanks for the patch, I changed a little (r48220) the makePSFont method, it was not working for me.

Anna

[annakrat]

Replying to cmbarton:

1) If border or background color is enabled but a color is not explicitly set, it raises the error of 'ps.map exited with a 1' (NB: this is a really useless error).

I cannot reproduce this error, do you talk about map info or text?

2) If a background color or border color is set for a text object it seems to show up in the preview and final output pdf.

I fixed the background color of text in draft mode. I tried to draw the text border in draft mode but it kept disappearing. I couldn't find the problem so I left it without it. Maybe a tooltip or a static label could inform user that not all features are visible in draft mode (like text highlight).

3) If a background color or border color is set of a map info object, it may or may not show up in preview and output. I've yet to come up with a sequence of steps that make this happen or not.

The color in draft mode is always blue and it has no other meaning. In preview mapinfo background color depends on its position, see #192

[martinl]

Replying to annakrat:

Thanks for the patch, I changed a little (r48220) the makePSFont method, it was not working for me.

Note: please backport (after some testing) relevant changes to devbr6, the code of wxGUI in this branch should be as much as closed to trunk.

[martinl]

Replying to martinl:

Note: please backport (after some testing) relevant changes to devbr6, the code of wxGUI in this branch should be as much as closed to trunk.

And of course bug-fixes should go also to relbr64.

[cmbarton]

I agree about the importance of backporting. But I'd like to get the current bugs fixed completely and tested before backporting.

Michael

[cmbarton]

Replying to annakrat:

Replying to cmbarton:

1) If border or background color is enabled but a color is not explicitly set, it raises the error of 'ps.map exited with a 1' (NB: this is a really useless error).

I cannot reproduce this error, do you talk about map info or text?

2) If a background color or border color is set for a text object it seems to show up in the preview and final output pdf.

I fixed the background color of text in draft mode. I tried to draw the text border in draft mode but it kept disappearing. I couldn't find the problem so I left it without it. Maybe a tooltip or a static label could inform user that not all features are visible in draft mode (like text highlight).

3) If a background color or border color is set of a map info object, it may or may not show up in preview and output. I've yet to come up with a sequence of steps that make this happen or not.

The color in draft mode is always blue and it has no other meaning. In preview mapinfo background color depends on its position, see #192

I'm close to fixing this, but have not yet committed those changes because they still have a few weird inconsistencies that have to do with updating after a drag event. I'll see how your changes mesh with mine. It's a pretty busy day today so I might not get to it until the weekend.

Michael

[annakrat]

Replying to cmbarton:

I'm close to fixing this, but have not yet committed those changes because they still have a few weird inconsistencies that have to do with updating after a drag event. I'll see how your changes mesh with mine. It's a pretty busy day today so I might not get to it until the weekend.

I appreciate your help however it would be more efficient if I try to fix the problems first because I understand the code better (as the author). On the other hand it's always better if someone else can understand and maintain the code.

Maybe you could summarize the problems and inconsistencies you encountered because I'm getting quite confused. Some problems may be platform specific, some inconsistencies in wx.psmap have their origin in ps.map module and I can explain them more.

Thanks Anna

[cmbarton]

I just committed the fixes I've been working on the past several days, but also incorporated all your changes prior to committing.

r48226

This seems to fix all prior problems except for a very weird one that I hope you have some insight into. For map info, the background and border shows up fine if the map info text is positioned in the top half of a page. If it is positioned in the bottom half of the page, the text displays fine, but the background and border disappear. Even odder, this behavior does NOT happen with the text objects.

If this tests out for other systems, maybe it can be backported, though the map info behavior is still not quite right.

Michael

[hamish]

Replying to cmbarton:

This seems to fix all prior problems except for a very weird one that I hope you have some insight into. For map info, the background and border shows up fine if the map info text is positioned in the top half of a page. If it is positioned in the bottom half of the page, the text displays fine, but the background and border disappear. Even odder, this behavior does NOT happen with the text objects.

that's a known problem, see #192 comment 5.

​https://trac.osgeo.org/grass/ticket/192#comment:5

Hamish

[cmbarton]

Ah. Glad I didn't spend a lot of time trying to fix this particular issue ;-)

Michael

[annakrat]

Michael, can we close this ticket or are there any issues I forgot? All recent changes are backported.

Anna

[cmbarton]

Yes, close.