Open plcplc opened 7 years ago
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)
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.
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
Measure
s 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?
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 mkQD
ed 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.
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!
It seems that
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 renderingversus
Sifting through the documentation of
diagrams-core
reveals thatFontSize
is a measured attribute, which cannot simply be extracted viagetAttr
, resulting intextLineBoundedIO
gettingNothing
, 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 totextLineBoundedIO
is simply thrown away by the current implementation. I would expect it to be retained in the resulting Diagram.