Re: [xep-support] ePUB

From: Greg Baryza <baryza@intersystems.com>
Date: Wed Feb 17 2010 - 07:35:52 PST

At 03:42 PM 2/17/2010, Werner Donné wrote:
>Hi Greg,
>
>Generating ePub from either PDF or XSL-FO will never produce optimal
>results. It is true you could flow the text in them on an eReader. You can
>even create a layout that comes close using CSS. The problem, however, is
>that for a good eReader-experience you need structure and navigation
>information. The chapter headings, for example, can be used to generate
>the NCX navigation table in ePub, but how can you tell what is a chapter
>heading in PDF or XSL-FO?
>
>You also need semantic information to cut up a large document into parts,
>because otherwise the eReader will choke on it.
>
>If I understand it correctly you would like to recover the effort you put
>in producing the formatting in XSL-FO. You could transform XSL-FO to
>XHTML, ignoring unsupported constructs. Formatting properties can be
>translated to CSS-properties in a "style" attribute. Properties for which
>there is no equivalent in CSS are simply dropped. The result will be a
>document containing a lot of "div", "span", "table", "img" and "a"
>elements and not much more. In order to obtain a navigation structure you
>can place ID-attributes on the fo:block elements that correspond to the
>chapters or sections in the original document. Your chapter structure
>would be encoded in those IDs.
>
>Best regards,
>
>Werner.

Werner:

Thank you for that. It gives me further understanding and something to
work on.

Our documentation is presently in XML. It is loaded into a database (one
of my company's products) and stored as objects that know how to render
themselves in HTML. We use this capability to serve up documentation on
demand to browsers.

Each object also knows how to re-render itself in XML. To produce PDFs we
first get XML files of the top-level documents from the database (which
recursively renders the children). Then we pre-process them to add info
useful for printed material, but not so much for online access -- list of
tables, list of figures, legal boilerplate and so on. This we turn into
XSL-FO and give to XEP.

Sounds like a route to investigatewould be to do another pre-processor that
would add the stuff needed by the e-reader and them transform that.

Much obliged.

>On 17 Feb 2010, at 14:10, Greg Baryza wrote:
>
> > At 01:25 PM 2/16/2010, Kevin Brown wrote:
> >> It has been a recent topic of discussion without any specific conclusions
> >> yet. From internal discussions, I can say ...
> >>
> >> Point (1) -- RenderX is a vendor that specializes in the "art" of
> >> composition -- meaning, layout of pages and composition of text like
> >> kerning, word and character spacing, calculating line ending and
> hyphenation
> >> ... the core engine of RenderX is used to do this. Consider this our
> special
> >> "ability".
> >>
> >> Point (2) -- ePUB is really not much at all of this. There are some
> elements
> >> that require analysis like embedding fonts, even restricted, subsetting
> >> fonts into the ePUB zip architecture. But it is designed to allow the
> device
> >> to flow the document, not create a pre-conceived flow of the document. It
> >> needs to do this to allow it to be viewed on any reader of any size,
> layout.
> >> In other words, XSL FO already has things that are not appropriate for
> ePUB
> >> or constructs that (are not or) should not be mapped.
> >>
> >> So ...
> >>
> >> Some feel that one should go from raw XML to ePUB with alternate mappings
> >> for appearance. There is a DITA module in development for this. There are
> >> google tools for DocBook and other formats ...
> >>
> >> http://code.google.com/p/epub-tools/
> >>
> >> We usually stay within the world of composition -- we produce PDF
> (including
> >> PDF/A, PDF/X, PDF Acroforms), PostScript, AFP, XPS and soon PPML. Our
> other
> >> formats include XHTML and SVG but these are special cases where you
> wish the
> >> XHTML and the SVG to look exactly like (or as close as possible to) the
> >> printed page.
> >
> > I'm still very much a newbie when it comes to ePUB, so if these
> comments are off the mark, I welcome the educational opportunity...
> >
> > Drawing a line between XHTML and ePUB seems like making a distinction
> without a difference. Isn't the browser "flowing" content into the page
> in a way similar to that of an eReader? It appears that many of the
> current conversion-to-ePUB products take PDFs as input so why not cut out
> the middle step when you can work with the original markup?
> >
> > We have used XEP quite satisfactorily for half a decade now. We are
> starting to get probes from our current customers as to whether we will
> produce the content for their eReaders, or whether they will have to do
> it themselves. Naturally, we would rather produce the content. We also
> do not necessarily want to add another vendor unless it becomes necessary.
> >
> > That's a short explanation of what motivated the query.
> >
> >
> >> Of course, RenderX has always been a customer-focused vendor so your
> >> feedback is welcome. How important is this to our customers? Feedback on
> >> here is what we like to see.
> >>
> >> Kevin Brown
> >> RenderX
> >>
> >>
> >> -----Original Message-----
> >> From: owner-xep-support@renderx.com [mailto:owner-xep-support@renderx.com]
> >> On Behalf Of Greg Baryza
> >> Sent: Tuesday, February 16, 2010 12:41 PM
> >> To: xep-support@renderx.com
> >> Subject: [xep-support] ePUB
> >>
> >> Does RenderX have any near-term plans to produce ePUB documents from
> XSL-FO
> >> input?
> >>
> >> Thanks.
> >>
> >> <G>
> >>
> >> -------------------
> >> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
> >> in the body of the message to majordomo@renderx.com from the address
> >> you are subscribed from.
> >> (*) By using the Service, you expressly agree to these Terms of Service
> >> http://www.renderx.com/terms-of-service.html
> >>
> >> -------------------
> >> (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
> >> in the body of the message to majordomo@renderx.com from the address
> >> you are subscribed from.
> >> (*) By using the Service, you expressly agree to these Terms of
> Service http://www.renderx.com/terms-of-service.html
> >
> > -------------------
> > (*) To unsubscribe, send a message with words 'unsubscribe xep-support'
> > in the body of the message to majordomo@renderx.com from the address
> > you are subscribed from.
> > (*) By using the Service, you expressly agree to these Terms of Service
> http://www.renderx.com/terms-of-service.html
>
>--
>http://www.pincette.biz/
>Handling your documents with care, wherever you are.
>
>
>-------------------
>(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
>in the body of the message to majordomo@renderx.com from the address
>you are subscribed from.
>(*) By using the Service, you expressly agree to these Terms of Service
>http://www.renderx.com/terms-of-service.html

-------------------
(*) To unsubscribe, send a message with words 'unsubscribe xep-support'
in the body of the message to majordomo@renderx.com from the address
you are subscribed from.
(*) By using the Service, you expressly agree to these Terms of Service http://www.renderx.com/terms-of-service.html
Received on Wed Feb 17 08:00:55 2010

This archive was generated by hypermail 2.1.8 : Wed Feb 17 2010 - 08:00:56 PST