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

RE: Prioritisation

From: Bill Kasdorf <bkasdorf@apexcovantage.com>
Date: Tue, 4 Aug 2015 19:03:17 +0000
To: Deborah Kaplan <dkaplan@safaribooksonline.com>
CC: Kaveh Bazargan <kaveh@rivervalleytechnologies.com>, Dave Cramer <dauwhe@gmail.com>, "public-digipub@w3.org" <public-digipub@w3.org>
Message-ID: <CO2PR06MB572A53890007E6215D23D81DF760@CO2PR06MB572.namprd06.prod.outlook.com>
Well, again, I would caution against confusing "fixed layout" with "paginated." I have a hard time accepting that sighted users _need_ the same layout as the print. Publishers like that--cookbooks, kids books, etc.--but that is not about accessibility, that's about design. (It usually impairs accessibility.) It's the information about the page breaks, not the replica layout, that is important, imo. That doesn't mean the sighted user doesn't want a nicely rendered page; that's why we're working on these pagination issues. But those nicely rendered pages don't need to (and usually shouldn't) replicate the print layout.--Bill

-----Original Message-----
From: Deborah Kaplan [mailto:dkaplan@safaribooksonline.com] 
Sent: Tuesday, August 04, 2015 2:10 PM
To: Bill Kasdorf
Cc: Kaveh Bazargan; Dave Cramer; public-digipub@w3.org
Subject: RE: Prioritisation

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 
> HTML+variety of screen sizes and types, not to mention the personal 
> HTML+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 Tuesday, 4 August 2015 19:03:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 4 August 2015 19:03:49 UTC