On 1/12/21 6:19 PM, Thibaut Cuvelier wrote:
> On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini
> mailto:lorenzobertin...@gmail.com>> wrote:
>
> Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
> > A tour of some C++ libraries for XML:
> > - RapidXML:
On Tue, 12 Jan 2021 at 16:33, Lorenzo Bertini
wrote:
> Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
> > A tour of some C++ libraries for XML:
> > - RapidXML: mostly unmaintained since 2013, no support for namespaces
> > (except in forks: https://github.com/dwd/rapidxml
&g
Il 08/01/21 03:00, Thibaut Cuvelier ha scritto:
A tour of some C++ libraries for XML:
- RapidXML: mostly unmaintained since 2013, no support for namespaces
(except in forks: https://github.com/dwd/rapidxml
<https://github.com/dwd/rapidxml>)
- Boost Property Tree: no XML parser, which
perty Tree, which popped up frequently while searching.
>>
>> I think Thibaut is right when saying that, for the way LyX is structured
>> now, a SAX writer would be more appropriate, because we won't work on
>> xml directly, but convert the LyX file. However most of the libraries
ght when saying that, for the way LyX is structured
> now, a SAX writer would be more appropriate, because we won't work on
> xml directly, but convert the LyX file. However most of the libraries
> have a DOM approach, and also, if someday we'll convert LyX format to
> something xml-like,
would be more appropriate, because we won't work on
xml directly, but convert the LyX file. However most of the libraries
have a DOM approach, and also, if someday we'll convert LyX format to
something xml-like, we might have to start all of this again.
I did a small benchmark with pugixml
>> > is a simple SAX writer, not a parser. I've done plenty of research about
>> > it, there's no XML library that does that. Most of them are using a DOM,
>> > which is a total waste of memory for such an application: it stores a
>> > complete XML tree in memory before s
ut
> > it, there's no XML library that does that. Most of them are using a DOM,
> > which is a total waste of memory for such an application: it stores a
> > complete XML tree in memory before serialising it. With SAX, you just
> need
> > a string backend, which is much mor
On Mon, Jan 04, 2021 at 09:48:42PM +0100, Thibaut Cuvelier wrote:
> There are multiple issues here. What is needed to generate HTML and DocBook
> is a simple SAX writer, not a parser. I've done plenty of research about
> it, there's no XML library that does that. Most of them are us
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
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.
> QXml
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
e
> possibility of using an external library to handle XML streams, for example
> with indentation and tag insertion. One of the candidates was
> QXmlStreamWriter <https://doc.qt.io/qt-5/qxmlstreamwriter.html> class,
> but with the talk about removing unnecessary Qt components we though
On 1/3/21 3:37 PM, Lorenzo Bertini wrote:
>
> Hello list,
>
> In 12055 <https://www.lyx.org/trac/ticket/12055>, discussing the merge
> of some MathMLStream and XmlStream components, we were contemplating
> the possibility of using an external library to handle XM
Hello list,
In 12055 <https://www.lyx.org/trac/ticket/12055>, discussing the merge
of some MathMLStream and XmlStream components, we were contemplating the
possibility of using an external library to handle XML streams, for
example with indentation and tag insertion. One of the cand
EST)
> > > schrieb Thibaut Cuvelier <mailto:tcuvel...@lyx.org>>:
> > >
> > > > commit 85946aae2b94fedf5ce9bd35e91ba500986b5121
> > > > Author: Thibaut Cuvelier <mailto:tcuvel...@lyx.org>>
> > > &
gt; > > Am Fri, 31 Jul 2020 23:37:33 +0200 (CEST)
>> > > schrieb Thibaut Cuvelier :
>> > >
>> > > > commit 85946aae2b94fedf5ce9bd35e91ba500986b5121
>> > > > Author: Thibaut Cuvelier
>> > > > Date: Sat A
Thibaut Cuvelier :
> > >
> > > > commit 85946aae2b94fedf5ce9bd35e91ba500986b5121
> > > > Author: Thibaut Cuvelier
> > > > Date: Sat Aug 1 00:02:36 2020 +0200
> > > >
> > > > DocBook: fix XML in comments (-- forbidden for some historical
>
> Author: Thibaut Cuvelier
> > > Date: Sat Aug 1 00:02:36 2020 +0200
> > >
> > > DocBook: fix XML in comments (-- forbidden for some historical
> > reason).
> > > ---
> > > autotests/export/docbook/deutsches_ert.lyx | 14
On Sat, 1 Aug 2020 at 00:28, Kornel Benko wrote:
> Am Fri, 31 Jul 2020 23:37:33 +0200 (CEST)
> schrieb Thibaut Cuvelier :
>
> > commit 85946aae2b94fedf5ce9bd35e91ba500986b5121
> > Author: Thibaut Cuvelier
> > Date: Sat Aug 1 00:02:36 2020 +0200
> >
>
Am Fri, 31 Jul 2020 23:37:33 +0200 (CEST)
schrieb Thibaut Cuvelier :
> commit 85946aae2b94fedf5ce9bd35e91ba500986b5121
> Author: Thibaut Cuvelier
> Date: Sat Aug 1 00:02:36 2020 +0200
>
> DocBook: fix XML in comments (-- forbidden for some historical reason).
> ---
&
Guillaume just made me notice a limitation of this patch for MathFactory:
with \def, the column for the XML entity was not parsed. It's fixed in this
new stand-alone patch (along with small updates in lib/symbols for things I
forgot).
Thibaut Cuvelier
On Thu, 18 Jun 2020 at 23:40, Pavel Sanda
On Thu, Jun 18, 2020 at 11:35:39PM +0200, Thibaut Cuvelier wrote:
> indicating that no real translation was available. I highly suspect that
> \varGamma was displayed as "varGamma", i.e. as text, instead of the right
> symbol. As far as I know, there is no HTML entity for rare symbols like
>
That effect was not intended: few new Unicode-based XML entities should be
output in HTML. I therefore investigated further the case of varGamma.
Before, it was simply not translated into MathML: the symbols file only
contained an x (
https://github.com/cburschka/lyx/blob
On Thu, Jun 18, 2020 at 09:41:10PM +0200, Kornel Benko wrote:
> > Mint 19.3 Tara.
>
> Tricia!
Ok, debian based distros seem to be covered, I just checked with another win
machine
and its fine. I'll comit the last patch.
Pavel
--
lyx-devel mailing list
Am Thu, 18 Jun 2020 21:40:25 +0200
schrieb Kornel Benko :
> Am Thu, 18 Jun 2020 21:24:45 +0200
> schrieb Pavel Sanda :
>
> > On Thu, Jun 18, 2020 at 09:08:07PM +0200, Kornel Benko wrote:
> > > I have no problems, if that is the expected line.
> >
> > Good, what distro? Pavel
>
> Mint
Am Thu, 18 Jun 2020 21:24:45 +0200
schrieb Pavel Sanda :
> On Thu, Jun 18, 2020 at 09:08:07PM +0200, Kornel Benko wrote:
> > I have no problems, if that is the expected line.
>
> Good, what distro? Pavel
Mint 19.3 Tara.
Kornel
pgpMkJYoL8IYI.pgp
Description: Digitale Signatur von
On Thu, Jun 18, 2020 at 09:08:07PM +0200, Kornel Benko wrote:
> I have no problems, if that is the expected line.
Good, what distro? Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
Am Thu, 18 Jun 2020 21:08:07 +0200
schrieb Kornel Benko :
> Am Thu, 18 Jun 2020 20:54:08 +0200
> schrieb Pavel Sanda :
>
> > On Thu, Jun 18, 2020 at 08:46:08PM +0200, Kornel Benko wrote:
> > > > > If you go to
> > > > > https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
> > > > >
Am Thu, 18 Jun 2020 20:54:08 +0200
schrieb Pavel Sanda :
> On Thu, Jun 18, 2020 at 08:46:08PM +0200, Kornel Benko wrote:
> > > > If you go to
> > > > https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
> > > > and check for the U+1D6Ex line do you see some meaningful symbols
> > > >
On Thu, Jun 18, 2020 at 08:46:08PM +0200, Kornel Benko wrote:
> > > If you go to
> > > https://en.wikipedia.org/wiki/Mathematical_Alphanumeric_Symbols
> > > and check for the U+1D6Ex line do you see some meaningful symbols
> > > like \varGamma in your browsers?
> Sorry, I misread the question.
Am Thu, 18 Jun 2020 20:44:20 +0200
schrieb Kornel Benko :
> Am Thu, 18 Jun 2020 20:01:18 +0200
> schrieb Pavel Sanda :
>
> > On Mon, Jun 15, 2020 at 02:46:47PM +0200, Thibaut Cuvelier wrote:
> > > Here is a new version of the first patch. Indeed, I forgot to completely
> > > refactor a few
Am Thu, 18 Jun 2020 20:01:18 +0200
schrieb Pavel Sanda :
> On Mon, Jun 15, 2020 at 02:46:47PM +0200, Thibaut Cuvelier wrote:
> > Here is a new version of the first patch. Indeed, I forgot to completely
> > refactor a few font-related things. It should be much better now. (I also
> > removed a
On Mon, Jun 15, 2020 at 02:46:47PM +0200, Thibaut Cuvelier wrote:
> Here is a new version of the first patch. Indeed, I forgot to completely
> refactor a few font-related things. It should be much better now. (I also
> removed a method declaration that belongs to another DocBook commit down
> the
On Thu, Jun 18, 2020 at 05:26:34PM +0200, Jean-Marc Lasgouttes wrote:
> Le 18/06/2020 ?? 17:19, Pavel Sanda a écrit :
> >Thanks, I committed the first patch with consts added (binding to
> >temporaries).
> >I propose to drop the second patch altogether. Unless you use simple
> >expressions
>
Le 18/06/2020 à 17:19, Pavel Sanda a écrit :
Thanks, I committed the first patch with consts added (binding to temporaries).
I propose to drop the second patch altogether. Unless you use simple expressions
chaining is not particularly safe, << is not a sequence point so order of
evaluation
is
Math manual to be identical.
> >
>
> Here is a new version of the patches. Among the changes:
> - removal of a TODO for xml::ParTag (the constructor with parid is no more
> used anywhere). ParTag still exists, as it is used to perform some dispatch
> in the stream.
>
;
> Ok, we are bit closer, I committed update of first patch.
>
> There is still missing id='magicparlabel-XX' part which need to be fixed.
> Please check xHTML output of e.g. Math manual to be identical.
>
Here is a new version of the patches. Among the changes:
- removal of a TODO
On Mon, Jun 15, 2020 at 02:46:47PM +0200, Thibaut Cuvelier wrote:
> Here is a new version of the first patch. Indeed, I forgot to completely
> refactor a few font-related things. It should be much better now. (I also
Ok, we are bit closer, I committed update of first patch.
There is still
On Mon, Jun 15, 2020 at 01:48:50PM +0200, Thibaut Cuvelier wrote:
> The goal being to completely overhaul that export (i.e. rewrite it), I
> don't know if it's helpful to ensure it still works with this patch :/.
No it's not. Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
On Tue, Jun 09, 2020 at 07:02:23PM +0200, Thibaut Cuvelier wrote:
> This patch is made so that there should not be any change to the XHTML
> output.
Oops, I think I waas too fast to accept your changes in the first patch.
I see huge diff between the current Math Manual and the pre a6b07608d8e9de
hanks, no warnings.
> > > >
> > > > My try to export was not successful though.
> > > > Error: Couldn't export file
> > > > ----
> > > > No information for exporting the format
ful though.
> > > Error: Couldn't export file
> > >
> > > No information for exporting the format MS Excel Office Open XML.
> >
> > These patches are aimed at docbook (to be completed in futu
Error: Couldn't export file
> >
> > No information for exporting the format MS Excel Office Open XML.
>
> These patches are aimed at docbook (to be completed in future) not for MS
> Excel Office Open XML export.
>
Unless I broke something in that export, but I don't know in which cases it
On Mon, Jun 15, 2020 at 08:43:39AM +0200, Kornel Benko wrote:
> Thanks, no warnings.
>
> My try to export was not successful though.
> Error: Couldn't export file
>
> No information for exporting the format MS Exc
ssful though.
Error: Couldn't export file
No information for exporting the format MS Excel Office Open XML.
Is this the wrong export?
Do I need some external converter?
Kornel
pgpmpI_kle471.pgp
Description: Digitale
hed.
> >
> > Kornel
> > --
> > lyx-devel mailing list
> > lyx-devel@lists.lyx.org
> > http://lists.lyx.org/mailman/listinfo/lyx-devel
> >
Compiles fine, with some warnings.
...
/usr2/src/lyx/lyx-test/src/output_docbook.cpp:44:19: warning: ‘const stri
+ b/src/tests/dummy_functions.cpp
@@ -3,10 +3,11 @@
#include "Format.h"
#include "LayoutEnums.h"
#include "LyXRC.h"
#include "support/Messages.h"
+#include "xml.h"
using namespace std;
namespace lyx {
@@ -47,6 +48,11 @@ Formats & theForma
On Sun, Jun 14, 2020 at 10:12:31PM +0200, Kornel Benko wrote:
> > Can you try to import my patch into dummy_functions.cpp ?
> > Pavel
>
> Works, if inserted also
> #include "xml.h"
> into src/tests/dummy_functions.cpp.
Cool, can you post the patch for convenience? P
--
lyx-devel mailing
r2/src/lyx/lyx-test/src/tests/dummy_functions.cpp:53:11: error: ‘StartTag’
has
not been declared docstring StartTag::writeTag() const { return docstring();};
^~~~
/usr2/src/lyx/lyx-test/src/tests/dummy_functions.cpp:53:32: error: non-member
function
‘lyx::docstring lyx::xml::wri
On Sat, Jun 13, 2020 at 02:39:18PM +0200, Kornel Benko wrote:
> > Just checked, same error in cmake build for tex2lyx without Pavel's patch.
> >
> > With the patch it compiles.
> >
> > Kornel
>
> And as expected, breaks building of check_layout:
Can you try to import my patch into
Le 13/06/2020 à 10:21, Kornel Benko a écrit :
Or you can add ../xml.o to the link list. Does this work? I think this
is in general better than to use a hack.
I do not see it as a hack. This is unused code in tex2lyx. And dummy*.cpp is
exactly for
this purpose there.
I know that, I just
layout.dir/dummy_functions.cpp.o
-o ../../bin/check_layout ../../lib/libsupport.a -lz
-lmagic /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5.9.5
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.9.5
CMakeFiles/check_layout.dir/__/Layout.cpp.o: In Funktion
»lyx::xml::StartTag::StartTag(std::__cxx11::basic_string,
s
Am Sat, 13 Jun 2020 10:09:34 +0200
schrieb Kornel Benko :
> Am Fri, 12 Jun 2020 13:15:19 +0200
> schrieb Pavel Sanda :
>
> > On Thu, Jun 11, 2020 at 06:30:22PM +0200, Thibaut Cuvelier wrote:
> > > Yes, the output is identical. I also added some comments.
> > >
> > > I'm adding a third patch
Am Sat, 13 Jun 2020 00:33:20 +0200
schrieb Jean-Marc Lasgouttes :
> Le 12/06/2020 à 23:28, Pavel Sanda a écrit :
> > On Fri, Jun 12, 2020 at 01:15:19PM +0200, Pavel Sanda wrote:
> > For this part, the attached patch seem to help with autotools.
IMHO it would help on cmake build too.
> Or you
Am Fri, 12 Jun 2020 13:15:19 +0200
schrieb Pavel Sanda :
> On Thu, Jun 11, 2020 at 06:30:22PM +0200, Thibaut Cuvelier wrote:
> > Yes, the output is identical. I also added some comments.
> >
> > I'm adding a third patch in this, I forgot it was necessary??? It is a
> > refactoring of XHTMLStream
On Sat, Jun 13, 2020 at 12:33:20AM +0200, Jean-Marc Lasgouttes wrote:
> Le 12/06/2020 ? 23:28, Pavel Sanda a écrit :
> >On Fri, Jun 12, 2020 at 01:15:19PM +0200, Pavel Sanda wrote:
> >For this part, the attached patch seem to help with autotools.
>
> Or you can add ../xml.o to the link list. Does
depends whether xml.o
brings some other cruft with it.
JMarc
CXX dummy_impl.o
CXXLDtex2lyx
dummy_impl.o: In function `lyx::xml::StartTag::StartTag(std::__cxx11::basic_string, std::allocator > const&)':
/home/lyx/devel/src/tex2lyx/../../src/xml.h:164: undefined reference to
On Fri, Jun 12, 2020 at 01:15:19PM +0200, Pavel Sanda wrote:
For this part, the attached patch seem to help with autotools.
> CXX dummy_impl.o
> CXXLDtex2lyx
> dummy_impl.o: In function
> `lyx::xml::StartTag::StartTag(std::__cxx11::basic_string std::char_traits, st
inks everything?
I can look next week, but I spent all my avail lyx-time for today when trying
to fix it.
0001 patch gives me:
output_docbook.cpp: In function 'const docstring&
lyx::{anonymous}::fontToDocBookTag(lyx::xml::FontTypes)':
output_docbook.cpp:48:40: warning: returning ref
On Tue, Jun 09, 2020 at 07:02:23PM +0200, Thibaut Cuvelier wrote:
> This patch is made so that there should not be any change to the XHTML
> output. All features are opt-in (name spaces and XML entities). XHTML
> output always uses HTML entities (which are very lenient), XML ones shoul
do not care that much about new xml part, but I wonder about the changes
to the current xHTML export.
The first patch looked more or less harmless.
The second part seem mostly as a huge work to add up the new xml column to
symbols.
- Could you clarify whether/how many output changes will be there in x
On Thu, 14 May 2020 at 20:40, Guenter Milde wrote:
> Dear Thibaut,
>
> On 2020-05-10, Thibaut Cuvelier wrote:
>
> > In order to ensure a valid DocBook entity with math formulae, the MathML
> > generator must produce valid XML. Right now, it "only" produces
Dear Thibaut,
On 2020-05-10, Thibaut Cuvelier wrote:
> In order to ensure a valid DocBook entity with math formulae, the MathML
> generator must produce valid XML. Right now, it "only" produces valid HTML
> (which is already quite an achievement!). The difference is in the
tch the structure now is:
#symbolfont charid charid-in-fallback-Xsymbol-font math-class
xHTML XML
Pavel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
On 5/9/20 9:25 PM, Thibaut Cuvelier wrote:
> Dear list,
>
> In order to ensure a valid DocBook entity with math formulae, the
> MathML generator must produce valid XML. Right now, it "only" produces
> valid HTML (which is already quite an achievement!). The difference is
&
Dear list,
In order to ensure a valid DocBook entity with math formulae, the MathML
generator must produce valid XML. Right now, it "only" produces valid HTML
(which is already quite an achievement!). The difference is in the
entities: in HTML, you can use many entities, like . This
On Tuesday, 23 April 2019 22.23.41 WEST Nico Williams wrote:
> FWIW, I've done some LyX->LyXHTML->XML conversions, as well as
> LyX->XML via Python (to fix text styling open/close mismatching) and
> then XSLT.
>
> You can find that work here: https://github.com/nicowi
Le 26/04/2019 à 10:52, Stephan Witt a écrit :
If I try to interpret it I can see in line (6) our code is involved the last
time before the crash. Here the method named lyx::frontend::Action::action is
called and this method does nearly nothing except calling some configured
method indirectly.
t doesn’t necessarily mean more possibilities… I
>> don’t know off-hand how the lists are constructed and why they contain
>> useless entries.
>>
>>>
>>> Excuse me, what is the »sack trace«? Should I send you the details of the
>>> SIGSEV?
>>
>>
FWIW, I've done some LyX->LyXHTML->XML conversions, as well as
LyX->XML via Python (to fix text styling open/close mismatching) and
then XSLT.
You can find that work here: https://github.com/nicowilliams/lyx2rfc
It's a bit old and rotted, but it illustrates something like
LaTeX->XML,
On 01/08/2017 05:30 PM, Martin A. Brown wrote:
> Hello,
>
>>> Yes, I can and I yes it works. I have attached the patch. I
>>> have never touched C++ before, so this is just the dumbest thing
>>> I could suggest, though it seems to do the trick.
>> Thanks, I've committed these. They're
On Sun, Jan 08, 2017 at 02:30:09PM -0800, Martin A. Brown wrote:
>
> Hello,
>
> >> Yes, I can and I yes it works. I have attached the patch. I
> >> have never touched C++ before, so this is just the dumbest thing
> >> I could suggest, though it seems to do the trick.
> >
> >Thanks, I've
Hello,
>> Yes, I can and I yes it works. I have attached the patch. I
>> have never touched C++ before, so this is just the dumbest thing
>> I could suggest, though it seems to do the trick.
>
>Thanks, I've committed these. They're sufficiently minor that we
>don't really NEED a license
t;> this tool over the years.
>>>
>>> I have two questions today, after examining the DocBook XML
>>> output from the 2.2.x series.
>>>
>>> Question 1
>>> --
>>> Is it possible to change the public identifier for the DocBoo
>> I have two questions today, after examining the DocBook XML output
>> from the 2.2.x series.
>
>You might want to read http://www.lyx.org/trac/ticket/7009
I see.
>I believe if someone competent told us (hint) what we are supposed
>to output, the patch to port
s today, after examining the DocBook XML
>> output from the 2.2.x series.
>>
>> Question 1
>> --
>> Is it possible to change the public identifier for the DocBook
>> XML 4.2 output processor to use:
>>
>> -//OASIS//DTD DocBook XML
Martin A. Brown wrote:
> I have two questions today, after examining the DocBook XML output
> from the 2.2.x series.
You mmight want to read http://www.lyx.org/trac/ticket/7009
I believe if someone competent told us (hint) what we are supposed
to output, the patch to port docbook for som
>
> I have two questions today, after examining the DocBook XML output from the
> 2.2.x series.
>
> Question 1
> --
> Is it possible to change the public identifier for the DocBook XML 4.2 output
> processor to use:
>
> -//OASIS//DTD DocBook XML V4.2//EN # -
Hello all,
I have used LyX on and off for many years and, working sporadically
with TLDP [0], I have handled a few documents that were written in
LyX. Thank you to the LyX team for your work on this tool over the
years.
I have two questions today, after examining the DocBook XML output
http://jblevins.org/log/xml-tools
This is an other link where the author has written about his experiences
with various Latex to XML converters
ᐧ
On Sun, Mar 2, 2014 at 11:35 AM, Prannoy Pilligundla prannoy.b...@gmail.com
wrote:
I found an other software which does the same thing
http://www
http://jblevins.org/log/xml-tools
This is an other link where the author has written about his experiences
with various Latex to XML converters
ᐧ
On Sun, Mar 2, 2014 at 11:35 AM, Prannoy Pilligundla <prannoy.b...@gmail.com
> wrote:
> I found an other software which does the same thi
I just discovered the LaTeXtoXML project:
http://dlmf.nist.gov/LaTeXML/
which is actively developed and may actually come very close to what
we are aiming at. It is a perl-based attempt to recreate a subset of
TeX with XML output. It is very math-oriented and, from a first look,
not so
actually come very close to what
we are aiming at. It is a perl-based attempt to recreate a subset of
TeX with XML output. It is very math-oriented and, from a first look,
not so bibliorgaphy oriented (although it does parse bibtex).
did anyone know of it? I am going to try it on our test document
I just discovered the LaTeXtoXML project:
http://dlmf.nist.gov/LaTeXML/
which is actively developed and may actually come very close to what
we are aiming at. It is a perl-based attempt to recreate a subset of
TeX with XML output. It is very math-oriented and, from a first look,
not so
ely developed and may actually come very close to what
> we are aiming at. It is a perl-based attempt to recreate a subset of
> TeX with XML output. It is very math-oriented and, from a first look,
> not so bibliorgaphy oriented (although it does parse bibtex).
>
> did anyone know of
be an intrinsic xml format,
which can evolve without change its structure and has some great
advantages over the current plain text format. Conversely the elyxer,
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which
every one can work
Alex Vergara Gil wrote:
Do you mean a native LyX file format which would be the primary format,
or an auxiliary format for interfacing with external tools?
I mean xml as primary format.
Well, I wanted to know what Richard meant, but your opinion is welcome as
well;-)
If you have xml
be an intrinsic xml format,
which can evolve without change its structure and has some great
advantages over the current plain text format. Conversely the elyxer,
lyx2lyx and other scripts should need an upgrade.
My point is, Unless you have defined a static lyx format in which
every one can work
Alex Vergara Gil wrote:
>> Do you mean a native LyX file format which would be the primary format,
>> or an auxiliary format for interfacing with external tools?
>
> I mean xml as primary format.
Well, I wanted to know what Richard meant, but your opinion is welcome as
well
go
with LaTeX.
Stefano
Dear all
I´m a LyX enthusiast and I can see how great this software is because I have
used it for 5 years by now. I´ve always asked in this list for a static
target lyx format that should be an intrinsic xml format, which can evolve
without change its structure and has
module would still be format-dependent, unless we go
with LaTeX.
Stefano
Dear all
I´m a LyX enthusiast and I can see how great this software is because
I have used it for 5 years by now. I´ve always asked in this list for
a static target lyx format that should be an intrinsic xml format,
which
Richard Heck wrote:
On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:
I´m a LyX enthusiast and I can see how great this software is because
I have used it for 5 years by now. I´ve always asked in this list for
a static target lyx format that should be an intrinsic xml format,
which can evolve
Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools?
I mean xml as primary format.
The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems
go
with LaTeX.
Stefano
Dear all
I´m a LyX enthusiast and I can see how great this software is because I have
used it for 5 years by now. I´ve always asked in this list for a static
target lyx format that should be an intrinsic xml format, which can evolve
without change its structure and has
module would still be format-dependent, unless we go
with LaTeX.
Stefano
Dear all
I´m a LyX enthusiast and I can see how great this software is because
I have used it for 5 years by now. I´ve always asked in this list for
a static target lyx format that should be an intrinsic xml format,
which
Richard Heck wrote:
> On 02/27/2014 11:27 AM, Alex Vergara Gil wrote:
>>
>> I´m a LyX enthusiast and I can see how great this software is because
>> I have used it for 5 years by now. I´ve always asked in this list for
>> a static target lyx format that should be an int
Do you mean a native LyX file format which would be the primary format, or
an auxiliary format for interfacing with external tools?
I mean xml as primary format.
The native file
format would need to be non-static and would need format changes as LyX
develops (so would face similar problems
will discuss that face2face during the meeting.
You should bring mirror then, no one else in this thread is in
Milano.
Anyway it's too late, Richard already barricaded in
underground garage of his
house and won't show until 378 patches implementing xml is
done
ounes wrote:
> I will discuss that face2face during the meeting.
You should bring mirror then, no one else in this thread is in
Milano.
Anyway it's too late, Richard already barricaded in
underground garage of his
house and won't show until 3
1 - 100 of 1040 matches
Mail list logo
