On Thu, Oct 17, 2013 at 1:49 PM, Pavel Sanda <sa...@lyx.org> wrote: > Josh Hieronymus wrote: >> 1. Breaking an XHTML file into smaller files can lead to better performance > > I think that for people who use XHTML as export format for different formats > won't be happy about this.
Indeed, I would be unhappy about that. Use LyXHTML as an intermediate format. Write a converter that does that. I've done it, it's easy enough. Heck, go further and use XSLT -- that's my advice, but you don't have to take this last bit of it, just don't change LyXHTML in odd ways please. (I can and must tolerate some backwards-incompatible changes in LyXHTML "schema". But some changes are tougher to swallow than others.) >> 3. There's certain metadata that is required for all EPUB documents in >> order to be valid EPUBs, and certain metadata that is required for them to >> be accepted at particular distributors. Should I leave it to the user to >> know the requirements for whichever distributors to which they wish to >> submit their EPUBs, or would it help to include the requirements for some >> of the major distributors so that, for example, the user knows what to >> include to get the EPUB accepted by Amazon? IMO LyX ought to be able to represent *all* the metadata you need. I use custom insets for this. My example app that uses LyXHTML and XSLT as intermediate steps can be found here: https://github.com/nicowilliams/lyx2rfc http://lyx2rfc.org/lyx2rfc/lyx2rfc.html It first exports to LyXHTML, then it applies an XSL to convert to xml2rfc's schema (this is where the custom insets are consumed as metadata relevant to RFC production), then it applies xml2rfc to convert to text and XSLT again to convert to HTML. I have converter configurations in LyX so I can export to any of the RFC formats from the LyX GUI directly. lyx2rfc can also be invoked from the command-line, or via the lyx2rfc.org website. > This would requirements would be shown in example files? How often they > change (what is the maintance cost of keeping it up-to-date in years time > range?) I wish I knew how to, or that LyX could be extended to, handle arbitrary metadata with specific formatting (including none) directives. For example, in RFC production there's a very specific set of instructions for formatting the front page, including various metadata only some of which LyX knows about natively. Any clues would be welcomed. For now I use custom insets, but I can't get LyX to do final formatting this way, instead I have to use XSLT + xml2rfc to do final formatting -- this is deeply unsatisfying. >> 4. Currently, the EPUB export script gathers its metadata by making use of >> a metadata module defining paragraph styles for different metadata >> attributes. There was discussion before about adding a new section to the >> document settings to gather the metadata instead, and the information >> collected could be used for purposes other than exporting EPUBs. If I were >> to begin work on this, what would be some metadata attributes beyond those >> used for EPUBs that should be included? > > I had in mind only PDF metadata we already have. How many EPUB metadata > fields are approximately needed for a document? That seems like the wrong question to ask. Instead LyX should support arbitrary (extensible) metadata. Nico --
