![]() |
One further problem caused by subsampling is that certain information is
irreversibly lost in the graylevel representation. For example, if you have a
graylevel pixel of intensity 50% (whatever the real color is), then, in case
of antialiasing, you will know that in the
input bitmap
two pixels had been set to foreground, but you would not know which two
these had been. But this information is important for concatenating and
blitting of antialiased bitmaps: it may well happen that two pixels with 50%
gray that lie over each other had to produce an output pixel of 50%, 75%
or 100% gray (where 100% gray means full foreground intensity).
To avoid these problems, t1lib generally does not cache antialiased
glyphs. Instead, it works on true bitmaps which are then subsampled at the
last possible stage to an antialiased glyph. Applications that do not use
anything more than the functions that yield char bitmaps or bytemaps, could
profit from caching of antialiased characters. Such applications could specify
T1_AA_CACHING
as an additional ingredient to the log
argument of
the function T1_InitLib()
which initializes t1lib. This is done by
OR'ing the value of log
with T1_AA_CACHING
as described in
. If this flag had been specified at initialization time,
T1_AASetChar()
will cache the bytemaps it has generated and will take
them from cache in future requests.
When caching antialiased glyphs, each size gets up to four distinct cache
areas, one for bitmaps and one for ,
and
subsampled
bytemaps each. As soon as a string-generating function is called these cached
antialiased glyphs cannot be used for the reasons discussed before. The
developer of an application should thus carefully think about whether
a possibly marginal performance gain is really worth this much higher
effort. If in doubt, simply check it out. Applications like
xdvi
which
place isolated character glyphs on a sheet could use this feature, however, and
profit from it.