Text is positioned on bottom edge of bounding box, not on baseline

[bergey]

When Text alignment is BaselineText, the local origin, from Diagrams' point of view, is on the baseline. In the Renderable instance for Text, refY should be the vertical distance from the top of the string to the baseline, not the height of the bounding box. (At least, I think Rasterific & FontyFruity place the origin & axes that way.)

This was reported in timbod7/haskell-chart#65 which has some supporting images.

The Cairo Backend is pretty similar to Rasterific in this area. Pango provides a function to locate the baseline; I'm not sure if FontyFruity does yet. SVG is quite different.

[mmaz]

Hi, I noticed a kerning discrepancy in the diagrams-rasterific backend. Is it possibly due to this issue, or something upstream? I have tried to create a minimal example for reproducing the issue, but I wouldn't be surprised if the difference I'm seeing is platform-specific. I'm on OSX, and I have locally installed the truetype font Lato from Google's webfonts repo. When I run the following script with stack example-svg.hs :

#!/usr/bin/env stack
-- stack --resolver lts-3.5 --install-ghc runghc --package diagrams
{-# LANGUAGE NoMonomorphismRestriction #-}
import Diagrams.Prelude
import Diagrams.Backend.SVG

d :: Diagram B
d = text "QRSTUVqrstuv" # font "Lato" <> rect 10 2 # fc white

main = renderSVG "test.svg" (mkWidth 400) d

in the SVG output, the uppercase T and lowercase t "correctly" butt against U/u (as seen on the left side of the example screenshot included below - I am assuming that Safari is relying on OSX's kerning support for this)

However, the following, after running with stack example-rasterific.hs,

#!/usr/bin/env stack
-- stack --resolver lts-3.5 --install-ghc runghc --package diagrams --package diagrams-rasterific
{-# LANGUAGE NoMonomorphismRestriction #-}
import Diagrams.Prelude
import Diagrams.Backend.Rasterific

d :: Diagram B
d = text "QRSTUVqrstuv" # font "Lato" <> rect 10 2 # fc white

main = renderRasterific "test.png" (mkWidth 400) d

contains "incorrect" kerning for TU and tu in the output PNG file (on the right in the below screenshot).

Thoughts? Lastly, please forgive my casual tossing about of 'correct/incorrect' labels above regarding kerning; I fully appreciate how tricky consistent font rendering is (especially across platforms!) and I am eternally grateful to the maintainers, for both diagrams and all the wonderful backends! It is an indispensable library to me.

[jeffreyrosenbluth]

I don't even think diagrams-rasterific currently has the ability to use fonts that are not internal to the system. I.e., ... font "Lato" <> ... does not effect the choice of font, which is open sans in rasterific.
So one thing you might be noticing is the difference between open sans and Lato. Even so the kerning issue seems to far off for this to explain and my guess is that it's a problem with rasterific/fonty-fruity.

[bergey]

It looks like FontyFruity-0.4.2 exposes the baseline height that we need. (Twinside/FontyFruity@de4d69f) This should be fairly straightforward now.