Re: Custom page lengths
Glenn Linderman <[email protected]>
| Newsgroups | gmane.comp.python.reportlab.user |
|---|---|
| Message-ID | <[email protected]> |
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.