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

Re: Prioritisation

From: Kaveh Bazargan <kaveh@rivervalleytechnologies.com>
Date: Tue, 4 Aug 2015 19:22:31 +0100
Message-ID: <CAJ2R9pgqcrav+pfCLvofJn3XLRv6k4ss3QEEgFR-h_WDqsRaLw@mail.gmail.com>
To: Deborah Kaplan <dkaplan@safaribooksonline.com>
Cc: Bill Kasdorf <bkasdorf@apexcovantage.com>, Dave Cramer <dauwhe@gmail.com>, "public-digipub@w3.org" <public-digipub@w3.org>
Thank you very much Deborah. I am learning a lot here. Accessibility is
paramount and close to my heart too. If you can give me any pointers to why
electronic and print versions need to match for accessibility, I would be
grateful.

On 4 August 2015 at 19:10, Deborah Kaplan <dkaplan@safaribooksonline.com>
wrote:

> It's good to have the clarification, Bill, because I was using it in both
> ways simultaneously. Careless of me!
>
> You need to maintain a record in the digital file of where the page breaks
> occur in the paginated version of record. But under certain circumstances,
> you need to replicate that in the rendered pages. Sighted users also
> sometimes need to use an online version for accessibility reasons (or by
> choice, but my concern is always going to be with accessibility). Those
> users also need to be able to have a visually rendered page as if it were
> print.
>
> There are any other number of reasons, both accessibility and design, why
> rendering a paged model would be desirable. E-book versions of picture
> books, for example, need visually rendered pages.
>
> There are good reasons to have visual pagination because of user
> preference, as has been discussed further up this thread, but there are
> also solid use cases where it is required, which is why I was bringing up
> accessibility and scholarship.
>
> Kaveh, adding pagination to the CSS requirements does not preclude in any
> way doing the richer kind of pagination you are describing for specific
> functionality. However, it is vitally important that, for the use cases
> were pagination is necessary, it is available.
>
>
> Deborah Kaplan
>     prio
>
> On Tue, 4 Aug 2015, Bill Kasdorf 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
>>
>>
>>
>> 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
>>
>>
>>


-- 
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:38:51 UTC