[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Cover-page simplification

From: Greg Chicares
Subject: Re: [lmi] Cover-page simplification
Date: Wed, 15 May 2019 02:43:25 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 2019-05-15 01:28, Vadim Zeitlin wrote:
> On Wed, 15 May 2019 00:33:47 +0000 Greg Chicares <address@hidden> wrote:
> GC> On 2019-04-24 17:47, Vadim Zeitlin wrote:
> GC> > On Tue, 23 Apr 2019 16:29:15 +0000 Greg Chicares <address@hidden> wrote:
> GC> > GC> Should cover_page derive from standard_page rather than 
> numbered_page,
> GC> > GC> in the hope that numbered_page::get_extra_pages_needed() will DTRT 
> for
> GC> > GC> the cover page?
> GC> > 
> GC> >  get_extra_pages_needed() definitely should DTRT, but the problem is 
> that
> GC> > we can't define the cover page contents using just the HTML template,
> GC> > precisely because of the rectangle mentioned below. So as long as we 
> keep
> GC> > this rectangle, we can't derive cover_page from standard_page.
> GC> 
> GC> Now, we can, because we've removed that rectangle.
>  This looks a bit like cheating, but if nobody objects to its removal, this
> is definitely the simplest solution.

It might be cheating if it were specified as desirable for some reason,
and we removed it to suit our own convenience. However, the rectangle
was added by some former employee for no known reason, and today nobody
wants it. Actually, such borders are hardly seen in modern typography;
the simple "rule" (horizontal line) now used instead looks much more
modern, and is of course more consistent with other PDF pages. We can
regard aesthetic improvement as the driving force, and simplification
of the code as merely a most welcome incidental benefit.

> GC> > GC> Is there any reasonable way to make the big rectangle on the cover 
> page
> GC> > GC> adapt to the height of any footers we might add there? (If that's 
> not
> GC> > GC> easy, then we might ask whether that rectangle is truly worthwhile.)
> GC> > 
> GC> >  The rectangle on its own is not a problem, as it's just drawn around 
> the
> GC> > cover page contents. The problem is the ugly hack in cover.mst adding 
> just
> GC> > enough of <br> tags to make the cover page contents fill up the page 
> area.
> GC> 
> GC> Today I was very glad that you'd mentioned that, because with the
> GC> changes committed a few hours ago I had to remove some of those
> GC> <br> elements.
>  This problem still remains, however, rectangle or not... Unfortunately I
> still haven't had any breakthrough and can't propose any good solution for
> handling this.

What is the real purpose of those <br> elements anyway? AFAICT, now
they serve only to position the logo and a couple of other elements
that are placed toward the bottom of the page. If so, then we could
probably put those elements and the logo here in class cover_page:

    // Only the lower part of the footer is wanted here.
    std::string get_upper_footer_template_name() const override
        return std::string {};

using a mechanism that is already present, and unused today. Then,
I think, these elements would grow from the bottom, and the other
elements would grow from the top, so any space in the middle would
automatically be blank, and we'd need no <br> elements, right?

reply via email to

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