Re: Using browser results for page references (was: Prioritisation)

On Thu, Aug 6, 2015 at 12:50 AM, Alan Stearns <stearns@adobe.com> wrote:

>
> 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>
> Resent-Date: Wednesday, August 5, 2015 at 3:35 PM
>
>
> On Tue, Aug 4, 2015 at 8:03 PM, Kaveh Bazargan <
> kaveh@rivervalleytechnologies.com> wrote:
>
>>
>>
>> On 4 August 2015 at 18:50, Bill Kasdorf <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.
>


You may be right that this will forever be unrealistic. But maybe not:
there are not that many browser engines out there and fonts can be bundled
with the page. And for this authoritative page one could possibly even
layout every word or letter directly in JavaScript -- maybe even draw the
entire thing on a canvas.

But then again, at that stage it may just be easier to just bundle a a list
that says how many letters went on each page or alike in the version that
went into print, and then the JavaScript can use that as information on
what went were.