You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently worked on getting a Hevea output for the Menhir manual -- see the corresponding merge request. There was a bug in the visual output that I had to fix, and I think this is a problem with Hevea: I believe that the spacing of the tabbing environment is wrong, at least for this use-case.
Menhir uses tabbing to show a textual representation of parse trees, see Figure 6 in my HTML rendering. In the PDF, it looks roughly as follows:
expression
IF expression THEN expression
IF expression THEN expression . ELSE expression
But the default translation of tabbing by Hevea uses the class cellpadding0 for HTML tables generated by tabbing, which sets padding:0; for the <td> columns, which results in the columns between next to each other with no space in between. The Hevea output looks like this:
expression
IF expression THENexpression
IF expression THEN expression . ELSE expression
For the Menhir manual, I implemented a workaround, which is to replace all occurrences of cellpadding0 by cellpadding1 in the generated HTML -- see the corresponding commit. This gives me a rendering closer to what LaTeX generates.
As far as I can tell, cellpadding0 is only used for the tabbing environment (open_tabbing in latexscan.mll). What is a reason for not using cellpadding1 there instead? In my case, using cellpadding0 is a rendering bug, but are there other cases where having any padding gives worse rendering? (Where LaTeX would itself not insert any spacing when using tabbing?)
I uploaded with this report a small ZIP archive repro-hevea-tabbing.zip which contains a minimal reproduction case. I also uploaded online the following files from this example:
repro-hevea-tabbing.html, which shows the native Hevea output and an image of the LaTeX translation: you see the rendering bug
repro-hevea-tabbing-fixed.html, which is the same file after replacing cellpadding0 with cellpadding1: it looks less wrong
The text was updated successfully, but these errors were encountered:
I recently worked on getting a Hevea output for the Menhir manual -- see the corresponding merge request. There was a bug in the visual output that I had to fix, and I think this is a problem with Hevea: I believe that the spacing of the
tabbing
environment is wrong, at least for this use-case.Menhir uses tabbing to show a textual representation of parse trees, see Figure 6 in my HTML rendering. In the PDF, it looks roughly as follows:
But the default translation of
tabbing
by Hevea uses the classcellpadding0
for HTML tables generated bytabbing
, which setspadding:0;
for the<td>
columns, which results in the columns between next to each other with no space in between. The Hevea output looks like this:For the Menhir manual, I implemented a workaround, which is to replace all occurrences of
cellpadding0
bycellpadding1
in the generated HTML -- see the corresponding commit. This gives me a rendering closer to what LaTeX generates.As far as I can tell,
cellpadding0
is only used for the tabbing environment (open_tabbing
in latexscan.mll). What is a reason for not usingcellpadding1
there instead? In my case, using cellpadding0 is a rendering bug, but are there other cases where having any padding gives worse rendering? (Where LaTeX would itself not insert any spacing when usingtabbing
?)I uploaded with this report a small ZIP archive
repro-hevea-tabbing.zip which contains a minimal reproduction case. I also uploaded online the following files from this example:
cellpadding0
withcellpadding1
: it looks less wrongThe text was updated successfully, but these errors were encountered: