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: Sun, 11 Mar 2018 16:51:30 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0

On 2018-03-10 19:22, Vadim Zeitlin wrote:
> On Sat, 10 Mar 2018 12:09:50 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Thanks, this change fixes the problem at hand, so I've committed it.
> GC> But now please help me understand it: I think I just don't quite
> GC> understand exactly what the variable names mean.

Later, it dawned on me that column_margin_ must be bilateral, and I hoped
to reply to my message before you could, because it seems so obvious in
retrospect.

>  Anyhow, column_margin_ is the margin on the left _and_ the right of each
> column, i.e. every column has 2*column_margin_ padding effectively. Initial
> code contained a comparison of per-column overflow with column_margin_
> just because I thought it would be nice to keep at least 50% of the margins
> to avoid columns running too close to each other and, to be fair, this was
> documented in the comment
> 
>         // If we have only fixed columns, try to make them fit by decreasing
>         // the margins around them if this can help, assuming that we can
>         // reduce them by up to half if really needed.

Possessed by the notion that column_margin_ was on the left-hand side only,
I parsed the comment as erroneous. With the patch, the comment now seems to
require emendation, and I was about to change it like this:

-        // reduce them by up to half if really needed.
+        // reduce them to the extent necessary.

when it occurred to me...are we now potentially removing all space between
successive pairs of columns? Just below, we say:

    // We need to round up in division here to be sure that all columns
    // fit into the available width.

which remains correct, but then:

    // We are going to reduce the total width by more than
    // necessary, in general, because of rounding up above, so
    // compensate for it by giving 1 extra pixel until we run out
    // of these "underflow" pixels.

Is it still true that there's always at least one pixel left? And, if so,
is that enough? We've already established that "9" is five "PDF pixels"
wide; do we need, say, two "PDF pixels" between columns for readability?



reply via email to

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