formulas creating invalid HTML code (Origin: bugzilla #746162)

[doxygen]

status RESOLVED severity normal in component general for ---
Reported in version 1.8.9.1 on platform Other
Assigned to: Dimitri van Heesch

Original attachment names and IDs:

• doxygenbug.tgz (ID 299331)

On 2015-03-13 15:34:36 +0000, Stefan Vigerske wrote:

Created attachment 299331
doxygen project to reproduce the issue

A doxygen code like

/** \mainpage

<center>
\f$a\f$ b \f[c \f]
</center>

*/

generates an HTML code that does not validate:

<div class="textblock"><center> <img class="formulaInl" alt="$a$" src="form_0.png"/> b </p><p class="formulaDsp">
<img class="formulaDsp" alt="\[c \]" src="form_1.png"/>
</p>
 </center> </div>

That is, after "b" is printed, Doxygen adds a "</p>", while there is no opening "<p>".

If I change the code to

/** \mainpage

<center>
\f$a\f$ b

\f[c \f]
</center>

*/

the generated HTML code is valid:

<div class="textblock"><center> <img class="formulaInl" alt="$a$" src="form_0.png"/> b</center><center> <p class="formulaDsp">
<img class="formulaDsp" alt="\[c \]" src="form_1.png"/>
</p>
 </center> </div>

On 2015-11-10 16:04:29 +0000, Stefan Vigerske wrote:

Our workarounds for issues that seem to be related to this bug are growing.
Can you give a hint where to start looking in the doxygen source if I were trying to come up with a fix for this?

On 2015-11-10 19:19:05 +0000, albert wrote:

The </p> is written in docvisitor.cpp in the routine forceEndParagraph which is called from HtmlDocVisitor::visit(DocFormula *f), so this might be the starting point. There is probably also a relation with void HtmlDocVisitor::visit(DocStyleChange *s) and specifically the case DocStyleChange::Center

On 2015-11-13 16:09:53 +0000, Stefan Vigerske wrote:

Thanks for the hints. It's good to know where the "</p>" comes from.

So, forceEndParagraph(), which writes the </p> does that if
(n->parent() && n->parent()->kind()==DocNode::Kind_Para)
and certain other conditions on the children of n are satisfied.

Here, n is the node for the "\f[c \f]" formula.
And n->parent() is a node of the Kind_Para kind that is actually processed before the DocStyleChange-node that holds the "<center>" marker.

So doxygen does not seem to make a distinction into hierarchies on the input "<center>\f$a\f$ b \f[c \f]</center>". I mean, why isn't the DocStyleChange node ("<center>") the parent of the nodes for "\f$a\f$", "b", and "\f[c \f]" ?

At the moment, it just puts in a "</p>" and doesn't bother that it has opened a "<center>" before.

Sorry, this isn't the "ok, I have a quick look and come up with a patch"-reply that I had hoped for.

On 2015-12-26 15:30:09 +0000, Dimitri van Heesch wrote:

I considered making the style change nodes part of the hierarchy, but this makes the parser a lot more complex. Instead, I decided to keep the style changes as "delta" nodes, and add a bit more complexity to the html output to produce proper output also in this case.

Although this is an improvement, it is not perfect. If you for instance use <b>..</b> across commands that need to be outside of a <p>..</p>, then one can still produce invalid html output. In the ideal situation the user would be present with a warning from the parser, or the bold section would nicely be broken up in parts.

On 2015-12-30 10:19:52 +0000, Dimitri van Heesch wrote:

This bug was previously marked ASSIGNED, which means it should be fixed in
doxygen version 1.8.11. Please verify if this is indeed the case. Reopen the
bug if you think it is not fixed and please include any additional information
that you think can be relevant (preferably in the form of a self-contained example).

On 2016-01-22 04:54:03 +0000, Stefan Vigerske wrote:

Thank you very much. From a quick look, it seems that the new doxygen has this fixed, indeed.