[xep-support] ePUB

[Greg Baryza]

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 at renderx.com [mailto:owner-xep-support at renderx.com]
>On Behalf Of Greg Baryza
>Sent: Tuesday, February 16, 2010 12:41 PM
>To: xep-support at 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 at 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 at 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 at 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