> > In my opinion, language should be taken from the document settings > since it is already a setting. I think for other fields such as author > this should be taken from an inset defined by the module/layout. But > this might be because I don't know anything about EPUB. Can I export > any document in LyX to EPUB with your method? I would just export from > the file menu? Or do I have to first add a module?
Right now, things are set up so that any document can be exported to EPUB using the File>Export menu option without adding an extra module. > Perhaps an extra > "EPUB fields" module could be useful in which the necessary (author > name) and optional fields are implemented with custom insets. > Is there a good way to distinguish between necessary fields and optional fields? Also, another issue to consider is that while some fields are not necessary insofar as EPUB validation is concerned, different distributors might require several such fields to be provided. > > What I'd like to implement at some point: > > - optional conversion of images to SVG format > > Note: Vector-based graphics scale better than raster-based graphics, > making > > them well-suited for electronic media. > > Note: EPUB specifications require compliant e-readers to support SVG. > > Note: Older versions of some browsers (primarily IE) don't support SVG. > > Note: Preliminary searches turn up a package named dvisvgm > > (http://www.ctan.org/pkg/dvisvgm) that converts DVI to SVG, and it's > > licensed under the GPL v3 or later. > > - ability to split large XHTML files into smaller ones > > Note: Splitting large XHTML files should boost the performance of the > > converted EPUB documents. > > - allow selection of an image for front cover artwork > > Note: Amazon requires JPEG or TIFF format for front cover artwork. > > Thanks for this information. What about EPS/PDF? What are their > advantages/disadvantages versus SVG? > Good question. As far as EPUB is concerned, the only images that are required to be supported by compliant e-readers are GIFs, JPEGs, PNGs, and SVGs, so SVGs are (supposed to be) natively supported, while PDFs and EPSs aren't necessarily supported, and are required to use a supported type as a fallback. For HTML in general, most web browsers support SVGs (it helps that the SVG standard is developed by the W3C), and I think that they don't typically support EPSs. I'm not sure about to what extent web browsers support embedded PDFs, though preliminary research suggests that most might. Another issue with PDFs is that they serve as containers for both vector- and raster-based information, so if they contain any raster-based info, that portion will appear pixelated when zoomed in.
