Re: [lmi] Group-quote PDF: whitespace changes, and enhancement

[Vadim Zeitlin]

On Thu, 8 Feb 2018 21:48:20 +0000 Greg Chicares <address@hidden> wrote:

GC> Vadim--We're testing group-quote PDFs, whose code changed as part of
GC> the XSL replacement. Kim and I both notice minute whitespace changes
GC> with HEAD vs. production releases, so first I'd like to ask whether
GC> that was strictly contrary to your intentions...

 I'm afraid it indeed was. At least I don't remember changing anything in
the group quotes intentionally. Reviewing the changes now, I thought for a
moment that 01be23a639e7aca8cebc96b5a4e36e22e4c0386b, which allowed to
reduce margins in the tables, could be blamed for this, but this commit
wasn't supposed to change anything for the group premium quotes table,
which has a variable-width column, and I don't see anything else that could
be responsible for this.

GC> Context: If the "Insured Name" input that's copied into the "Participant"
GC> column of a group quote is rather long, it spills into the "Issue Age"
GC> column (as it always has). With a this datum [remove the quotes]:
GC>   "Director, Global Solution Architecture" [see footnote below]

 Hmm, when I produce the group premium quotes by editing the InsuredName in
the same census I used for the PDF pagination bug, I don't see any overflow
here because the "Participant" column is very wide (~60% of the page
width). What exactly do I need to see it?

GC> Kim used to have a slight space between the "Participant" and "Issue Age"
GC> columns, but the space is no longer present with the code in HEAD. When
GC> I ran it with both HEAD and a six-month-old release, I saw no space in
GC> either circumstance--it looks the same to me, even if I enlarge both to
GC> 400%, and even if I use multiple PDF viewers (evince, imagemagick, gimp).

 Sorry, does this mean that you and Kim see different results with a
version from 6 months ago or that the change happened more than 6 months
before (in which case it can't be due to any changes done as part of
illustration PDF generation, of course, which would be reassuring, even if
not immediately helpful)?

GC> Anyway, when I saw this, it struck me that letting "Insured Name" spill
GC> into the next field isn't what spreadsheets would do, so it looks like
GC> an error. And a really long "name" like:
GC>   "President & CEO and all-around Real Good Guy"
GC> produces output like this, more or less:
GC> 
GC>   Participant                  |  Issue Age
GC>   -----------------------------|----------------
GC>   President & CEO and all-aroun|d Real БⰝod Guy
GC> 
GC> because age "60" is overstruck with "Good". I think that proves that
GC> truncation would be a good enhancement, at least for this "Name" field
GC> and probably for the whole main table. I'm pretty convinced, but Kim
GC> is lukewarm; what's your opinion?

 I think that the ideal solution might be to allow slight overflow if it
doesn't actually result in the text overlap such as above. But this is a
bit tricky to implement, and I'd definitely prefer to truncate at the
column boundary rather than to not truncate at all, resulting in horrors
such as the ASCII art above (and for once it's the contents and not the
presentation style which is the problem!).

GC> Earlier messages on this list discuss truncation vs. wrapping, in the
GC> context of the boxed "Summary", but I've found no discussion here of
GC> truncation vs. overflowing, though it's clear that I had noticed small
GC> overflows in the past and considered it okay. Now I'm inclined to change
GC> my mind. This is probably quite deep in code that I'm not really familiar
GC> with, so can you say whether it's easy enough to change?

 It should be pretty simple: we just need to set the clipping rectangle
before calling DrawText() in wx_table_generator::do_output_values(). The
only potential problem is that I haven't used clipping with wxPdfDC yet,
but it's definitely implemented in its code and so I think it has all
chances to work.

 Please let me know if I should do this,
VZ