On 2022-04-01 04:44, Thibaut Cuvelier wrote:
On Wed, 30 Mar 2022 at 07:29, Daniel <xraco...@gmx.de
<mailto:xraco...@gmx.de>> wrote:
On 2022-03-28 18:49, Thibaut Cuvelier wrote:
> On Mon, 21 Mar 2022 at 13:11, Lorenzo Bertini
> <lorenzobertin...@gmail.com <mailto:lorenzobertin...@gmail.com>
<mailto:lorenzobertin...@gmail.com
<mailto:lorenzobertin...@gmail.com>>> wrote:
>
> Il 21/03/22 11:49, Daniel ha scritto:
> > On 2022-03-21 10:55, Lorenzo Bertini wrote:
> >> There is some degree of duplication between Docbook and
LyXHTML
> code.
> >> I think its because the latter is much older and Thibaut
had to
> write
> >> its own to produce Docbook. This has been brought up also
when
> >> addressing MathML production. I agree LyX needs more
standard XML
> >> generating functions.
> >>
> >> Its part of a larger theme about XML production, and
there was a
> talk
> >> sometime ago about using a library for this.
> >
> > I might be misunderstanding your comment. But actually, I
wanted to
> > point not to the way XML is generated but more to the actual
> content,
> > for example, the specific attributes of an element which
seem to be
> > duplicated. But maybe that problem is somehow dependent on the
> general
> > generation of XML?
>
> Sorry, I meant that code duplication is probably due to the
different
> maintainers for the two formats and the fact that one is much
older and
> has been untouched for a long (LyXHTML). I remember Thibaut
saying he
> branched from LyXHTML knowingly, even if it would have meant
rewriting
> some stuff. Looking at your examples, this might be the case.
>
> I think a common interface to write XML elements like tables,
tags,
> etc,
> would help reduce this, but it will be a lot of effort. I'll
wait for
> Thibaut and Richard to chime in on this.
>
>
> There is already a generic interface for XML tags (but not
> tree-oriented, like almost all XML tools). However, it does not make
> sense to have a generic function for a table: CALS and HTML are two
> quite different formats; moreover, HTML tables in DocBook do not
always
> exactly match what HTML allows (mostly, HTML allows CSS, but DocBook
> forbids formatting).
Okay. As I said, I have no knowledge about DocBook. I was working on
adding support for line styles to LyXHTML and noticed that it felt
strange to work with the code when very similar code appeared in the
DocBook section.
DocBook does not support CSS Styles? Well, at least what I added does
not need to be duplicated for DocBook then. But what is
style
This attribute specifies style information for the current
element.
(https://tdg.docbook.org/tdg/5.0/html.td.html
<https://tdg.docbook.org/tdg/5.0/html.td.html>)?
You're right, td has a style attribute (it's quite exceptional in DocBook).
I've merged a lot of code between HTML and DocBook for lines in the last
three commits (c7896cf9, ec016162, 0ba1b68f). The codes for DocBook and
XHTML are harder to merge, I believe it's more open to discussion, hence
I'm attaching a patch to this email to gather feedback. I could go
further, but the main codes (::docbook and ::xhtml) differ more in their
preamble, I'd rather do that in a second step, after having some
feedback for the first one.
Thanks. As I said, I have no idea about docbook, but I guess others can
provide more valuable feedback. But did you happen to check whether it
conflicts with my patch? (https://www.lyx.org/trac/ticket/10154#comment:10)
Daniel
--
lyx-devel mailing list
lyx-devel@lists.lyx.org
http://lists.lyx.org/mailman/listinfo/lyx-devel
