Legends Print on new line - and other issues

[geekdenz]

When printing legends and setting inline: true to give a maxHeight of the legend, so that legends are printed on a new column if they overflow, the legend chips are printed on the next line. In fact, as far as I remember, the new line problem also happens when inline: false is set.

If you need more info to reproduce, I can provide that when I have a bit more time.

[geekdenz]

Update:
When setting "iconBeforeName": true in the "class" property of the json that is sent to the print module, it prints the legend chip before the "name".

Like so:
"legends":[{"name":"Potential Natural Vegetation","classes":[{"iconBeforeName":true,"name":"Unclassified","icon":"http://maps-b/cgi-bin/mapserv?...", ...

However, this doesn't fix this problem unless one, again, specifies "inline": true.

I think that
inline: true
should not have different behavior for the legends printing in a new column.

However, from the code, I can see the difficulty with that. I will have a go at fixing it, but cannot promise anything.

Is the person who did that logic still around? If so, don't hesitate to contact me any time, as your insight might make fixing this problem a lot easier.

The main point of this post is that
inline: true
should not affect the overflow logic.

Please correct me if I'm wrong but I had a chat to people at the office and they agreed with me.

[jesseeichar]

I don't know who wrote that code. It is likely a combination of people, though I can't say for sure. That said, your point makes sense to me (from the little I understand it).

[sbrunner]

Effectively it make sense !

[geekdenz]

Thanks for the quick answers!

Cool, so you think it makes sense to review a big portion of that code or even rewrite? It seems rather ugly to be honest. I was also planning to do some documentation and hopefully implement some unit tests while I'm at it.

[jesseeichar]

+1.

On Mon, Mar 11, 2013 at 10:56 AM, Tim-Hinnerk Heuer <
[email protected]> wrote:

Thanks for the quick answers!

Cool, so you think it makes sense to review a big portion of that code or
even rewrite? It seems rather ugly to be honest. I was also planning to do
some documentation and hopefully implement some unit tests while I'm at it.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/33#issuecomment-14704519
.

[geekdenz]

Update:
I'm currently writing code to put the legend items into a table with 2 columns. The legend chip in one cell (column 1) and the description in the next cell (column 2).
However, I was thinking it might be better to make an overarching table to ensure that the inner tables (the 2 columns tables) have the same widths for columns 1 and 2.
Also, I'm not sure how to deal with the overflow (max height). I could calculate the total height like it was done, but maybe there is a more elegant way of doing it with a paragraph or so. Will have a google for that and iText.

[geekdenz]

Update:
I've written the code to include a table and even added optional CSS-style padding. Currently that's all in the landcare branch, but it needs some cleaning up and some test cases written. I will also test it with some other configuration settings. Hopefully, I didn't break anything. I will submit a pull request once I've done all that.

[geekdenz]

Update:
Assuming the legend items should be put into a (small) table with 1 or 2 columns. 1 for the legend text/name and 1 for the legend icon/chip.
Suggest we make the following changes and clarify meanings of (please +1 if you agree):
- !legends
? maxHeight: 0 # total maximum height of one legend item, i.e. the whole table, optimum will be calculated.
? maxWidth: 0 # total maximum width of legend items, i.e. the whole table, optimum will be calculated.
? maxIconWidth: 8 # maximum width of the legend chip/icon itself
? maxIconHeight: 8 # maximum height of the legend chip/icon itself
? defaultScale: 0 # do we still need this? If yes, scale the icon by this number of non-null
? inline: true # legend icon/chip appears on the same line as the text
? classIndentation: 20 # horizontal ident space for each class item in the legend
? layerSpace: 5 # vertical space AFTER the legend items
? classSpace: 2 # vertical space AFTER class legend items
? backgroundColor: #FFFFFF # Does this even work? Doesn't # introduce a comment?
should maybe be:
? backgroundColor: FFFFFF # background color of the WHOLE legend block
? layerFont: Helvetica # font used in the layers' legend items' texts/names
? layerFontSize: 10 # font size for layers (not for classes)
? classFont: Helvetica # font for class legend items
? classFontSize: 8 # font size for classes
? fontEncoding: Cp1252 # font encoding, same as before
? columnMargin: 3 # same as before margin (like in CSS) for each column

I'm basically implementing it now like this, but have changed significant parts of the code to something I would understand better. I calculate the widths and heights of things based on how they render onto a temporary PDF file. Otherwise, it doesn't seem possible to get accurate widths and heights of things. pdfPTable.getTotalHeight() returns 0 for tables that have data in them but are not rendered onto a "physical" PDF file. This just means that a file on disk has to be opened and written to but it can be deleted after the print is complete.

[geekdenz]

Update:
OK, I should have thought about this more before I started implementing...

Anyway, the design decisions/conclusions are:
We should adopt the CSS box model where possible and the whole legends block needs to adhere to more common standards. I realise that we cannot implement CSS exactly, but should stay close to the standard.
So, I suggest we use (only) the following:

backgroundColor: apologies, this actually works as it is currently.
maxWidth/Height: maximum TOTAL width/height of the legends block as it makes more sense in regard to the other blocks
iconMaxWidth/Height: maximum width/height of the cell for the icon. This excludes border and padding as in CSS
textMaxWidth/Height: maximum width/height of the cell for the text/name of the legend item (class or layer name), excludes padding and border
iconPadding: CSS notation like padding (a b c d, a b=d c,, a=c b=d a=b=c=d) but without units because the default unit is points
textPadding: same as iconPadding for the text component
columnPadding: padding for each column
maxColumnWidth: excludes columnPadding BUT includes legend item total width, i.e. includes optimal icon width + optimal text width + their respective padding (and border), border being either true of false for now

horizontalAlignment: (default) alignment of legend items
layerSpace: spacing after layer legend item
classSpace: spacing after class legend item

fonts etc we keep.

[sbrunner]

Hello,

defaultScale: 0 # do we still need this? If yes, scale the icon by this number of non-null

Yes we need this, when we gets different legends from mapserver we obtain images at different size.
By default the mapfish print display them at 72 dpi than we have big images.
It we reduce them with iconMaxWidth or iconMaxHeight the different legend parts well be incoherent.
With defaultScale we can reduce all the legends icons with the same scale.

For all other +1 :-)

[geekdenz]

Can I assume that the iconMaxWidth/Height is a hard maximum and the defaultScale always makes the image smaller or equal in size than that.

E.g. an image is 20x20pt, iconMaxWidth=40, iconMaxHeight=40, defaultScale=2.5, This makes the image 50x50pt but then the hard max of 40 is applied, so the image becomes 40x40pt.

Another counter example would be an image is 20x20pt and the defaultScale=1.5. The picture becomes 30x30pt and iconMaxWidth/Height doesn't need to be applied because it is smaller.

Please confirm.

[sbrunner]

exactly :-)

[geekdenz]

Update:
Yay! Got it all working smoothly. Couldn't test all possible scenarios, but it seems the legends are now pretty flexible and robust. Will merge into my local master branch and submit a pull request as soon as we've done some more testing. Also, added a mini feature where the scale of a class item can be changed within the spec JSON submitted from the client. We need this feature to potentially show a bigger legend for specialised layers. Thanks to the defaultScale/scale this was also possible.

[geekdenz]

Can close this as it is resolved.