Re: Why choose Debian on server
On Wed 09 Jan 2019 at 20:43:19 (+0000), Brian wrote:
> On Wed 09 Jan 2019 at 12:47:42 -0600, David Wright wrote:
> > 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.
>
> That's spot-on, but do not think I am wedded to this technique. If I had
> a desperate to print a one-off (like the originator of this sub-thread)
> I would use it but would be cogniscent of its limitations. Manipulating
> images within the printing system is fraught as far as I am concerned.
I have discovered, through using this Take a Screenshot command (sort
of in anger), that it pays to hit End (or scroll there) before taking
the shot. When imaging this page (which prints poorly here)
https://www.howtogeek.com/112888/3-ways-to-access-your-linux-partitions-from-windows/
the shot was, at first, taken before all the diagrams had been fully
rendered.
> Curt informatively posted:
>
> https://lists.debian.org/debian-user/2019/01/msg00447.html
>
> A twist with the page he refers to is that getting the whole page with a
> right click is not possible at this site.
Confirmed here.
> > > > 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.
>
> CUPS itself has removed or deprecated such options:
>
> https://github.com/apple/cups/issues/4010
>
> It is cups-filters which carries the flag now.
>
> > > > 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
>
> An ordinary user shouldn't have to do this. OTOH, an ordinary user
> should not feel it is acceptable to impute motives and spread false
> information. A skilled user (such as the starter of this sub-thread)
> could have copied and pasted or used 'lynx -dump ....." to get what
> was wanted.
>
> It's a pain, But needs must on occasion.
A fairly simple script: read the image pixel size, compute the slice
heights using the paper's aspect ratio, allowing for desired overlap
between pages (and I also make allowance for my printer's excessive
top margin, assuming I'm going to actually put marks on paper). The
tricky bit is finding the needles (-crop, -extent and -page) in the
haystack that is man convert (and its web page), and then using
convert twice, once to generate each image section, and again to
turn this section into a PDF page.
Finally, pdftk catenates the collection of pages into a single
document. No interaction required.
Cheers,
David.
Reply to: