[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] Group-quote PDF: whitespace changes, and enhancement
From: |
Greg Chicares |
Subject: |
Re: [lmi] Group-quote PDF: whitespace changes, and enhancement |
Date: |
Thu, 8 Feb 2018 23:46:48 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 |
On 2018-02-08 22:34, Vadim Zeitlin wrote:
> On Thu, 8 Feb 2018 21:48:20 +0000 Greg Chicares <address@hidden> wrote:
[...]
> 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?
You'd need to make "Supplemental amount" (Input::SupplementalSpecifiedAmount)
nonzero; but apparently you can't do that with the 'sample*' products. Let's
see...
File | Open | sample.database
Riders...TermIsNotRider: change from 0 to 1
Premiums...SplitMinPrem: change from 0 to 1
File | Save
File | Close
File | New | Census
[using 'skin.xrc']
Census | Edit case defaults
"Names" tab..."Corporation": change to "xyz"
OK, then click "Yes" on the messagebox
Census | Edit cell
"Names" tab..."Insured": change to "Director, Global Solution Architecture"
"Face" tab..."Supplemental amount": change to 234567
"Payments" tab..."Corporation payment": change to 1234
OK
Census | Print group roster | Print group premium quote to PDF
Well, that only took...way longer than I'd hoped. But you should see
Director, Global Solution Architecture45
and if you prepend "Senior " to the job title, you'll get something like:
Senior Director, Global Solution ArchiႯႧcture
(Asomtavruli is perfect for this).
> 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
Yes. Well, we think so. Mine is from six months ago (it says
"System version: 20170721T1310Z"), but I'm not sure how old hers is.
However...
> 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)?
...we thought that nothing had changed in the group-quote code for
a long time, until the very recent changes. I'd better ask Kim if
she can re-run with the 20170721T1310Z version, just to rule out
any code change we might have overlooked.
> 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.
You should have been a politician.
> 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!).
And I'm beginning to run out of unicode alphabets.
> 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,
Yes, please. Each hour I spend discussing this only deepens my
conviction. If anyone complains about the change, I'm perfectly
content to retort "and what does your spreadsheet program do?".