Re: Prioritisation

Hey,

On Tue, Aug 4, 2015 at 7:50 PM, 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
>
>
>

I think it should be possible to offer both things (dynamically paged pages
AND making sure that page 32 contains the same content on different
devices), possibly with a few tiny changes to rendering engines [1]. Then
the insertion of manual page breaks are only needed if there is a specific
reason to end a page before it is entirely filled.

Of course this means that:

A) Pages will always need to contain the same amount of text/content on all
devices. That may not make sense for some tiny mobile screens for which it
may make sense to use a lot more pages.
B) One needs to define the size of a single page on beforehand.
C) Fonts used for rendering need to be the exact same.

For issue A I could think of some solutions that should work for most
cases: For example, one may use the same pagination size on 80% of screens
by adding extra margins or zooming further in, and in the 20% remaining
cases of really tiny or really huge screens, one uses two types of pages:

* One system used for flipping through pages on the system in question
where page size equals screen size.
* A second system of pagination that uses the standard page size as
reference that is used to assign page numbers, etc. . The device with the
small/huge screen that displays small pages should not have problems
figuring out what content would have gone on what page if the page size had
been the standard size.

How that all would be presented graphically to the user would come down to
the preferences of those doing the book design and designing the JS needed
to set this up.



[1] At the Frankfurt Bookfair in 2012, we tried to show the first version
of the browser-based book-page design that I have been working on quite a
bit, but we had a browser on the server create PDFs. Even though everything
should have been the same, we found that the browsers on server and demo
machine cut the page contents slightly differently. Our investigations went
as far as that the dpi of the screen where the browser was running had some
influence, even when it shouldn't, but we never quite found out what the
reason was. At any rate, the differences were miniscule, but it did lead to
some words/letters being moved on to the next page some times. I haven't
investigated whether that would still happen in 2015.





> *From:* Kaveh Bazargan [mailto:kaveh@rivervalleytechnologies.com]
> *Sent:* Tuesday, August 04, 2015 1:37 PM
> *To:* Bill Kasdorf
> *Cc:* Dave Cramer; public-digipub@w3.org
> *Subject:* Re: Prioritisation
>
>
>
> Thank you Dave and Bill
>
>
>
> Dave I totally take your point about that horrendously long web page. So I
> agree that we need some kind of paginated layout so you finish one chunk
> and go to the next. Therefore I also like reading paginated text – at least
> for long prose. (In fact, I prefer beautifully typeset pages printed on
> good quality paper!)
>
>
>
> My issue is that paginating for an interactive reader like an iPad is
> totally different to paginating for paper. On paper there is no
> interactivity, no accessibility (apart from having readable fonts), and no
> reflow. It is quite natural to flip a page to look at a figure floated onto
> the next page and very quickly flip back and forth. And quite natural to
> have footnotes. But on an electronic device it is hard to do that, yet
> easier to hover the mouse and have a note pop up.
>
>
>
> So while I fully support pagination for on screen reading, done by the
> browser, but I cannot see the advantage of floating figures and tables,
> footnotes, or traditional indexes for that matter, in an electronic reading
> environment.
>
>
>
> As I write this I see Deborah's mail about electronic and paper versions
> having the same pagination. That is a constraint that prevents good print
> as well as good online pagination. My solution would be to do away with
> page numbers and refer to paragraphs, which would then apply to any
> reflowing version too!
>
>
>
> I feel that for straightforward text it is great that we can have one
> engine producing the same pages for online and for print. But for complex
> documents, say critical editions, or STM content, we can take the XML
> document (or very strict HTML) and pass it to a dedicated pagination engine
> to do the one thing it is good at.
>
>
>
> Kaveh
>
>
>
>
>
>
>
> On 4 August 2015 at 18:11, Bill Kasdorf <bkasdorf@apexcovantage.com>
> wrote:
>
> Also, it's important not to confuse "pagination" with "fixed layout." Most
> eReaders provide a paginated view that is still reflowable. And most
> readers (that is, the human kind) prefer that for reading long form
> content. Even reading the New York Times on my iPad, I have it set to
> paginated rather than scrolling view. Way easier (especially on a treadmill
> in the morning).
>
>
>
> Of course an important underlying issue here is the EPUB+WEB vision:
> ideally, we'd like the same file (or collection of resources, whether
> packaged or not, that constitutes a publication) to be able to behave the
> same online and offline. Best to have the same standard, non-proprietary,
> ubiquitous infrastructure native to browsers able to deliver that without
> requiring separate software.
>
>
>
> --Bill Kasdorf
>
>
>
> *From:* Dave Cramer [mailto:dauwhe@gmail.com]
> *Sent:* Tuesday, August 04, 2015 12:32 PM
> *To:* public-digipub@w3.org
> *Cc:* public-digipub@w3.org
> *Subject:* Re: Prioritisation
>
>
>
> On Tue, Aug 4, 2015 at 11:55 AM, Kaveh Bazargan <
> kaveh@rivervalleytechnologies.com> wrote:
>
> Forgive me for a very basic question, but it is a devil's advocate type of
> question. And if this is not the place to ask this perhaps you can direct
> me to any relevant discussions.
>
>
>
> My very basic question is, why do we need to "paginate" in the browser in
> the first place? Why not keep the browser for reflowing and interactive
> text, which is what it is good at, and use a standard mark-up pagination
> system (TeX/LaTeX would be my choice) to do what that is good at. If
> another system has already solved problems like footnotes and floating
> figures, what exactly is the drive to reinvent that in the browser?
>
>
>
> Again, apologies if the answer is really obvious!!
>
>
>
> Regards
>
> Kaveh
>
>
>
>
>
>
>
> I find that reading long-form content is easier if that content is
> paginated [1]. Much of the reading we do is now on screens, and HTML+CSS is
> a very nice way of rendering content that can adapt to a variety of screen
> sizes and types, not to mention the personal needs of the reader. So I
> think it would be tremendously valuable to have the ability to paginate in
> the browser, thus combining some of the design capabilities of print with
> the flexibility and ubiquity of the web. This would make it easier to
> develop ebook reading systems and give browser users more choice in how
> they read, while preserving the accessibility advantages of the web.
>
>
>
> Regards,
>
>
>
> Dave
>
>
>
> [1]
> http://www.clickhole.com/blogpost/time-i-spent-commercial-whaling-ship-totally-chang-768
>
>
>
>
>
>
> --
>
> Kaveh Bazargan
>
> Director
>
> River Valley Technologies
>
> @kaveh1000
> +44 7771 824 111
>
> www.rivervalleytechnologies.com
>
> www.bazargan.org
>