[racket] how to get exact results from get-text-extent

Right, I meant "exact" in the Racket sense of "exact rational."

The broader issue I'm thinking about is what kind of units to use in a
typesetting system in order to get the best balance of precision and speed.

For instance, the flexibility of a 64-bit flonum doesn't necessarily buy
you anything over a 64-bit fixnum, since typesetting systems have a
practical limit on both precision (in the subpixel direction) and scale (in
the megapixel direction).

TeX, for instance, is based on a "scaled point" which represents 1/65536th
of a point, with a max dimension of 2^30 scaled points, or about 19 feet.
One could imagine a 64-bit version of this concept that extends both the
scale and precision (to ludicrous degrees) while remaining a fixnum (which
I gather from the docs are typically cheapest).





On Mon, Dec 1, 2014 at 2:01 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:

> We should probably improve the contracts on `racket/draw` to promise
> flonum results for text metrics. The intent is to make metric-derived
> calculations have a predictable cost, instead of potentially triggering
> expensive exact arithmetic.
>
> When you say that Pango produces "exact" results, do you mean "integer"
> or "exact rational"? The latter is certainly true: Pango's raw API
> produces integers to be divided by 1024 to convert to drawing units.
> Taking that conversion into account, Pango doesn't always produce
> integer drawing units (at least on some platforms; I'm not sure about
> all). Even so, the intent is that representing an integer divided by
> 1024 as a flonum will not normally lose any prevision (i.e., for normal
> drawing sizes), and so `inexact->exact` on the immediate result from
> `racket/draw` recovers the exact Pango result when exact arithmetic is
> specifically wanted.
>
> At Mon, 1 Dec 2014 11:56:12 -0800, Matthew Butterick wrote:
> > The `get-text-extent` method in racket/draw does not contractually
> guarantee
> > either exact or inexact numbers, though in practice I find it produces
> inexact.
> >
> > This function, however, calls into the Pango text-layout system. I find
> that
> > when I invoke Pango's text measuring directly through the FFI, it
> produces
> > exact results.
> >
> > Is this difference in behavior deliberate, or does `get-text-extent`
> preserve
> > exactness under certain circumstances?
> >
> >
> > ____________________
> >   Racket Users list:
> >   http://lists.racket-lang.org/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20141201/ef3731cd/attachment.html>