Text extents about freetype-go HOT 16 OPEN

It looks to me like DrawString in freetype.go needs to be factored out into 
drawOrMeasureString(string, point, measure bool), which checks if measure == 
true and skips the drawing. Then there would be two public entry points, 
DrawString and MeasureString (same args, same return).

Tell me if you want me to submit a patch doing this.

A patch that implements what I mentioned is attached. See if it solves your 
problem.

Ah nice. I haven't tested it quite yet, but I understand what you did. Thanks!

So, the only caveat that remains is: how does one make sure the 'y' returned 
from MeasureString covers the bounding box of the text? (As of right now, the 
'y' seems to correspond to the base line of the text, so that if it's used as 
the Point.Max.Y for a bounding box, the box will cut off all letters that sink 
below that base line. Like the tail in 'y' or 'j'.)

I'm sure there's a technical word for the "base line of the text", but I'm not 
sure what it is. Am I making any sense?

(It is very possible that it isn't the job of freetype-go to do this 
computation, and that it's up to me to do it. I'm just not sure how.)

Once again, thanks! Your patch is appreciated.

Maintainers: is there any chance of getting this patch applied upstream?

Oh, right, I got distracted and forgot about height. I'll take another try at 
it.

Well thinking some more, I see that I totally screwed this up, not even the 
signature is right. The correct signature would probably be 
MeasureString(string) (canvas image.Point, start raster.Point), so that a 
caller like you can use it to decide how big of a canvas to allocate and where 
to draw on it to ensure that all pixels are shown.

example/freetype/main.go shows an overly simplistic way of calculating the 
location of the next line of text, which is pt.Y += c.PointToFix32(*size * 
*spacing). For your purposes (allocating the minimal canvas) you don't want to 
fudge it with a spacing factor, but actually know the farthest down from your 
origin point that pixels will be drawn. That dimension is known to DrawString 
down inside of it's per rune loop, so calculating it in MeasureString should be 
possible as well.

Don't hold your breath for an update to the patch; I'm not familiar enough with 
this code to make it work in the time I have available. Sorry.

Actually, I don't think you screwed it up. raster.Point seems to be what 
freetype-go wants to return, and that it's up to the caller to convert them. 
(I've been doing that.) Maybe that should be changed, but I'll leave that up to 
the maintainer's discretion.

As for discovering point.Max.Y, perhaps I can use 'glyphRect' to compute it? 
i.e., in the per rune loop:

p.Y = max(p.Y, orig.Y + c.FUnitToFix32(glyphRect.Dy()))

Where 'orig' is a copy of the original point passed to DrawString.

Finally, a question for the maintainer: *should* this calculation of Y be the 
value returned by DrawString, or is this an entirely separate computation? As 
far as I can tell, the Y value returned is the same as the Y value put in, so 
perhaps this computation is desirable.

When I get home, I'll work on another patch that tries to incorporate these 
changes.

No worries Jeff, thanks a lot for your help! You shoved me in the appropriate 
direction :-)

Yeah, package freetype needs to expose font metrics in some way. I'd rather 
hold off on that until the hinting code lands, though, as hinting affects 
metrics. Hinting has recently pushed the scale computation out of package 
freetype and into package truetype.

Also, golang-dev mail from long, long ago notes that ideally the API would let 
you e.g. change font colors while preserving kerning. Thus, the actual API 
design might need some deep thought.

Sorry for the late response, but I had a typo in my mail setup and wasn't 
getting freetype-go bug mail.

Okay, I've finally cobbled something together that appears to work. I've added 
a separate MeasureString method, which I hope returns the width/height of the 
bounding box containing the text provided.

I know next to nothing about font rendering and hacked this together based on 
other code in the package. It's likely I've done something wrong, but I thought 
it'd be nice to get this issue rolling. It's really awkward to render text 
without it.

I'm hoping that this, or something similar, will be added to freetype-go. For 
now, I have a clone: http://code.google.com/r/jamslam-freetype-go/

Nigel: comments are welcome!

Hello All, I'm curious if this is still holding on additional code before being 
added to the package. Is the patch provided the only means of getting this sort 
of functionality added?

As far as I know, yes. I'm still actively using my fork (jamslam-freetype-go) 
in my window manager until it gets fixed upstream.

Yes, hinting isn't completely implemented yet. It's a lot closer than when 
comment #9 was written, but it's still not complete.

The vg package from gonum/plot has code for computing these metrics.
You can find it here: https://github.com/gonum/plot/blob/master/vg/font.go.

It works OK, but it's not exactly right. For one, the scaling is a hack that I 
mostly made up. Everything else I tried didn't seem to work. I am also 
suspicious of the bounding boxes that freetype-go computes. They seem to be too 
big in the Y direction. At least, visually, they seem larger than line heights 
for the same fonts by other programs. This isn't a big problem unless you want 
to draw highlighted text with a shaded background.

I think that the bounding boxes are "too tall" for use as ascent and descent 
because they are computed from the bounds in the head table. Ascent and 
descent, for horizontal fonts should come from the hhea table. Would it be 
possible to expose this information?

In fact, I'll just open a separate issue for it.