[4840] in java-interest
re: Printing
daemon@ATHENA.MIT.EDU (Thomas Hickey)
Tue Jan 16 16:36:00 1996
From: hickey@oclc.org (Thomas Hickey)
Date: Tue, 16 Jan 1996 10:46:11 -0500
To: java-interest@java.sun.com
Cc: Amy.Fowler@Eng.Sun.COM, jshermer@BASISinc.com, scottj@aip.org,
eng40260@leonis.nus.sg, pdurusau@emory.edu,
babyak@fssun09.dev.oclc.org
Several people have asked for more information on how OCLC is handling
non-standard fonts. Here is a summary, along with a response from Sun
to the initial posting:
Problem: We need to display journal articles, many with mathematics,
that require a large (and growing) number of different symbols (glyphs).
We do this within Java by completely bypassing the standard fonts. We
encode each font as TIFF-encapsulated Group 4 compressed file along
with a small header that describes some font-level characteristics such
as maximum width and baseline offset. The glyphs in the fonts are
stored (compressed) at 300 dpi, and then scaled (using gray-levels for
anti-aliasing) to the proper scaling. Normal scaling is 3:1, for 100
dpi, but other levels are supported for zooming in and out. We
generate the 300 dpi images from TrueType fonts we are using for a
proprietary client, and use standard TeX TFM files to supply width
information.
The scaling occurs during the decompression, using software we have
ported to Java. The resulting bitmaps are turned into little images
for display, and cached for subsequent use. By shifting the images
during scaling we can position the resulting glyph to within a 1/3 of
pixel at 100 dpi, greatly simplifying text placement.
The system works reliably and well. If we were reimplementing our MS
Windows client we would probably adopt the same technology.
The primary problem we have (other than printing) is speed. The fonts
have to be downloaded (a 12pt font is about 6K bytes) which can take
time, the initial decompression time for each glyph is noticeable, and
the actual display of the cached images is not as fast as standard text
display. Under ideal conditions, however, the system nears acceptable
speed already, and we expect that promised speed improvements will be
enough. Space does not seem to be a major problem (we only decompress
and cache characters as they are encountered in the text).
In case you missed Sun's response to the printing question here it is:
>We are currently working on enabling printing for AWT,
>but I'm sorry to say it will not be in 1.0.
>Regards,
>Amy Moore-Fowler
>Java Products Group
>Sun Microsystems, Inc.
By this, I'm assuming they hope to include it in the next release,
rumored to be this summer. This would be soon enough for us, assuming
a beta version becomes available before that.
--Th
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
