Text envelope generation is fontsize ignorant

[plcplc]

It seems that

t <- textLineBoundedIO (mempty # fontSizeL 20) (Text mempty BoxbasealignedText "Hello World")

results in the envelope of t being computed at size 12 (px/pt/?), as witnessed by the discrepancy between the size of the text and its envelope by rendering

(t # showEnvelope)

versus

(t # fontSize (local 12) # showEnvelope)

Sifting through the documentation of diagrams-core reveals that FontSize is a measured attribute, which cannot simply be extracted via getAttr, resulting in textLineBoundedIO getting Nothing, and surely , fmap getFontSize (getAttr (mempty # fontSizeL 12)) == Nothing. I'm not sure what would be a good fix to this, as we cannot reasonably know what to pass to pango at this point, as the proper font size to select depends on the size the text eventually ends up at when rendered. Or if it is safe as long as the font size measure is Local?

Additionally, the fontSize attribute in the style argument to textLineBoundedIO is simply thrown away by the current implementation. I would expect it to be retained in the resulting Diagram.

[plcplc]

While I'm at it, it also seems that the origin of the text is outside the envelope at the baseline, as witnessed by the loop in the shown envelope.

Attempting to render text with BoxAlignedText 0.5 0.5 together with showEnvelope and showOrigin gives the below result:

(which I'm not sure how to interpret. It seems that the origin is placed correctly in the center of the text, but completely off with respect to the envelope)

[leftaroundabout]

Yeah, there's definitely some very strange stuff going on at the Pango interface. (When I added text annotations to dynamic-plot, I never really understood how the boxes work out, but with some trial&error I was able to get the results I wanted. Hardly satisfying...)

I think it would be good to make some test code that allows directly comparing the results of SVGFonts text for reference with those generated by diagrams-cairo / Pango. That will hopefully point us to where the problem lies.

[bergey]

Thanks for reporting this. Sorry the Cairo.Text module is so under-tested & under-documented.

As you have noticed, Pango needs to know the final rendering size of the Diagram in order to layout / measure text. I think the Cairo.Text functions need to be passed a Diagram after adjustDia2D has been called, and possibly also after Global Measures have been calculated. In other words textLineBoundedIO has the same interface as layoutStyledText and needs to be called deep in the middle of Diagram rendering, as the later is. I don't remember the details, but I can dig into this more on Thursday.

I believe it is correct for the origin to be at the baseline. I'm surprised that Pango reports a logical extent that doesn't include the baseline, and doesn't include leading above either. These dimensions are part of the font. What font is this? It's possible that I misunderstand what Pango means by "logical extents", or maybe I just swapped fst and snd.

Additionally, the fontSize attribute in the style argument to textLineBoundedIO is simply thrown away by the current implementation. I would expect it to be retained in the resulting Diagram.

I think you're right. Can you send a PR to correct this?

[plcplc]

I believe it is correct for the origin to be at the baseline.

Agreed. Makes sense.

I'm surprised that Pango reports a logical extent that doesn't include the baseline, and doesn't include leading above either. These dimensions are part of the font. What font is this? It's possible that I misunderstand what Pango means by "logical extents", or maybe I just swapped fst and snd.

Yes. I think you swapped them. Funnily, I only realised that when looking at the pango docs, thinking the haddocks be wrong as they mention the result in the order "logical and ink". Only just realised that the haddocks also include an annotation to the result. Guess I'm not used to reading those.

I think you're right. Can you send a PR to correct this?

I'll certainly give it a go. That change on its own is certainly easy enough. However, it's not all that satisfying on its own as the origin and envelope are still a bit messed up.

Would you mind if I introduced a BoxAlignedText aware placement of origin? Also, how about equipping the mkQDed text diagram with the trace of the bounding rectangle? That way other parts of the diagram can at least get some crude idea of the size of texts in the diagram.

[bergey]

Would you mind if I introduced a BoxAlignedText aware placement of origin? Also, how about equipping the mkQDed text diagram with the trace of the bounding rectangle? That way other parts of the diagram can at least get some crude idea of the size of texts in the diagram.

Those both sound like good ideas. Thank you!