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 Mar 2018 15:38:46 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-08 12:46, Vadim Zeitlin wrote:
> On Thu, 8 Mar 2018 10:36:58 +0000 Greg Chicares <address@hidden> wrote:
> 
[...comparing old and new PDFs for tables that contain large numbers...]
> 
>  Thanks, I can see the issue and it's very visible on even the second page,
> where "Premium Outlay" value in the first row overlaps with the age in the
> new PDF, but not the old one.
> 
> GC>  - it seems less cramped, using more of the available page width;
> GC>  - in the first row of the table, the "Premium Outlay" column
> GC>    isn't wide enough to be clearly separate from the column to
> GC>    its left, and it slightly overlaps the column to its right.
> 
>  This can be "fixed" by using the same font as the old PDFs did, i.e. Times
> Roman instead of Helvetica used by the new PDF code:

[...patch...]

We think Helvetica is an improvement here.

>  With this change, the old and new PDF look closer to each other

They're less different, and there's about a one-en spacing between
the first-row numbers 109,890,000 and 100,051,590 that collided
without the patch. However, that spacing was perhaps five en in
the old PDF, which seems to widen all columns to use all the
available horizontal space.

Can the new PDF similarly apportion the available blank space (on
the right) among all columns? That would incidentally keep the
numbers from running into each other with Helvetica.

>  Also, new PDF still uses wider (by a factor of ~1.5) margins around the
> page than the old ones. AFAIR I did this intentionally because the old
> tables seemed to go uncomfortably close to the right page border to me, but
> if we need to fit more data into them, it probably should be reduced.

We think the new PDF should use the same margins as the old ones.
Wider margins probably are preferable in general, e.g. for normal
word-processed documents, but life-insurance illustrations are a
special case because they try to pack a lot of information into
every page. Whether or not that's tasteful, it's common practice.

We prefer the old PDF margins even for all-text pages, where the
new margins give a left-of-center feel. I'm not sure it's easy to
quantify that, but different people who've compared old and new
PDFs here uniformly have this impression. Perhaps the left and
right margins are equal, and the ragged text on the right side
adds some irregular white space to the right margin in some way
that makes the empty space on the right look larger than on the
left. I'm not sure that's the reason, but I'm sure that's the
impression we get.

>  The problem is that all this is still very ad hoc, i.e. there is no
> obviously right value to use for the page margins or for margins between
> the table columns. I chose something that looked reasonable to me, but now
> we see that it doesn't quite work and I'm going to change it, but nothing
> guarantees that we won't have to change it again in the future...

There's no guarantee, but I think we're close to the final layout
and won't be revisiting this again.

>  Anyhow, the first question is whether you'd like to switch to using Times,
> which is more compact than Helvetica?

No, our preference is Helvetica.

> Please note that this would affect
> the group quotes PDFs too, as written. It would, of course, be possible,
> and simple, to keep using Helvetica for those and use Times for the
> illustrations, but I'm not sure if it's a good idea to use inconsistent
> fonts in the output files produced by the same program.
Good point. Keeping Helvetica here also preserves similarity to
the group quotes, which were designed more recently and, I think,
more carefully than XSL-FO illustrations.



reply via email to

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