Web lists-archives.com

Re: Why choose Debian on server

On Mon 07 Jan 2019 at 23:51:36 (+0000), Brian wrote:
> On Mon 07 Jan 2019 at 14:37:30 -0600, David Wright wrote:
> > On Mon 07 Jan 2019 at 18:21:07 (+0000), Brian wrote:
> > > On Sun 06 Jan 2019 at 18:13:58 -0600, David Wright wrote:
> > > 
> > > [...]
> > > 
> > > > BTW if this Screenshot method is meant to yield a "printable"
> > > > document, I haven't yet figured out how to print it sensibly.
> > > > $ lp -d PDF very-long-image.png   gives me the image on one page,
> > > > and looks, as it happens, like the sort of output that FF sometimes
> > > > gives when printing articles: a narrow column of minute text.
> > > 
> > > To nitpick, the claim was that the Raspberry Pi Stack Exchange page
> > > was printable. Whether the marks on paper satisfied a user in all
> > > regards wasn't touched on until now.
> > 
> > I think it's reasonable to demand a certain level of legibility.
> Indeed. That is why I am looking at printouts from Firefox and lp which
> nobody with reasonable eyesight would have any trouble reading.
> > > For me, printing the screen image obtained from my chosen page from
> > > the Print Preview of FireFox gave an acceptable output with a Custom
> > > Scale. It helped to choose Landscape mode.

I think I see what you're doing now: you take the snapshot in FF, then
open the snapshot in FF again and then use Print Preview to set the
scaling factor before you print it.

> > The landscape mode changes the output from a very tall image printed
> > on a portrait page to the same image printed across it instead,
> > reducing the scale by the golden proportion.
> > 
> > > 'lp -d.....' benefits from fiddling with the scaling= option and from
> > > orientation-requested=4.
> > 
> > This gets very involved. Having tried feeding convert with the image,
> > I see that it can produce a pretty faithful PDF which suffers only
> > from the usual problem of being overtall.
> Printing from Firefox is hardly involved. Basically, choose the scaling.
> Forget about lp; most people never use it directly.

Well, I couldn't see any scaling options in lp except fit-to-page
which would be fighting what one is trying to do.

> > If I was going to indulge in this very often (which I'm not) I think
> > it would be worth writing a script to run convert on page-size slices
> > of the image, outputting them as PDFs, and collate them into a
> > conventional multipage document with pdftk. It would be fairly simple
> > to compute the y-size by ratioing the x-size according to the paper
> > regime, and even allow for some overlap between pages (because one
> > doesn't know where to slice in between lines of text).
> Sounds more involved than using lp.

I've found that the package posterazor can split the FF image and,
trying it out, it seemed to be able to fit-to-width. It can also
yield overlapping pages so you don't get lines of print split across
pages as with your method.

But again, if I were having to do this regularly, I would prefer to
write a script rather than have to go through its 5-step interactive
dialogue on each occasion. Most of the degrees of freedom given by
posterazor are unnecessary because the values can all be computed.