RE: [xep-support] ePUB

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
Received on Wed Feb 17 05:42:54 2010