Hi Steve, On Fri, Jan 31, 2014 at 5:47 PM, Steve Litt <sl...@troubleshooters.com>wrote:
> Ladies and gentlemen, if the preceding paragraph doesn't convince us we > need a good, solid, LyX to ePub and LyX to Mobi conversion (do ePub > first, you can convert ePub into Mobi), then nothing will. Instead of > slamming out his book in LyX, Anthony must use an outside service > (smashwords), meaning a two word modification is, as Joe Biden would > say, a Big Friggin Deal. Further, to satisfy Smashwords he must write it > in LibreOffice to simulate MS Word. Or, if he's just doing Kindle, he > can submit rtf (what could *possibly* go wrong). > Good luck with the convincing part. > You can't base a LyX to ePub converter off either LyX2Xhtml or Alex's > eLyXer: Those produce great (X)html for stuff like footnotes and > bibliographies, but they discard semantic tags (h1-h6) for variously > named divs (yeah, <div>, not even <p>), as I remember they still use > outdated <a name="whatever"/> instead of giving an ID to a tag. One or > both of them does you the "favor" of renaming all graphic files to a > numerical sequence: I guess this is to prevent identically named > graphics in different directories from clobbering each other, but there > are better ways of doing this that don't have the anti-debugging > baggage of removing all meaning from graphic names. Current > LyX exported (X)html files just generally require *huge* > postprocessing, with zillions of special cases, to get them in > reasonable shape to make an ePub. If that were not the case, somebody > would have made a LyX2ePub a long, long time ago, because the demand is > there, and a lot of people have that itch, and I'm not the only one > who has tried to do it. > eLyXer does not rename any graphic files AFAICR. Also, eLyXer should provide semantic tags like h1-h6, as you can see here: http://elyxer.nongnu.org/math-unicode.html Shamefully, because I need to be able to have my books available as > ePubs, after 13 years using LyX to write my books, I'm now using the > Bluefish editor to write my future books. I've written an Xhtml to ePub > converter in Python, and I can write an Xhtml to LaTeX converter just > as easily. But let me ask you something: Have you ever tried to slam > out 2500 words a day in Bluefish? Bluefish will never have the > authoring speed of LyX. But then again, as things stand now, a LyX > authored document will never be convertible to ePub. > I feel your pain. Not with Bluefish but with other, also less powerful editors. For good or for bad I have not needed translation to ePub yet. The shame is, in theory, LyX to ePub is simple. Every environment > becomes <p class="environmentname">, every character style becomes > <span class="charstylename">. Leave <div> out of it except for every > special cases. Even lyx-code should become <pre class="lyxcode">, not > <div class="lyxcode">. > It should not be difficult to change eLyXer output to be as you desire; just take a look at base.cfg https://github.com/alexfernandez/elyxer/blob/master/src/conf/base.cfg where most elements of the output can be configured. There are many special cases and a few ugly-ish tricks (such as h? to denote h1-h6), but it is mostly there. Or should be. > A special one-per-book configuration file (I did mine in YAML) defines > the assignment of Part, Chapter, Section, Subsection etc to <h1>, <h2>, > <h3>, <h4> etc, and defines which go in the table of contents, and > which get numbers and what prefix the number gets (Part, Chapter, etc). > I've already done this: It works. Don't worry about converting LyX > environment and char style defs to CSS, just list all paragraph and > char styles, so that the author can make the necessary CSS. CSS is > *much* easier to define than LaTeX environments and commands. And yes, > let the author know that this export requires the author use only a > subset of LyX's capabilities. > With luck, LyX devs will propose a native export which is neither here nor there. Uphill battle in any case. I briefly considered writing Yet Another LyX to HTML Exporter, but > found out that in spite of LyX's native format being Non Human Friendly > XML, it's not *well formed* XML, so I can't use Python's lxml.etree, > let alone Python's xml.etree.ElementTree, to parse it. Perhaps if LyX > offered an export to well-formed XML, hopefully with a DTD, I could > parse that to produce ePub-friendly Xhtml, but as far as I know that > doesn't exist either. > With eLyXer I have already done all the heavy work myself of converting LyX documents to an in-memory structure of containers and insets. In theory you might just tweak the configuration file base.cfg and generate a completely different document structure such as ePub. In practice, and as far as I know, it works: I was able to make the transition from LyX 1.x to 2.0 just by adding a few insets and containers to the configuration file. Sadly, after 7 years, not using LyX anymore and with little help from LyX developers (with some *laudable exceptions*) I can no longer justify myself to devote any efforts to support eLyXer, not even a few hours to solve reported issues with the latest formats. I am just not interested. My lack of long-term support for eLyXer has thus become a self-fulfilling prophecy. Anyway, I would suggest anyone who is working on any portion of a LyX > to ePub conversion talk with me. I'm pretty knowledgeable about ePub, > and I've already identified a lot of the dead ends and blind alleys in > ePub creation, and I know what parts of the LyX document should go into > the ePub, and which parts would be better re-done as either config or > CSS. > If you are already conversant in Python, know ePub and are willing to do the pretty boring task of translating between LyX and ePub, then you can take eLyXer as the starting point to do the job. It can probably be done in a few days: - one to understand eLyXer internals, - one to solve any stupid design errors that I may have made that make ePub support hard, such as configure it to use a different base.cfg file, - and one or two to recode all commands to output ePub. I would encourage you to take eLyXer and run from there, but the high probability that you will find strong opposition to integrate the resulting converter into eLyXer will probably mean that your effort will mostly be useful for you. So, my advice would be to keep away from it. If you are still interested I can of course give you any support you need with the source code. My switch to Bluefish isn't cast in concrete: Once LyX contains a > good, generic, reliable LyX to ePub or even LyX to "ePub friendly" Xhtml > conversion, I can switch back. If you do it soon enough, I won't even > have to write an Xhtml to LaTeX converter :-) > Again, good luck, whatever course you choose. Alex.