On Sat, 9 Jul 2016 12:36:36 +0100 Guillaume Munch <[email protected]> wrote:
> Le 07/07/2016 19:25, Steve Litt a écrit : > > On Wed, 6 Jul 2016 16:57:23 -0400 > > Richard Heck <[email protected]> wrote: > > > >> On 07/06/2016 04:45 PM, Robert Alvarez wrote: > >>> Epub output questions appear here periodically. > >>> > >>> An answer in one thread said that it might appear in version 2.2 > >>> > >>> I looked in the release notes but could not find it. > >>> > >>> Is epub output in 2.2? > >> > >> No, it is not. It is possible we will see in in the 2.2.x series. > > > > Robert, > > > > Be careful what you wish for. Even if/when LyX finally has ePub > > export, the question is "what quality ePub?" Will it be like the > > HTML and Xhtml exports, having all sorts of extraneous CSS styles > > to do silly stuff, deprecated stuff like <a name="whatever">, and > > the like? Just because something outputs something they call ePub, > > and it's decipherable by Calibre's ebook-viewer, doesn't make it > > the kind of ePub you can convert and sell on Amazon, or the kind of > > ePub that won't make your readers crazy with anger. > > > > Since about 2008 LyX native format has become more and more "XML > > like" without being either valid or well formed XML. If they just > > made LyX into valid and well formed XML, creating our own > > converter, with Python and Python's XML parser, will become a one > > person project. And such a converter will by its very nature be > > semantic, it won't do stupid stuff like having paragraphs all have > > either "indented" or "unindented" classes. That's a job for CSS, > > not for different types of paragraphs. Converting LyX native format > > to a valid and well formed XML would make export to ***ALL*** > > formats, those known and those yet to be discovered, easy. And the > > converters would exist completely outside of LyX and therefore > > would be small and modular. > > > > Hi Steve, > > There is a lot of wishes in your message. But I must warn, if you > ever happen to find this one person for the task, that their time is > better used within the project than outside of it. You can have a look > at the example of eLyXer, which has decided to go on its own. It still > has not caught up with the 2.2 format. Also, implementing things twice > is costly, and for what benefit? I do not see what edge a language > like Python has for this problem. > > The problem rather seems to be finding this one person. So, any > volunteer? > > Guillaume :-) What gave you the idea I was considering doing something outside the LyX project? Here's the problem Guillaume. Until LyX' native format is true XML, it's a \HUGE undertaking to make any kind of semantic export. The LyX of 2002 was parseable by a mere mortal using Python. A true XML LyX format would be easily parsable by a mere mortal using Python. But as the native format stands now, caught in a netherworld between LaTeX and XML, it takes a person with a huge brain to parse it. Or it takes someone who can use existing LyX C++ code and use it in a way that upgrades won't bust his parser. Free software is created by people scratching their itch (such as outputting to ePub). Interestingly, not all popular projects are started by outstanding programmers. Many are started by run-of-the-mill programmers who just need something done. That type of programmer is much more likely to go outside the project than dive into the LyX C++. If the project wants people to work from within, I think they need to quickly make LyX much more parseable, probably by finally becoming well formed and valid XML. This would open a huge world of write once, deploy everywhere possibilities, and bring home the wandering sheep. SteveT Steve Litt July 2016 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques
