Re: [xep-support] ePUB

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.

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