Well, regardless of any other issues, I have a fully working LyXHTML => EPUB/Kindle converter. It was written in Python because a) it was fast to develop, b) it runs plenty fast, and c) Python had the perfect libraries for parsing HTML and generating EPUB. Item (c) then led to FAST TO DEVELOP. I have books to publish, and I can't sit around waiting for some ideal, perfect solution.
Speaking of which, I did run into a problem with the LyXHTML export from LyX. The other HTML exports from LyX all include the output contained in Tex Code insets, while the LyXHTML export does not. This creates a problem for using any kind of /lettrine or "initials" functionality in your book, which is quite a problem. What I did to fix the problem is include a configurable table in the converter that automatically includes the starting text for each paragraph. Anytime I would change the first words of a paragraph, I would have to make a change in the converter's configuration file, changing the text there also. This is obviously extremely hacky, but it does get the job done. If only the LyX team would fix the LyXHTML export so it includes any text in a Tex Code block, ideally executing the Tex Code so it properly adjusts the text size, that would be ideal. The regular HTML export does this, so it should be easy to just port that code over to the LyXHTML export. At least, one would hope so. *Ken Kopelson* (619) 733-3374 On Sun, Mar 6, 2022 at 5:31 PM Steve Litt via lyx-users < lyx-users@lists.lyx.org> wrote: > Dr Eberhard Lisse via lyx-users said on Sun, 6 Mar 2022 21:24:57 +0200 > > >Steve, > > > >Since it such a schlepp, why don't you participate in the development > >or support the developers? > > LyX is great software by a great project. Great projects can be very bad > in certain respects, and that doesn't prevent them from being great > projects. As you read my response to your question, please keep in mind > that I'm very grateful to LyX for being the tool that created at least > 8 of the books I currently offer. My responses merely point out how > LyX could be much better in the area of exports. Here are, my answers > are enumerated below. > > 1) The converter must be semantic. It must keep styles as styles til > the very end, not prematurely convert to appearance. The LyX native > format is hostile to that goal, and since 2007 the LyX devs have > shown little interest in that goal. > > 2) File conversion software has no business being written in C++ plus > Qt. Python, Lua, Ruby, Perl or *maybe* simple C are the right way to > go, at least for version 1. If performance became a problem, and I > doubt it would, it could be rewritten in C. Years ago I stopped > using both C++ and Java because, in my opinion, they both suck. > > 3) Simplicity is an asset. Conceptually all that need be done is create > Xhtml5 tags with the same names as the environments and insets. But > that's not what I've seen from the LyX (X)HTML exports in the past > decade. Simplicity is an asset: The conversion software should be > separate and distinct from LyX, with a very thin interface. > > 3.1: Content in semantic Xhtml5 can be converted to anything. > > 4) If I had time to help the LyX devs, I'd have time to singlehandedly > create a Markdown=>Xhtml=>ePub and Markdown=>Xhtml=>PlainTeX=>PDF > software stack. The QOwnNotes software is already a great typing > front end for Markdown, which is why I chose Markdown. With the > Markdown based converter done, I could turn around and easily create > an Asciidoc version. > > 5) I could have, offered to, and would have written the converter for > the LyX project, if only they had followed through with their mid > 00's plan of making LyX an XML dialect. They refused to do so. > > Bottom line, in my opinion, the LyX project is the wrong project to > build the LyX to ePub (or to (X)HTML) converter. Alex Fernandez was > right about that when he built eLyXer, and IMHO eLyXer was better than > the native LyX converter at that time, but eLyXer was only half > semantic. > > If the LyX project can export to some completely semantic XML, I'll be > glad to join the team who does the conversion from there. > > > >Never mind that LyX seems to predate the Kindle, this is a LaTeX issue > >rather than a LyX one (which, after all, just a front end). > > Tragically, you've just uncovered the main problem. As long as LyX is > considered a front end to *LaTeX*, there will never be a good, robust > LyX=>ePub. Only when LyX is considered a front end to *everything* > will semantic ePub, as well as conversions to formats we haven't yet > dreamed of, be possible. > > >As written numerous times I am very keen on on the new DocBook format > >but since I use LyX in production in my practice, I can't use two > >different formats, and my staff can't cope with alpha software. > > If it's DocBook *xml* as opposed to sgml, and if the DocBook XML is > merely a representation of the environments and insets of LyX, that's a > perfect point of demarkation between LyX and (HTML | ePub | other). > You'd probably use Pandoc for DocBook=>ePub, I'd probably write my own, > but either way, it could work if DocBook *XML* and styles are kept as > styles. > > SteveT > > Steve Litt > March 2022 featured book: Making Mental Models: Advanced Edition > http://www.troubleshooters.com/mmm > -- > lyx-users mailing list > lyx-users@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-users >
-- lyx-users mailing list lyx-users@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-users
