Mailing Lists: Apple Mailing Lists

Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Font scaling using AffineTransform



Jim Douglas
>I can't work out any coherent rules for what translation to apply in any
>situation, so this doesn't seem to be the basis for a workaround.

Great sample code.  I love a puzzle on a dismal Saturday afternoon.

Playing with the code a little while, I discovered:
  a) the translation to apply is independent of the scaling.
  b) the translation is related to the nominal original point-size.

In your example, you had:
        Font f = new Font("SansSerif", Font.BOLD, 12);
        ....
        a.translate(-6.5,-13);

12 is the nominal original point size, and 13 is 12+1.  The -6.5 is simply
-13/2, though in practice it works better to use 2.5, as in:
  private void tweak( AffineTransform a, int nominal )
  {
    double ty = nominal + 1.0D;
    double tx = ty / 2.5D;
    a.translate( -tx, -ty );
  }

This is only APPROXIMATE, but it works pretty well.  The tx calculation
still needs further divination.

I expanded your test case to also present a 3X nominal original size, using
both a scaled AffineTransform and literally multiplying the original size
by 3.  At 3X scaled and an original size of 18, the tx is pretty far off
with /2.0, and better with /2.5 yet still imperfect.

I suppose one could do a curve fit with enough data points and derive even
better parameters.

Things I didn't try:
  1) Other fonts.
  2) Scale transforms less than unity.
  3) Rotation transforms.


The real puzzle is what kind of haywire calculation is going on in the
first place that it needs to translate by those amounts in order to correct
it.  It seems like an elementary blunder that then cascades through the
rest of the calculations.

The one thing I can think of is that there's some original mistake in Y
that's based on the font's ascent or nominal point-size.  Since font
baseline (i.e. it's ascent height) is at coordinate 0,0, there's a
discernible "footprint" on the trail for that mistake.

The really weird one is why TX is TY/2.5, or whatever it turns out to be.
That one just seems wacko, because the X of a rendered glyph isn't offset
by ascent height.

Maybe there's less here than meets the eye, and I'm just reading imagined
patterns into clues.

Still, it looks like the beginnings of a workaround.

  -- GG


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden

This email sent to email@hidden



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.