Jim Douglas <email@hidden> wrote:
>Thanks for the comments, Greg. The most confusing thing about this to
>me is hearing that Apple has apparently known about this for almost two
>years; I don't understand why it hasn't been fixed.
I don't bother trying to understand why something isn't fixed, because it
make no difference to anything I can do about it. For example, does it
make a difference whether it's due to technical difficulty, a side-effect
of another bug, or simply engineering cost/staffing tradeoffs? I don't see
any difference, because if the result is still "bug not fixed", the outcome
for me is identical: bug not fixed, ergo create workaround.
>I found a few more complexities...if you find offsets that work for one
>JComponent, they don't work for another one; here's a sample with
>JLabel and JButton; the button text looks ok, but the label text is
>shifted too far to the left:
That may be entirely due to the component type. A JButton in Aqua has a
certain amount of padding between the text and each end of the button's
rendered shape. This is to account for the semi-circular ends of Aqua
buttons, but it ends up providing some "margin" for the mis-metric'ed Font
to intrude into yet stay within the control's bounds. A JLabel has no such
paddding. Instead, the edge of the JLabel is almost flush with the
calculated bounding box of the text. Thus, JLabels have almost no margin
for fonts with off-kilter metrics. Make your JLabels opaque with a bkgd
color and you'll see.
Unfortunately, bkgd color is ignored for Aqua JButtons.
Also try a JTextField, which looks pretty screwy. It's off the left edge,
and drag-selecting letters has serious rendering problems. Probably due to
the difference between rendering a string of chars vs. rendering a single
char with the screwy metrics. Blecch.
Also try a subclassed JComponent that renders some text with a visible
bounding box. That'll be screwy, too.
This whole process is really just taking shots in the dark and trying to
figure out what you hit by the noise it makes. There's no explanation of
exactly how the derived font's transform is getting screwed up, so it
really shouldn't be surprising that it misbehaves as badly as it does. If
there were a complete coherent explanation, a theory, then a consistent
workaround might be devisable. Without a unifying theory, it's all ad
hoccery and phlogiston.
-- 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
