a question about fonts

Joachim Durchholz joachim.durchholz at munich.netsurf.de
Fri Apr 23 18:31:04 UTC 1999


"Norton, Chris" wrote:
> 
> *  There are two types of rasterizing - easy and hard
> *  Easy rasterizing algorithms take the Outline font coordinates and
> create Bitmap fonts out if them, but they do not make use of the
> auxiliary information (often described as "hints").
> *  The more complicated rasterizing algorithms use all available
> information from the Outline font definition to make the most
> "pretty", scaleable font it can.  This process takes longer, so the
> rendered font is generally cached (like in the StrikeFont cache).

There's a third one: Use the easy algorithm, but compute how much of
each border pixel is covered by the outline and make the pixel
transparent to the corresponding degree.
This has already been mentioned as "anti-aliased" font rendering. The
transparency information is often called "alpha channel" (in analogy to
the the RGB channels).
Small fonts tend to look somewhat fuzzy at a short distane with this
one, but the overall effect is quite good.

> (I'm still wondering what "kerning", "ligatures" and "splines"
> are, although I can guess at their meanings from the context)

Kerning is the process of moving adjacent characters closer or farther
away from each other. TeX tries to distribute the black areas evenly
across a line by using kerning; there may be other criteria that could
be optimized via kerning. Customarily kerning information is precomputed
(sometimes even by the font designer) and transmitted as a
twodimensional table that specifies the distance between each pair of
character (a solution that I don't like because it doesn't handle
changes between fonts on a line).

Ligatures are combined characters. For example, fi is commonly made into
a ligature (the i loses its dot, which is represented by the end of the
top hook of the f).

Splines are a simple way to define a rounded line. The parameters of a
spline are its endpoints, and the direction that the line is going off
at each point. The coordinates of each intermediate point can be deduced
via quadratic equations. There's only one way to make a spline for each
set of endpoints-plus-directions parameter sets.
It is mathematically easy to have two splines that smoothly connect
(just let them have one endpoint-plus-direction in common), as well as
making sharp corners (just let the direction differ but not the
endpoint), so they are ideally suited to describe the curved lines that
make up the outline of a character.

> Question:  Since OS's apparently come with built in rasterizing
> software, couldn't a primitive call be added to Squeak to accomplish
> the more difficult rasterizing tasks?  If an Outline font could be
> converted into a Bitmap font, by passing it with size parameters to
> the OS rasterizing routines, then the generated Bitmap font could be
> converted (if needed) and cached in the StrikeFont cache.  [Note:  I
> still know nothing about primitives, so this may be a dumb question]

It should be possible to use this algorithm to convert outline fonts to
bitmap fonts. I *know* it's possible (even easy) to do that under
Windows; it requires some fiddling with GDI calls, but that's about all.

The downside is that you cannot rely on the fonts being rendered in the
same way on every platform. The effects can be truly horrific: If you
have, say, a DTP program in Smalltalk, lines will end at different pixel
positions depending on the OS rasterizer used. IOW if you have a text on
a Unix box, it may or may not have the same line breaks on a Windoze
box.

OTOH it may be a good idea to just use the primitive and build a good
rasterizer later when there's a DTP program in Smalltalk.

> Observation 2:  Several people have told me that the full rasterizing
> algorithms are also very complex and challenging to write.  The
> general consensus is:  "don't go there".

I'm not familiar enough to confirm or deny that.

> This may be true, but I have found hints on the web
> (http://w3c1.inria.fr/Fonts/#type1) that there are specs and free
> implementations available that maybe could be ported to Squeak
> (apparently a low quality rasterizer is available in Ghostscript,
> and rasterizing source is distributed with X).

Well, the Ghostscript rasterizer used to be bad, so it's probably better
to just stick with the easy rastering method. However, I think I read
something that this rasterizer was improved; besides, I definitely read
that the main problem was that Ghostscript came with fonts that had no
hints to the rasterizer quality were irrelevant anyway. So it might be
worth checking.
I can't comment on the X rasterizer.

Regards,
Joachim
-- 
Please don't send unsolicited ads.





More information about the Squeak-dev mailing list