DocBook change: use a stack of fonts

[Thibaut Cuvelier]

On Tue, 27 Dec 2022 at 05:42, Richard Kimberly Heck <rikiheck at gmail.com>
wrote:

> On 12/26/22 21:46, Thibaut Cuvelier wrote:
>
> On Tue, 27 Dec 2022 at 03:20, Richard Kimberly Heck <rikiheck at gmail.com>
> wrote:
>
>> On 12/26/22 20:13, Thibaut Cuvelier wrote:
>> > Dear list,
>> >
>> > To solve https://www.lyx.org/trac/ticket/12585, I wrote the attached
>> > patch. Basically, LyX now considers the order of font tags when
>> > closing them, otherwise you get strange results like in the ticket.
>> > The bug is quite serious, actually, even though I don't believe many
>> > users will hit it.
>>
>> I struggled with that when writing the original XHTML code. It's hard to
>> get right. I know it sometimes would fail. Is this same code also used
>> with XHTML now? Or would it need to be adapted for that case?
>>
>
> I've tested this case and it looks like the XHTML code did the right thing
> there. It's a part I rewrote for DocBook, introducing a few bugs.Here is
> the output from XHTML for the same file:
>
> <div class='standard' id='magicparlabel-1'>norm <em>emph
> <b>emph-bold</b></em><b> bold</b> norm</div>
>
> I don't understand why it is producing the right output while DocBook did
> not. Maybe the pending tags or the special code for font tags from
> XMLStream kick in. If that's the case, it's a bit strange that XMLStream
> deals with this kind of issue (it feels like XMLStream is doing work at
> multiple levels of abstraction).
>
> I wish I'd commented this code a bit more. I thought I did that pretty
> well.
>
> Anyway, after digging into it, the magic happens in
> XMLStream::operator<<(EndTag), though the font part specifically is handled
> in Paragraph::simpleLyXHTMLOnePar.
>
Thanks for having a second look. I reworked my patch to use the existing
features of XMLStream: the bug is due to a faulty comparison between tags.
The new patch is much smaller and yields the same benefits while being
easier to debug. There are no newer features of C++ used here. I've
explained more details in the commit message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221227/9a4e482b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-XML-overhaul-the-tag-comparison-operators.patch
Type: application/octet-stream
Size: 5637 bytes
Desc: not available
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221227/9a4e482b/attachment-0001.obj>