Closed cspiel closed 3 years ago
Unfortunately, this PR introduces a regression, consider the following latex code:
\documentclass{article}
\usepackage[utf8]{inputenc}
\begin{document}
\begin{center}
\begin{tabular}{c}
\hline
Coucou coucou coucou coucou\\
Coucou coucou\\
\hline
\end{tabular}
\end{center}
\end{document}
Previous rendering is like this (\hline's are apparent): While the new rendering is like that (\hline's have disappeared):
@maranget - THX for checking!
It looks like we always have had two distinct cases of horizontal rules.
A standalone case (e.g. \hline
) and another, where a style
attribute
is active alongside with the class (\@hr
). The last patch honors this
distinction.
Alternative title: "The Optimizer Strikes Back!"
The current definition of CSS class
horizontal-rule
sets bothheight
andwidth
. Macro\@hr
uses classhorizontal-rule
, but overridesheight
andwidth
with astyle
attribute to control the shape of the rule as requested by the macros' actual arguments.If the optimizer decides to hoist this
style
and convert it to a CSS class the precedence rules change: Classes are applied in their order of definition. The optimizer sorts all classes into alphabetical order and uses the prefixc
for its own classes. That way the style hoisted into classc###
always ends up before classhorizontal-rule
and the style'sheight
andwidth
thus are shadowed.The last item of the following example generates different horizontal rules depending whether translated with or without
-O
.This P/R suggests to drop both
height
andwidth
from classhorizontal-rule
to recover consistent behavior.