Ron,
Whoa, a lot of questions! I'll start from the top.
WYSIWYG is never perfectly attainable, regardless of AA. Printer resolution is
generally much greater than screen resolution. When you send a print job to a
printer, you generally want to take advantage of the greater spatial resolution
to more accurately render your text. Have you never had the problem where a
document looked different on the screen than it does when sent to a printer?
This nasty problem crops up mainly because of the differences in font metrics
between a printer-resident font and the font installed on your hard drive.
Microsoft Word solves this problem by using the metrics of the printer-resident
font, and not the font of the same name that is installed on your hard drive.
Microsoft and Adobe have different algorithms for antialiasing. If I correctly
recall, Adobe's T1 renderer "fuzzes" out the edges of each glyph. This may
indeed increase the width in terms of pixels of the glyph. Microsoft's TrueType
rendering applies antialiasing in the y direction only - therefore it will not
increase the width (in terms of pixels) of each AA'd glyph. This does not mean
that fonts will not be scaled differently in Windows than they are in the
printer.
For TrueType fonts, the pixels that are turned on or off are dependent upon the
pixels per em (PPEM). Every glyph in a font is described in terms of an em,
which is usually a 2048 x 2048 grid. When the point size gets too small, or the
resolution of the output device (screen, printer) gets too small, there are not
enough pixels that fit within the em to accurately represent the shape of the
glyph. That is why TT and type 1 fonts have "hints" that a font renderer applies
to ensure that the resultant bitmap is legible. These "hints" may mean that a
font's width or height in pixels is adjusted. These hints are often arranged so
that AA is not necessary if the PPEM is great enough. After all, AA is a way to
reduce the effects of limited spatial resolution - in a 600 DPI Laser Jet, the
resolution is good enough and AA is usually not applied.
Sorry for the digression. Back to the original set of question - do J2D and
Swing use the same font renderer? If not, why? Sun would have to answer this
question.
Regards,
Steve
Ron Yust wrote:
> Steven,
>
> Are you saying then that you can't achieve WYSIWYG using AA font rendering?
> By your description then, if I use AA in a Word document for example, what I
> see on the screen is NOT what will be printed?
>
> How do program's like Adobe's Acrobat reader allow me to smooth fonts
> without extending their length? Again, why can Windows and Macintosh AA
> text without visual problems Swing experiences?
>
> And finally, why doesn't the Java2D team alter Java2's
> FontMetrics.stringWidth() method to allow for the expansion instead of
> requiring Swing to call a different method to determine the length?
>
> -Ron
>
> > -----Original Message-----
> > From: Steven C. Kapp [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 08, 1999 7:57 AM
> > To: Ron Yust; [EMAIL PROTECTED]
> > Cc: [EMAIL PROTECTED]
> > Subject: Re: [java2d] Anti-aliasing Swing text
> >
> >
> > Ron Yust wrote:
> >
> > > Phil,
> > >
> > > Can you answer just one question? Has the Java2D team talked
> > to the Swing
> > > team about this problem?
> > >
> > > It's amazing that as long as Swing and Java2D have been out
> > (even in beta)
> > > that no one has attempted to address this problem. I've seen Swing code
> > > that checks whether it is running a 1.2.x VM so I know they can
> > program for
> > > Java2 differences. I'll bet they are not even aware of what should be
> > > changed. Or they may feel it is a Java2D problem instead since
> > > Windows-based anti-aliased text looks fine with Swing. Maybe
> > it's Java2D's
> > > AA algorithm that erroneously extends the length of text. I
> > would expect an
> > > AA text string to be the same length as a non-AA string, but just more
> > > readable. This is how I see other AA rendering on my Windows NT and
> > > Macintosh machines!
> >
> > Rendering glyphs is more complicated than that. Depending upon
> > the antialiasing
> > implementation, and the complexity and point size of the glyph,
> > the glyph may
> > need to be slightly "stretched" in the horizontal (or vertical)
> > direction. This
> > stretching is necessary to ensure that the glyph is rendered into
> > enough pixels
> > that it is legible. For example, consider what happens to a
> > lowercase "m" as the
> > point size is decreased - a bounding box that encompases the
> > pixels of the glyph
> > will not scale linearly. If the bounding box did scale linearly,
> > the vertical
> > stems on the "m" would have no space between them at a small
> > enough point size.
> > Simply toggling AA on and off may not guarantee that the rendered
> > glyphs have
> > the same pixel dimensions.
> >
> > However, I'd certainly agree that Java base classes and Swing
> > should handle AA
> > in identical fashion.
> >
> >
> > > -Ron
> > >
> > > > Its not quite that simple, since getStringBounds() needs to
> > know the G2D
> > > > It is believed that Swing's metrics calculations are structured
> > > > in a way that
> > > > assumes the metrics are not affected by anything. This would probably
> > > > require significant changes in Swing, possibly with some
> > > > performance impact.
> > > > The Swing team will look into how they should handle this, but its not
> > > > going to make a release this year, so the recommendation is not
> > > > to use A-A text.
> > > >
> > > > -Phil.
> > >
> > > =====================================================================
> > > To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
> > > Java 2D Home Page: http://java.sun.com/products/java-media/2D/
> >
> > --
> > =========================================================================
> > Steven C. Kapp mailto:[EMAIL PROTECTED]
> >
> > Senior Member of Technical Staff
> > Questra Consulting http://www.questra.com
> > 300 Linden Oaks
> > Rochester, NY 14624 (716)381-0260,x276
> >
> > Personal - mailto:[EMAIL PROTECTED] http://home.eznet.net/~skapp/
> > =========================================================================
> >
> >
> >
--
=========================================================================
Steven C. Kapp mailto:[EMAIL PROTECTED]
Senior Member of Technical Staff
Questra Consulting http://www.questra.com
300 Linden Oaks
Rochester, NY 14624 (716)381-0260,x276
Personal - mailto:[EMAIL PROTECTED] http://home.eznet.net/~skapp/
=========================================================================
=====================================================================
To subscribe/unsubscribe, send mail to [EMAIL PROTECTED]
Java 2D Home Page: http://java.sun.com/products/java-media/2D/
