Using browser results for page references (was: Prioritisation)

From: Johannes Wilm
Date: Wednesday, August 5, 2015 at 3:34 PM
To: Kaveh Bazargan
Cc: Dave Cramer, Richard Ishida, W3C Digital Publishing Discussion list
Subject: Re: Prioritisation
Resent-From: <public-digipub@w3.org<mailto:public-digipub@w3.org>>
Resent-Date: Wednesday, August 5, 2015 at 3:35 PM


On Tue, Aug 4, 2015 at 8:03 PM, Kaveh Bazargan <kaveh@rivervalleytechnologies.com<mailto:kaveh@rivervalleytechnologies.com>> wrote:


On 4 August 2015 at 18:50, Bill Kasdorf <bkasdorf@apexcovantage.com<mailto:bkasdorf@apexcovantage.com>> wrote:
A quick clarification. I am quite sure that in her e-mail Deborah is using the term "pagination" to mean "maintaining a record in the digital file of where the page breaks occur in the paginated version of record." That's essential to accessibility and other useful things as well (citations, cross references, indexes, etc. in a world in which print is still considered the version of record and references to its page breaks are common.) That's not the same as making the _rendered pages_ in the digital file replicate those in the print.—Bill K

[...]


But Bill, how do we make the page breaks in the electronic version to be the same as those of the print pages unless we have the same elements and layout? For instance if a floating figure is missing from an electronic page, do we just make a short page and break where the paper copy breaks? That would lead to very ugly results.


The end device should be able to both figure out what page numbers would be in the normal sized output AND what it is on the actual device. All without having to add extra meta data about where non-explicit page break occur.

So basically it renders the pages twice:

A) Once in the original size. This can be done in a way so the end user doesn't actually have to see it. The page numbers are retrieved from this version. A could be made to be exactly equal to the print version (or the other way round: in order to create the print version, one simply prints out A).

Unless you use the same browser, platform, version, font supply, etc. you are almost guaranteed to not get page numbers that match the printed version. I’m completely behind the idea of using javascript-convoluted browser rendering to produce printed books, but A) won’t give you the immutable page numbers some are looking for.



B) A second time for the user to see it in the size appropriate for the zoom level and  screen size.

There are various ways this could be presented to the user in the User Interface. For example the "Jump to page number" function could be using the page numbers retrieved from A but then jump to the correct location in B. And the page numbers shown in the corner of the pages could also be the ones retrieved from A (that would mean several pages in a row could be displayed with the same page number and one B page could have two page numbers if it happens to span over the break between two A pages.