Re: Prioritisation

On Thu, Aug 6, 2015 at 6:35 PM, Bill McCoy <whmccoy@gmail.com> wrote:

> I agree with Leonard about the deficiencies in today's browser printing
> pipelines but wanted to add a couple things:
>
> - EPUB print-on-demand solutions are starting to appear, I saw one being
> offered for the Japanese market last month at Tokyo International Book
> Fair. There has been interest expressed in an initiative on this by folks
> from major print/POD players (HP, Toppan, Dai Nippon Printing, Ingram) as
> well as the accessibility community. No active project is yet under way in
> IDPF/Readium but I anticipate there may be something soon and would love to
> have this coordinated with this group's activities. Today's prevalent
> solutions in the CSS formatting space (AntennaHouse and Prince) are
> proprietary so having something open source, built on a browser engine, and
> helping to advance the relevant open standards (esp. CSS) would seem
> helpful. I don't think this necessarily needs to wait for other parts of
> the EPUB-WEB vision to be realized so it could be a good candidate for
> near-term efforts that would yield rapid useful results.
>

Small advertisement: Vivliostyle, whom I'm working with/for, is open source
and does printing via browser technology. It is not quite perfect yet, but
at quite an advanced stage and hopefully it should be able to do a lot of
what Prince/AntennaHouse can do with HTML in the near future.


- I think it would make most sense for this group to focus on OWP->PDF that
> is good for high-quality printing... I believe the "interactive PDF" has
> passed it's sell-by date and fundamentally trying to map HTML forms into
> PDF forms, HTML JS APIs into Acrobat scripting APIs etc. seems both
> unlikely to be fruitful and unlikely to be very useful since we already
> have EPUB and are moving in the direction of EPUB-WEB.  There are some
> areas of functionality missing from EPUB that are present in PDF that could
> be helpful to OWP in general and thus in scope for EPUB-WEB and thus this
> group. For example, digital signatures (in the legal sense). Working on
> filling these gaps seems better to me than worrying about PDF as anything
> else than its design center and primary use case as a replica of paper.
>

Right. Well, actually the issues with the print-to-pdf features Leonard
mentions were things we were considering when I was working on another open
source predecessor to Vivliostyle.js with another group. Our conclusion
back then (in 2012) was that people were still using PDFs for onscreen
reading. But as far as we understood, the main reason for that was that
certain things found in scientific texts (mathematical formulas, footnotes,
etc.) were just not very easily displayable using epubs.

We were considering whether we could add such features to browser-created
PDFs. One possible solution we came up with would be to take the PDF as it
comes out of the browser and enhance it. To do that one would however have
to give complex instructions to users ("After you create your PDF, please
go to site X and upload it then, then download another PDF form there and
use that") or give them an augmented version of the browser, both of which
are not easily done. We ended up just not doing them.