Weasyprint: Fix rendering of KaTeX output

[mbarkhau]

As recommended by @liZe in #59 I'm opening a separate issue to fix the rendering of this test page: https://gist.github.com/mbarkhau/ff263164cd162ff1fd734c2b0ce23241

The output is generated by KaTeX on Node.js, so JavaScript is not required to render the formulas, only HTML and CSS.

Running this file through WeasyPrint produces some warnings, but I would ignore those for this issue, as I was able to comment them out locally without affecting the rendering.

[mbarkhau]

@liZe also mentioned that the square root symbols are not rendered due to #75, so that should also be considered out of scope for this issue.

[mbarkhau]

I've updated the gist so that it doesn't use inline <svg> elements for the square roots and instead uses images with base64 encoded data. There are also some rendering issues with those:

Chrome

WeasyPrint

[liZe]

I've fixed the position of superscript. The problem was caused by the wrong position of inline table's baseline.

We now have to fix square root symbols and the circumflex position.

[liZe]

The circumflex position is OK now. Lines larger than their parents were horizontally aligned, but it's not allowed by the spec.

[liZe]

I think that everything's OK now. the first page of your updated sample looks the same between my browsers and WeasyPrint. The ones with inline svg tags are broken because of #75.

The bugs closed thanks to this issue are corner cases of rarely used features, it was cool to fix them:

• Table rows now have a baseline when their cells are not baseline-aligned (5877056).
• Inline table are vertically aligned with their first row (9012888).
• Lines larger than their parents are not horizontally aligned anymore (76479de).
• Size of SVG files is now forced, not hinted (37e788e).
• Bonus in CairoSVG: ratio and alignment set in the root svg tag are now handled (0d71521) and respected with forced sizes (889ee3f).

Thanks a lot for this bug report and for the samples, it was hard to debug but quite simple to fix. It's really good news to have this kind of bugs on rarely used features, as we blindly have to follow what the spec tells and see the result work like a charm. It makes me believe that the rest of the code is quite OK :smile:.

[mbarkhau]

Wonderful to hear, thank you very much for the fixes.