Steven,

Thanks for the information, but when I want to know the time I don't really
want to know how to build a clock. :)

Still, from your feedback AA text without expansion should have been
possible for Java2D and Swing (like Microsoft TT).  If Java2D was going to
alter text length, the Swing team should have been prepared a long time ago.

-Ron

> -----Original Message-----
> From: Steven C. Kapp [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, June 08, 1999 1:53 PM
> To: [EMAIL PROTECTED]
> Cc: Ron Yust
> Subject: Re: [java2d] Anti-aliasing Swing text
>
>
> 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/

Reply via email to