lmi
[Top][All Lists]
Advanced

[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?".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]