Sciss wrote:
>i'm having a graphics problem ; on a panther / java 1.4 machine
>(where i developed originally), text is displayed about 2 pixels
>below the same display on tiger / java 1.5 . at first i thought it
>was a bug in my code when calculating the y coordinate using
>fontMetrics.getAscent() . but as you can see in the screenshots, this
>vertical shift also applies to regular gadgets like JTextField and
>JLabel (the "markers" text on the top left is a JLabel) ... it looks
>particularly bad with custom gadgets where text placement is critical
>like the green-background marker in the screenshot. interestingly,
>the labelling of the axis seems to be the same ... i looked in the
>code, and yes, there is a difference : in the axis i use (for
>whatever reason ;-) fm.getMaxDescent() instead of dealing with the
>ascent.
>
>i'm using Helvetica plain and Helvetica italic. Is this a bug in java
>or did apple silently change the fonts in an inconsistent way? i
>don't want to change all my code depending on whether i'm on the one
>or other system. will this get fixed?
For all practical purposes, you should just assume there are no consistent
font metrics. Not across OS releases, and not across Java versions or
releases, either. This is mainly because there are various differing
font-metrics bugs in every case on Mac OS X. This makes font handling, and
especially PRECISION font handling, such a thrilling experience.
For precision font handling, you can embed a font (e.g. a TrueType ttf
file) in your jar, and then load it using the Font class, or you cand
dynamically figure out what the OS and Java versions are and then set
appropriate adaptive parameters. If you do the former, there are STILL no
guarantees, due to bugs in embedded font handling across Java releases. If
you do the latter, there are no guarantees, either, because font metrics
can STILL change, either because Apple fixes font bugs in later releases,
or because the user installs a font of their own under an "assumed name".
The "Helvetica" you request has no guarantee of being the "Helvetica" you
want.
What I've done in the past is to write code that determines bounding-box
and baseline (the worst-behaving metrics) using fairly simple yet reliable
methods, e.g. FontMetrics.getStringBounds(), then apply parametric
adjustments based on system properties or on configurable values. I
usually store and encapsulate all this hackery in a class called Appearance
or Fashion, and then have all my OTHER classes call one of those methods to
get the font, its bounding box, its baseline, or whatever. Sometimes it's
even necessary to factor out the rendering to a Graphics or Graphics2D,
such as when you elide letters from a string until it fits within a certain
width.
Another thing I've found useful is to add code that renders a visible
bounding-box and baseline behind rendered text, so I can actually see
what's going on in the real catastrophic cases. This is typically a
conditional keyed to a system property. It doesn't appear on EVERY text,
like in every JLabel, just in the cases where precision matters or a font
is being rendered badly.
Separating out all the font-hackery makes it MUCH easier to deal with the
different adjustments or work-arounds you have to make. Not separating it
out makes it a LOT harder to fix problems, and when it comes to fonts, I
figure there will ALWAYS be some problem, even when it means taking out a
work-around when a bug gets fixed.
As I vaguely recall, I sometimes have to add adjustments for other
platforms, too, which can lead to a Class.forName() "plugin" that's keyed
to the OS name. And that isn't just because the same font name, e.g.
"Helvetica", can have different metrics across different platforms, because
there's no universal registry of unique font-names. It's because sometimes
the font that's installed under a particular name has certain, um,
peculiarities, for whatever reason.
In general, precision font handling in Java sucks. It sucks more in some
cases, like older Mac OS X or older Java versions, and it sucks less in
other cases. But I just assume it ALWAYS sucks, so I'll always have to
write SOME kind of parametric adjustment, or have to hard-wire it to a
specific font or small set of fonts with well-behaved characteristics.
It would be nice if things were different, but if you're targeting a range
of platforms, you either have to assume very little (be adaptive), or
bravely accept the consequences of your assumptions. YMMV.
On the plus side, once you get a usable Appearance or Fashion class, it's
pretty easily reusable across a broad range of cases and platforms.
-- 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
