On 1/4/21 5:10 PM, Pavel Sanda wrote: > On Mon, Jan 04, 2021 at 09:48:42PM +0100, Thibaut Cuvelier wrote: >> My recommendation, based on a quite long study of XML libraries (i.e. >> several years, but quite far from full-time): either use QXmlStreamWriter >> (which is mostly a SAX implementation in C++) or write our own. >> QXmlStreamWriter is almost 4k-line long, but it can substantially be >> simplified in our case ( >> https://github.com/qt/qtbase/blob/54875be84de059374920e4c0deacd13a41caaa13/src/corelib/serialization/qxmlstream.cpp). >> >> >> TinyXML2 (https://github.com/leethomason/tinyxml2), pugixml ( >> https://github.com/zeux/pugixml), and Xerces-C++ ( >> https://xerces.apache.org/xerces-c/) are only DOM-based. There are quite a >> few C libraries, like libxml2, that can be SAX-like, but C libraries are >> horrible to use (http://www.xmlsoft.org/examples/testWriter.c).
I did some searching and, yes, I see the problem. Word is that recent versions of libxml and libxml2 have dependencies on Gnome libraries that we don't want. I'll let you know if I get any answers to my question on the Fedora list. > I do not dare to make any qualified recommendation between the choices > above. But thinking aloud -- if there de facto isn't an alternative > to QXmlStreamWriter, would it be hard to separate that class from > the rest of Qt, fork and include it as an internal lyx routine? > We would have full control over that code without unnecessary surprises > of Qt's development. I was going to suggest something in this spirit. If, as our usual policy has been, we confine QXmlStreamWrapper to support/, then what that basically means is writing our own LyX API as a kind of wrapper around the Qt stuff. (Thibaut, if you haven't already, you might look at how the FileName class. Much of it is a wrapper around QFile.) Some, even many, of the routines might just directly call the Qt equivalent (probably after a call to toqstr, from qstring_helpers). This would be a relatively quick way to get something that worked and was easy to use, and work on adapting DocBook and HTML export to this code could proceed. At that point, we could then write our own XML backend, possibly adapting it from the Qt code. There are quite a few dependencies there, but I'll guess some of them we do not need (e.g., the QApplication and QFile dependencies). Our we build a lightweight library from scratch. (It does seem like maybe there's a general need for that.) With the already functioning backend from QXmlStreamWrapper, it would be easy to test our own code and make sure it was producing the same output. Riki -- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
