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
