freenode/#clim - IRC Chatlog
Search
2:44:01
loke
jackdaniel: I have noted there are two differences between bounding-rectangle and text-size. Both are useful.
2:44:39
loke
And as Climaxima is probably one of the most text-measurement-heavy applications, m taking advantage of both to a very high extent.
4:15:55
loke
jackdaniel: The height (top and bottom of the bounding box) are different. The text-size function returns the actual pixel boundaries, while the bounding rectangle uses the font height and descender.
4:17:29
loke
Note that the truetype renderer's backend implementation of text-size doesn't actually return the correct values. It returns 7 values, four of which are the ascent and descent of the font, followed by the asecent and descent of the actual text. The trueype renderer returns the dame values for these, while the freetype renderer returns the correct values.
4:19:04
loke
So in Climaxima, I'm using text-size when I need to perfectly align text based on the content (i.e. when choosing where do draw the exponent, or where to put the limits in a SIGMA operation)
4:19:42
loke
The bounding box is used for regular alignment where the actual string doesn't matter, since it uses the font dimensions rather than the text dimension.
4:39:51
jackdaniel
you mean that bounding-box shouldn't take into account each glyph but rather return some approximate value taken from font-ascent/descent and average character-width? or what?
4:42:21
loke
What I'm saying is that the current implementation uses the font ascent/descent when computing the height of the bounding-box.
4:43:44
loke
Persoanlly, I don't agree with that, but that's not really relevant. We discussed that back when I implemented the freetype renderer, and it was pointed out (by you or beach, I think?) that the bounding box height should not be affected by the actual characters that are displayed in it, as that would affect the height of a clickable presentation.
4:44:57
loke
And I have no problems using TEXT-SIZE to determine the actual dimensions of the text. Using TEXT-SIZE givens me the pixel-perfect dimensions, which is absolutely required by Climaxima.
4:47:52
loke
It's clear that both pieces of information (font ascent/descent and actual text ascent/descent) is needed at different times. Both of these pieces of information is returned by FONT-TEXT-EXTENTS, but, as I mentioned earlier, the truetype renderer doesn't actually compute the text ascent/descent, but simply returns the font values for both.
4:50:27
loke
You can see the difference in the return alues of FONT-TEXT-EXTENDS for the freetype vs. the truetype renderers.
4:51:30
loke
The text ascent/descent is returned in the second and third return values, while the font extents are returned as the sixth and seventh values.
4:52:51
loke
Oh, and one last thing: The width is always computed from the text content of course. This is all about the height (i.e. the ascent and descent)
4:58:50
jackdaniel
(that means, that font-text-extents misses font-left and font-right, because left/right bearings should be taken into account too
4:59:23
jackdaniel
luckily it is an internal itnerface, so there is no controversy with adding more values
5:49:50
jackdaniel
another finding: our text-style-to-x-font is redundant with (standard) text-style-mapping
5:51:56
loke
Speaking of FONT-TEXT-EXTENTS. I have no idea what the purpose of the eigth and ninth values are supposed to be. If I recall correctly, no code uses them.
5:53:37
jackdaniel
text direction should be implied by the advance-width/advance-height, eventually by toward-x toward-y (i.e for vertical text with "normally" oriented glyphs)
5:54:06
loke
If the new truetype renderer can get the extents correct (needs to be pixel perfrect) I'll be happy to try to adapt Climaxima to be able to use it.
5:55:11
loke
The other feature that should be standardised is a way to install custom fonts. Climaxima ships with its own fonts, and there needs to be a way to tell CLIM to use it.