Re: magazines and OWP (was Re: Prioritisation)

Thank you Leonard for clarifying Adobe's technology vector with DPS and yes
I would agree that the impediments to broader adoption of digital magazines
(as currently conceived) hasn't really been about the technology... well,
at least not directly. Digital magazines have been very targeted to
tablets, but tablet sales have stalled while smartphone consumption of
content is soaring... the model of precisely designing various fixed
renditions of beautiful pages makes sense in a tablet-centric world but is
not as practical for the N-screen world we are converging on, with most
users' primary screen being their smallest..., this demands reflow, which
is a technical requirement (one that I believe that EPUB-WEB group needs to
be keeping front and center, since it also relates to a11y, and more
generally machine processability).

I do also agree on the need for choice in regards to content types
including reflowable text, scalable text/vector graphics, and bitmap
images. OWP overall and EPUB 3 already fully support all these choices,
albeit in the case of scalable text/vector graphics it requires a
transformation from PDF page descriptions (which can be "theoretically"
lossless if SVG is the output of the transformation). I realize DPS now
supports PDF pages as a content type (I believe it was originally bitmap
pages only) which does remove a translation step and simplify workflows for
some publishers... that could definitely be done with EPUB since its
content types are extensible but so far we have taken the position that we
would rather stay more closely aligned with OWP rather than bolting on a
very large additional technology which is, at least in some respects,
redundant with respect to OWP capabilities (esp. SVG) and which would add
to the "threat surface". EPUB-WEB work could revisit this question, of
course, and if a grand integration could be done that pulls PDF in more to
the OWP that could be interesting, but it would also be much more ambitious
and again could create some redundancy. Personally I would vote for keeping
focus for EPUB-WEB on the "native" OWP content types (HTML/CSS and SVG)
while increasing efforts on PDF to HTML/CSS and SVG translation (which
while mostly being an implementation activity might have some spec impact,
e.g. font support in SVG is a known weak point in achieving a full
isomorphism with PDF page descriptions).

--Bill

On Mon, Aug 10, 2015 at 10:59 AM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> Bill, I am not sure why you believe that the current crop of digital
> magazine isn’t getting customer traction – our customers think it’s working
> acceptably.  Could it be better – sure – but the reasons (based on actually
> talking to customers :) have nothing to do with the technical matters.
>
> That said, the changes in Adobe’s DPS product line are actually more about
> a change in distribution model than a change in display technology.  Our
> current DPS publications support multiple rendition formats including (but
> not limited to) HTML/OWP, PDF and raster images (PNG/JPG).  Each
> publication is free to choose any combination of those formats for each
> individual article contained in the publication – in that it’s quite common
> to find publications with some PDF, some HTML and the occasional
> raster-based article depending on what they are trying to achieve.  With
> the new model – all that remains the same.  No changes to the technologies
> in question.
>
> What has changed, however, is that in addition to offering our customers a
> fully self-contained publication, they may now build publications that
> intermix self-contained, cached or live content.  This yields a publication
> that serves the three different types of distribution models described on
> the Packaging page (<
> https://www.w3.org/dpub/IG/wiki/Requirements_for_Web_Publication_and_Packaging>).
> Yes our publications remain in a proprietary format, as that better suits
> our business needs at this time.
>
> As with you, we (Adobe) does believe that the OWP is a key set of
> technologies that should be available to our customers for their publishing
> needs.  However, we don’t believe that it is the only set of technologies
> as they should be able to choose the solution that fits their content.  It
> may be that today there is a greater demand for PDF (or raster) based on
> designers with print-centric backgrounds and missing pieces in the OWP
> stable…but hopefully this group can help drive the OWP forward and enable
> greater use in this particular industry.  BUT there will always be a need
> for choice = something that needs to be incorporated into any real-world
> solution.
>
> Leonard
>
> From: Bill McCoy
> Date: Sunday, August 9, 2015 at 1:35 PM
> To: Dianne Kennedy
> Cc: Jacob Friedman, Ivan Herman, Leonard Rosenthol, Johannes Wilm, Bill
> Kasdorf, Kaveh Bazargan, Dave Cramer, W3C Digital Publishing Discussion
> list, Matthew Hardy
> Subject: magazines and OWP (was Re: Prioritisation)
>
> Dianne is certainly correct that  magazine workflows are largely Adobe
> CS-centric, and (per other email) that print-first orientation will likely
> linger longer in this segment of publishing, at least for major consumer
> magazines.
>
> But I think it would nevertheless be a big mistake for this group to make
> working on digital magazine requirements anything other than in-scope and
> high-priority (at least in the big-picture sense).
>
> The "jazzed-up print-replica" nature of digital magazines as per most
> solutions to date (including the original Adobe DPS) haven't led to
> large-scale customer traction, and it seems that Adobe is with its newly
> announced "DPS 2015" moving towards more OWP-centric experiences, for
> example by integrating Apache Cordova (aka PhoneGap). I believe there is
> still a proprietary format for content and that the browser engine may not
> yet be used to render all content but I'm not sure and the situation seems
> to be a bit fluid (perhaps Leonard could give us some information about the
> evolving DPS technical architecture).
>
> More generally it seems clear that the major consumer print magazines are
> being substantially disrupted by the Web and mobile apps and that both
> established properties and new media firms will continue to arise that are
> digital-first and in many cases digital-only. It is clear that these folks
> will be directly benefited both by improving OWP base capabilities for
> publishers and by working towards the EPUB-WEB vision.
>
> And I think that magazines are an especially interesting and important use
> case for EPUB-WEB because they are advertising-centric, and ads in digital
> content  (in many cases) need to be dynamic not static, come from multiple
> sources, have robust analytics, and be actionable by the user. These things
> are of course easy to do with websites but not so straightforwardly with
> packaged EPUB publications. OTOH digital magazines also (in many cases)
> need to be distributed through channels, supported via custom applications,
> and  usable offline, all things that are easy to do with for example EPUB
> but not so straightforward with websites. Last but not least, magazines are
> perhaps the pickiest segment about design/layout/typography: if we can make
> OWP good enough for a consumer magazine art director, it is pretty much
> guaranteed to be good enough for everyone else in publishing.
>
> Strategically, I see digital magazines in the broadest sense as pushing
> the need for convergence of publications/websites, online/offline,
> real-time/dynamic and static/canonical content and improving high-design
> layout/typography capabilities of OWP... all of which is precisely where we
> should be looking for high-priority work items to fully realize the
> EPUB-WEB vision.
>
> Tactically, by this group explicitly working this this area we will be
> setting a direction that OWP is the right platform for digital magazines...
>  this would also encourage vendors such as Adobe to move further towards
> OWP (and in the process help to improve OWP for all publishers).
>
> --Bill
>
>
> On Wed, Aug 5, 2015 at 7:43 AM, Dianne Kennedy <dkennedy@idealliance.org>
> wrote:
>
>> For magazines the shift to digital-first will be a slow one as workflows
>> are currently highly invested and a near monopoly held by Adobe Creative
>> suite.  In our case digital-first will be some combination of PRISM
>> metadata for the issue and articles within the issue + HTML5.  In fact,
>> PRISM is working on an authoring schema for authors to use as a front end
>> to their CS workflows.  While new magazines may leapfrog, majors are doomed
>> to a slow evolution toward the ideal.
>>
>>
>>
>> I'm just trying to convey the reality of our situation (magazine
>> industry) and figure out if that is out of scope for this discussion.  If
>> out of scope, I will place any of those thoughts and put any input I have
>> that considers the current reality aside so I can contribute from the
>> proper point-of-view.
>>
>>
>>
>> *Dianne Kennedy *| Vice President Digital & Emerging Technologies
>>
>> O: 630.941.8197 | M: 630.908.0770 | dkennedy@idealliance.org
>> <sbonoff@idealliance.org> | www.idealliance.org
>>
>> [image: idealliance_logo_web]
>>
>>
>>
>> *From:* Jacob Friedman [mailto:jacob@subsumo.com]
>> *Sent:* Wednesday, August 5, 2015 9:25 AM
>> *To:* Dianne Kennedy
>> *Cc:* Ivan Herman; Leonard Rosenthol; Johannes Wilm; Bill Kasdorf; Kaveh
>> Bazargan; Dave Cramer; W3C Digital Publishing Discussion list; Matthew Hardy
>> *Subject:* Re: Prioritisation
>>
>>
>>
>> Publishing is definitely moving toward the web - I can imagine that all
>> printed materials *should and will* be authored in such a system which
>> respects HTML markup. Essentially, this solves cross-platform publishing...
>>
>>
>>
>> On 2015-08-05, at 10:20 AM, Dianne Kennedy <dkennedy@idealliance.org>
>> wrote:
>>
>>
>>
>> Question, does this only apply when the WEPUB is the sole point of
>> reference?  In other words, are publications that were originally published
>> in print out of scope for this discussion?
>>
>> For magazines whose origin is a print rendition, print will remain the
>> publication of reference and we will want to mark where pages were broken
>> in that original source, despite where an individual rendition might break
>> "pages".  The reason for this is that pages are often copyedited to
>> engineer page breaks at important content markers.  Its also important to
>> being able syncronize the point in content that a user returns to as they
>> move between Web to mobile from print throughout their reading day...
>>
>> Dianne Kennedy | Vice President Digital & Emerging Technologies
>> O: 630.941.8197 | M: 630.908.0770 | dkennedy@idealliance.org |
>> www.idealliance.org
>>
>>
>>
>> -----Original Message-----
>> From: Ivan Herman [mailto:ivan@w3.org]
>> Sent: Wednesday, August 5, 2015 4:37 AM
>> To: Leonard Rosenthol
>> Cc: Johannes Wilm; Bill Kasdorf; Kaveh Bazargan; Dave Cramer; W3C Digital
>> Publishing Discussion list; Matthew Hardy
>> Subject: Re: Prioritisation
>>
>> Leonard,
>>
>>
>> On 04 Aug 2015, at 21:38 , Leonard Rosenthol <lrosenth@adobe.com> wrote:
>>
>> With the focus here on terminology, I think that we also need to be
>> careful about what the definition of a “page” is in this context.
>>
>> In reading over the various messages here, I see (at least) three
>> different definitions.
>>
>> 1 – The content that fits on the device’s screen/output without requiring
>> any scrolling.
>> 2 – The content that maps to a semantic concept in the publication (eg.
>> Index, chapter, article, etc.) and may require scrolling
>> 3 – The content that maps to the printed or fixed layout representation.
>>
>>
>> I like this differentiation, and I would think that #2 is indeed very
>> important but we may want to, eventually, completely dissociate it from the
>> concept of paging.
>>
>> My understanding is that publishers, these days, put some sort of a page
>> mark into the digital output (in the form of an invisible element, of a
>> metadata, etc.). The purpose of this is to be able to *link* (either
>> conceptually or through real hyperlinks) into the document. It is obviously
>> important for various use cases that came up in this thread already (and
>> others) like academic reference or classroom usage. But, just as you say,
>> handling these may require scrolling and that because the concept of these
>> anchors are, actually, orthogonal to display, ie, pages in terms of #1 and
>> #3.
>>
>> I think there is an interesting discussion to have on where anchors
>> should be put, what is the granularity of those, can (in future) some sort
>> of a robust anchoring approach take over the need for these anchors, etc.
>> It is largely a usability issue, but I think it is better if we separate it
>> from the concept of pagination…
>>
>> Cheers
>>
>> Ivan
>>
>>
>>
>>
>> Each of these is a completely valid definition of a “page” of content
>> that one may wish to present to a user in a paginated fashion, where they
>> navigate between other instances of the same.   And, like Johannes, I
>> believe they are all valid use cases for varying types of content – and
>> that (a) authors need to be able to control which they want (perhaps more
>> than one in the same publication) and (b) any UA/RS needs to be able to
>> support what the author has specified.
>>
>> Leonard
>>
>> From: Johannes Wilm
>> Date: Tuesday, August 4, 2015 at 3:21 PM
>> To: Bill Kasdorf
>> Cc: Kaveh Bazargan, Dave Cramer, "public-digipub@w3.org"
>> Subject: Re: Prioritisation
>> Resent-From: <public-digipub@w3.org>
>> Resent-Date: Tuesday, August 4, 2015 at 3:21 PM
>>
>>
>> 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
>>
>>
>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>>
>
>