W3C home > Mailing lists > Public > public-digipub@w3.org > August 2015

Re: Prioritisation

From: Kaveh Bazargan <kaveh@rivervalleytechnologies.com>
Date: Tue, 4 Aug 2015 18:37:03 +0100
Message-ID: <CAJ2R9ph7+cmwO9AcS=3UjAX2iM5MwiH_qoJT+GCV+BOSrNA5bw@mail.gmail.com>
To: Bill Kasdorf <bkasdorf@apexcovantage.com>
Cc: Dave Cramer <dauwhe@gmail.com>, "public-digipub@w3.org" <public-digipub@w3.org>
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
Received on Wednesday, 5 August 2015 21:38:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 August 2015 21:39:15 UTC