[reportlab-users] Custom page lengths

Glenn Linderman v+python at g.nevcal.com
Tue Apr 12 19:32:35 EDT 2016


On 4/12/2016 9:40 AM, Tim Roberts wrote:
> Glenn Linderman wrote:
>>
>> Nearly every device has some sort of PDF viewer; multiple screen size 
>> abound.
>>
>> Already coded: formatting the data to different widths so that it is 
>> easier to read on various devices from cell phone to tablets, with 
>> reasonable font sizes and not needed to scroll sideways.
>
> I need to point out that this is completely contrary to the stated 
> purposes of PDF.  A PDF document is supposed to be the same 
> everywhere.  It is not supposed to depend on the viewing device. 
> That's exactly what the "P" is for.  What happens when  your phone 
> users try to route their document to a printer?  Are they going to get 
> 10 words per page?

Any particular PDF would, indeed, be the same everywhere... hence the 
"P" is preserved.

It is not expected that _anyone_ would ever even _think_ of printing 
these narrow documents. A printable one is also provided.  These are 
clearly marked for use with small devices, not intended for printing.

The problem, though, is that the printable version is too wide for 
little screens, and lots of scrolling is required both horizontally and 
vertically to see the info.  Some PDF viewers on phones/tablets have a 
"reflow" feature, but that winds up breaking lines at random spots... 
sure it fills the screen, but info is hard to find because the line 
structure has been ruined. The narrow formats I'm generating are still 
usable, unlike those that are "reflow"ed (if you want to complain about 
the missing "P" in PDF, the viewers that implement "reflow" certainly 
are breaking that rule).

Leaving the only remaining problem, the inordinate amount of vertical 
scrolling required when the information on a particular page is small 
compared to the information on the page with most content... which 
brought to me my question.

Generally, people will be using the PDF bookmarks to reach the page of 
concern. But once there, they might want to go forward or backward a few 
"long" pages with lots of blank space at the bottom... so I'd like to 
make the pages with less content shorter.

> I can't help but think that you should be using HTML for this, not PDF.

It's a thought, but HTML doesn't have much concept of pages. So to use 
HTML, I'd have to somehow invent that concept, since this data is 
strongly organized by pages.  Yeah, it has anchors, and so I could do 
the index / PDF bookmarks pretty well...  I guess a "page break" could 
just be a thick horizontal line...

Browsers, though, do a lot of incompatible fakery regarding screen size 
& DPI, and it can be nearly impossible to figure out what size the 
screen actually is, to know how much data to put on it.  I guess I could 
just format it for so many mm width like I am the PDFs...

Hmm. In HTML-land, a tad bit of Javascript could mean that the document 
could let the user choose the width, if the Javascript can't really 
figure out the right choice, meaning I would only need one document, 
instead of 4, as presently envisioned with the PDF solution.

I'm still open to suggestions regarding dynamic page length... but I 
will explore doing this with HTML, and see what feedback I get from the 
users.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist2.pair.net/pipermail/reportlab-users/attachments/20160412/4b46b580/attachment.html>


More information about the reportlab-users mailing list