- From: Kaveh Bazargan <kaveh@rivervalleytechnologies.com>
- Date: Tue, 4 Aug 2015 19:22:31 +0100
- 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>
- Message-ID: <CAJ2R9pgqcrav+pfCLvofJn3XLRv6k4ss3QEEgFR-h_WDqsRaLw@mail.gmail.com>
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