-
Bug
-
Resolution: Not an Issue
-
P3
-
None
-
1.3.0
-
x86
-
solaris_2.5
customer's email:
In my opinion the bug with printing and the bug with zooming is the same.
I deduce this from the fact that Java2D uses the same approach to scale
graphics from user space to device space, as we use to provide zooming
functionality: the java.awt.geom.AffineTransform (look at "Programmer's
Guide to the Java 2D(TM) API" ftp://java.sun.com/docs/j2se1.3/j2d-book.pdf
chapter "2.2.6 Transformations" on page 23 or at the API description of
class Graphics2D:
http://java.sun.com/products/jdk/1.2/docs/api/java/awt/Graphics2D.html):
zoom(AffineTransform) AffineTransform
graphic object ---------------------> User Space
----------------------> device space 1 Printer (600dpi)
|
---------------------->device space 2 Screen(72dpi)
|
---------------------->device space 3 Printer(300dpi)
The first AffineTransform is done by our zooming mechanism, the second one
is done in Java2D automatically. This second transformation depends on the
resolution of the device space.
The "given-step" case only works if all Fonts which were drawn in the
transformed Graphics2D Object have the same size. The acceptable
transform-steps, which mean the steps where the Font-Glyphs are scaled in
a similar manner as other graphic objects (lines, polygons....) are
determined by the resolution of the device space and 150 dpi is nearly the
resolution of a screen device. So the result is acceptable with 150 dpi
printer resolution in respect of scaling of text and graphics. With regard
to overall printing quality 150 dpi is of course not acceptable.
To show this I implemented the attached example Print.java. Please try
this example and print with different printer resolutions. You'll see,
that command line output which is made in Printer.RenderPanel.print() is
different for different print resolutions. Furthermore you have the
printer output with text scaling different for different resolutions (see
the attached ps-files produced with AdobePS Acrobat Distiller 3.0 with
300 dpi and 144 dpi chosen in the printerdialog).
Files are attached in the attachments section.
In my opinion the bug with printing and the bug with zooming is the same.
I deduce this from the fact that Java2D uses the same approach to scale
graphics from user space to device space, as we use to provide zooming
functionality: the java.awt.geom.AffineTransform (look at "Programmer's
Guide to the Java 2D(TM) API" ftp://java.sun.com/docs/j2se1.3/j2d-book.pdf
chapter "2.2.6 Transformations" on page 23 or at the API description of
class Graphics2D:
http://java.sun.com/products/jdk/1.2/docs/api/java/awt/Graphics2D.html):
zoom(AffineTransform) AffineTransform
graphic object ---------------------> User Space
----------------------> device space 1 Printer (600dpi)
|
---------------------->device space 2 Screen(72dpi)
|
---------------------->device space 3 Printer(300dpi)
The first AffineTransform is done by our zooming mechanism, the second one
is done in Java2D automatically. This second transformation depends on the
resolution of the device space.
The "given-step" case only works if all Fonts which were drawn in the
transformed Graphics2D Object have the same size. The acceptable
transform-steps, which mean the steps where the Font-Glyphs are scaled in
a similar manner as other graphic objects (lines, polygons....) are
determined by the resolution of the device space and 150 dpi is nearly the
resolution of a screen device. So the result is acceptable with 150 dpi
printer resolution in respect of scaling of text and graphics. With regard
to overall printing quality 150 dpi is of course not acceptable.
To show this I implemented the attached example Print.java. Please try
this example and print with different printer resolutions. You'll see,
that command line output which is made in Printer.RenderPanel.print() is
different for different print resolutions. Furthermore you have the
printer output with text scaling different for different resolutions (see
the attached ps-files produced with AdobePS Acrobat Distiller 3.0 with
300 dpi and 144 dpi chosen in the printerdialog).
Files are attached in the attachments section.
- relates to
-
JDK-4311203 deriveFont does not use floats, it uses int values
- Closed