DocBook change: use a stack of fonts

[Richard Kimberly Heck]

On 12/27/22 10:55, Thibaut Cuvelier wrote:
> 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.

That looks great. Yes, I overlooked the case you mention in the notes.

Riki

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lyx.org/pipermail/lyx-devel/attachments/20221227/2383aa2f/attachment.html>