On Wed, 2013-04-10 at 17:46 -0700, Pavel Sanda wrote: > Adrián Pereira wrote: > > I'll appreciate more information about this project, so i can start reading > > the documentation and maybe the code. > > More people already asked about XHTML/ePUB stuff, so few bits of info below. > > Current status of related native LyX export functionality is:
> 3) LyX->ePUB > Not done at all. 2. needs to be tweaked to get 3. > Contact not completely clear to me, several people have been around > this (Rob/Liviu/perhaps Richard?). I apologize for being so quiet in the past few months. I've been absolutely swamped with work and family commitments (my wife and I were lucky enough to have a son born last August, and it's amazing how children change your life). About a year ago, I started work on ePub support. Based on that experience, I would strongly recommend that we tighten up our XHTML and CSS export and use that output for packaging ePub. As others have already said, the LyX format is a moving target, and I'm not sure why we would want to maintain two separate implementations. Our existing XHTML device already provides: 1.) CSS customization 2.) MathML 3.) References and Bibliographies This covers everything we need to create robust markup for ePub packaging. As I see it, most of the development tasks fall into the following general categories: 1.) Developing CSS markup that can be applied to make it more ePub friendly. This includes a few semantic tag changes which make sense in a browser, but are less well adapted for devices. Consider, for example, the CSS property "page-break-inside", which should be used inside figures to prevent them from being split willy-nilly across several pages, unless absolutely necessary. It seems that most of this work should be done inside of a module that can be added to a document. This would maintain the integrity of our existing customization system. 2.) Creating a system to split documents into multiple XHTML files. ePub readers perform better if book content is split into multiple files (especially if the book contains audio/video material.) It speeds up load time and improves performance. The last time I checked (which, unfortunately, was a while ago), though, there wasn't an easy way to specify break points in a document. This would mean some work on the backend and providing a UI mechanism to specify breakpoints. Perhaps through a markup tag or through a break inset, similar to chapter-break (or both). 3.) Add image processing options. Many people who use LyX will likely want to target multiple output formats (PDF, XHTML, and ePub, for example). Electronic devices do not need the super high resolution images that print requires. There should be some way to provide separate resolution and processing specs which can be fed to ImageMagick. 4.) Create a system to package ePub, generate supporting files, and package into a zip archive with an epub extension. This could easily be done via a Python script. 5.) Providing for a UI that can be used to edit styles and create valid custom CSS and LaTeX. There are obviously other approaches, but I think that the outline above would provide for a robust and customizable system that we can extend to support additional features (such as audio/video). It also helps us to avoid the sorts of maintenance headaches that a separate XML -> XSLT route would create. Other thoughts (Richard, Pavel)? Cheers, Rob
