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.