Unwanted horizontal spacing in the diplomatic transcriptions

[gerritbruening]

DUPLICATE of faustedition/faust-gen#13

See
http://beta.faustedition.net/documentViewer.php?faustUri=faust://xml/document/faust/2.3/gsa_391347.xml&page=5&view=document
in comparison to
https://faustedition.uni-wuerzburg.de/new/document/faust/2.3/gsa_391347.xml#/5
In particular:

• freu t (anchor)
• Clytemnest en (anchor)
• Auserwählte n (anchor)

[thvitt]

It looks like the boxes (for, e.g., Clytemnest) is too large in the SVGs. I have not seen any CSS induced spacing for the affected boxes, so it seems to be a problem in the pre-rendered SVGs?

[thvitt]

Those cases that I could identify were consequences of invalid web font definitions in the generation pages, leading to different fonts (with different metrics) being used for calculating the boxes in the SVGs and actually rendering the text snippets in the users' browsers.

I believe to have fixed this in dev, if I have missed something, please reopen and link & describe cases that are still wrong in dev.

[gerritbruening]

Hm, when I look at
http://dev.faustedition.net/documentViewer.php?faustUri=faust://xml/document/faust/2.3/gsa_391347.xml&page=5&view=document
I still can see unwanted horizontal spacing.

[thvitt]

Current version of the rendering uses the same CSS for both rendering (cf. the 🐛 icon in the document viewer) and display, and there are still spacing issues.

Current hypothesis is that the SVG content is scaled somewhere in the rendered page, this would also explain the unwanted vertical space.

[thvitt]

Here is an example excerpt from 2 H S. 224.

(1) SVG as generated using PhantomJS:

<g class="text-wrapper" transform="matrix(1 0 0 1 0 0)">
  <rect class="bgBox hand-st material-t normal" height="23" width="336" x="0" y="-18"/>
  <text class="text hand-st material-t normal">Du kriegerzeugte, ſchlachterzogne, junge Brut</text>
</g>

(2) Debug HTML as generated using PhantomJS:

<g class="text-wrapper" transform="matrix(1 0 0 1 0 0)">
  <rect class="bgBox hand-st material-t normal" height="23" width="336" x="0" y="-18"></rect>
  <text class="text hand-st material-t normal">Du kriegerzeugte, ſchlachterzogne, junge Brut</text>
</g>

(3) The SVG from 1 copied into the documentViewer:

<g class="text-wrapper" transform="matrix(1 0 0 1 0 0)">
  <rect class="bgBox hand-st material-t normal" height="23" width="336" x="0" y="-18"></rect>
  <text class="text hand-st material-t normal" style="pointer-events: none;">Du kriegerzeugte, ſchlachterzogne, junge Brut</text>
</g>

(4) The excerpt as rendered in Firefox from debug.html:

<g class="text-wrapper" transform="matrix(1, 0, 0, 1, 0, 0)">
  <rect class="bgBox hand-st material-t normal" height="16.433332443237305" width="307.70001220703125" x="0" y="-13.600000381469727"></rect>
  <text class="text hand-st material-t normal">Du kriegerzeugte, ſchlachterzogne, junge Brut</text>
</g>

The XML samples have all been copied from the respective files (1+2) or from Firefox' debug window (3+4), and the XML has been canonicalized and indented in order to be comparable.

As can be seen, the stuff rendered by PhantomJS is never modified; it is just rendered with different, more appropriate coordinates in Firefox.

This may be the DPI issue 2.x versions of PhantomJS face (that are announced to be solved in 2.2), or it may be a general problem. Maybe try SlimerJS to confirm; and decide whether we can just wait for a fixed PhantomJS or switch to SlimerJS or whether we need to calibrate the generated SVGs to the users' browsers.

[thvitt]

The problem still exists with SlimerJS (faustedition/faust-gen#13) 😠 so it's probably an inclusion thing, not a rendering issue. Cf., e.g., Clytemneſten here and compare with the version rendered in the current browser.

[thvitt]

It is not an inclusion thing:

• The dimensions of the pre-generated files are slightly larger than those of the version rendered in-browser, both for the whole svg (417×631.55 vs. 379.5666…×585.083…) and for the text box 'Und als…Clytemneſt' (Width: 230 pre-rendered vs. 205.13333 rendered in-browser)
• The dimensions in the PDF and PNG screenshots that are taken during rendering are also wrong
• The font sizes are correct in all cases

So the basic problem is that the rendering process renders correctly when run from an interactive browser, but wrong when run from SlimerJS or PhantomJS. But why‽