Spacing / coordinate issues for diplomatic transcripts

[thvitt]

See also faustedition/faust-web#22

The pre-generation of the diplomatic transcript SVGs causes spacing / scaling issues for the typeset texts. Differences can be observed in the dev version using the bug and pdf buttons.

• optimal positioning is appearently achived when rendering in the target browser (bug button). This takes quite a while, however, so no productive version.
• PDFs are usable when rendered using PhantomJS 2.1.0-24-gd038837, although inter-line spacing appears wider than in the firefox in-browser rendering.
• inserting the pre-rendered SVGs into the site seems to cause unwanted scaling, though, with the effect that the individual boxes (calculated in PhantomJS) are slightly larger than required for rendering the text in Firefox. This is especially visible when there are multiple boxes in one line.

[thvitt]

The main remaining issue is an inclusion problem that can be observed by replacing documentViewer in the URL with debug.html or debug2.html: When the pre-rendered SVG is included, it is scaled slightly larger, but the font sizes remain the same, thus messing up the spacing (most visible: causing gaps in lines that consist of multiple boxes).

I've no idea where this scaling comes from and how to avoid it. It even appears in debug2.html, which is very simplistic, so its probably somewhere in the CSS?

[thvitt]

When using SlimerJS instead of PhantomJS, the horizontal offsets are even in the generated PDF – cf., e.g., the interpunction at the end of lines in lower parts of 2 H p. 109

[gerritbruening]

Test cases:

• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=1&view=facsimile_document
• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=10&view=facsimile_document (slightly)
• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=11&view=facsimile_document ("Füsse")
• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=19&view=facsimile_document
• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=21&view=facsimile_document
• http://dev.faustedition.net/documentViewer?faustUri=faust://xml/document/test/test.xml&page=22&view=facsimile_document

[wissenbach]

This is the same bug as (or rather underlying cause of) faustedition/faust-web#22. I prefer the discussion in this project (faust-gen) as it is the appropriate place, but that other issue contains valuable information, too.

[thvitt]

As an experiment, I've modified the CSS in order to use the browser's default fonts (CSS font family names serif, sans-serif and monospace) and run a SVG rendering using SlimerJS. The result seems to show almost correct measurements:

Testhandschrift rendering with default fonts (ZIP, 1.7MB)

[thvitt]

It might be a workaround to try to prepare a browser profile that uses Ubuntu / Gentium / Ubuntu Mono as default fonts for sans-serif / serif / monospace …

[gerritbruening]

It seems as if underlinings are expanded as a result of the longer boxes:
http://dev.faustedition.net/documentViewer.php?faustUri=faust://xml/document/faust/2/gsa_391098.xml&page=385&view=document
(see "Gretchen")
And it seems as if this does not happen when xml:space="preserve" is applied (compare "Gretchen" with the underlinings in the previous line).
Same applies to strikethroughs.

[wissenbach]

In c27fc3d and b861c52, I included Web Font Loader (https://github.com/typekit/webfontloader). This is what is used by https://github.com/millermedeiros/requirejs-plugins which @thvitt mentioned.
If you set Faust.TranscriptConfiguration.forceFontLoading=true in transcript-configuration-faust.js, you can test it in your own browser using debug.html. Unfortunately, Web Font Loader claims my browsers failed to load the web fonts, and I could not figure out why it says that.

[thvitt]

Build still delivers a different result than running the maven script by hand, this is all very strange

[thvitt]

Maybe headless chromium is worthwhile evaluating, e.g., remote controlled using selenium or chrome-remote-interface. PhantomJS is not developed any longer, and SlimerJS development seems to have stalled, as well.

[thvitt]

Here an example (2 III H.1 S.5, differences marked:
Current dev rendering using slimerjs/Firefox:

Puppeteer / Chromium --headless rendering: