The previous "the endpoints are inclusive" comment seems confusing. It's true
that the bounding box's max X equals the right-most coordinate, which suggests
<= instead of <, but that node's coordinate is itself exclusive. Consider the
solid 1-pixel square: (0, 0), (64, 0), (64, 64), (0, 64) in fixed.Point26_6
coordinates. The right-most coordinate is 64, and the bounding box's max X
equals 64, but rasterizing that square only affects sub-pixels up to but not
including 64.

Instead, it seems accurate to follow the fixed.Rectangle26_6 description, in
that the max values are exclusive.

LGTM=bsiegert
R=bsiegert
CC=golang-codereviews
https://codereview.appspot.com/60380043

The logic is a little clunky, but as before, let's get it right first,
then get it clean once we have a full battery of tests.

R=bsiegert
CC=golang-codereviews
https://codereview.appspot.com/50910043

R=bsiegert
CC=golang-dev, remyoudompheng
https://codereview.appspot.com/34700043

Also add API for vertical metrics.

R=bsiegert
CC=golang-dev, remyoudompheng
https://codereview.appspot.com/21330043

R=bsiegert
CC=golang-dev
https://codereview.appspot.com/14604044

R=bsiegert
CC=golang-dev
https://codereview.appspot.com/14548046

points accordingly.

Yes, it's a mess, but let's pass the tests first, and then refactor.

R=bsiegert
CC=golang-dev
https://codereview.appspot.com/14419052

R=bsiegert
CC=golang-dev
https://codereview.appspot.com/11983043

to package truetype.

R=bsiegert
CC=golang-dev
http://codereview.appspot.com/6427062

R=bsiegert
CC=golang-dev
http://codereview.appspot.com/6343091

R=gri, bsiegert
CC=golang-dev
http://codereview.appspot.com/6347057

Thanks to Jeff R. Allen <jra@nella.org> for the conversation that
led to this change.

benchmark              old ns/op    new ns/op    delta
BenchmarkDrawString     21168440     20143860   -4.84%

The number of mallocs per iteration is unchanged.

R=rsc, r
CC=golang-dev, jra
http://codereview.appspot.com/6304077

No code changes, just a copy/paste.

R=bradfitz
CC=golang-dev
http://codereview.appspot.com/6201052

.TTF files)

R=bradfitz
CC=golang-dev
http://codereview.appspot.com/6194050

I'm not sure why I put that limit in in the first place. I can't find
that limit in either the C Freetype code or the TTF spec.

R=bradfitz
CC=golang-dev
http://codereview.appspot.com/6201043

file offset.

R=bradfitz
CC=golang-dev
http://codereview.appspot.com/6198043

Also update freetype/truetype for s/int/rune/.

R=rsc, bradfitz
CC=golang-dev
http://codereview.appspot.com/5505067

R=rsc, r
CC=golang-dev
http://codereview.appspot.com/5339048

just version 2. The FTL (Freetype Licence) is still available. This
matches the original Freetype library (written in C).

This only expands and does not further restrict the licensing options
available to users of the freetype-go library.

R=adg
CC=golang-dev
http://codereview.appspot.com/1731049

R=r
CC=golang-dev
http://codereview.appspot.com/1196045

draw text onto an image.

This is a simple API that doesn't handle line breaking, ligatures,
right-to-left or vertical scripts, and other fancy features.

R=r, rsc
CC=golang-dev
http://codereview.appspot.com/1121045

Parsing a malformed TTF may result in an index out-of-bounds panic,
rather than guaranteeing to return an error. This may be tightened
in the future.

R=r, rsc
CC=golang-dev
http://codereview.appspot.com/940044