Re: [AGG] Re: text rendering

[Pierre A. <pie...@op...>]

Ivan Nincic wrote:
> The design of a cache for vector fonts requires some balancing between
> two opposing forces: memory vs. CPU.
> 
> Caching bitmaps with subpixel X positioning is prohibitative in terms of
> memory use (see Foley, van Dam, Computer Graphics, Section 19.4 The
> Special problems of text). The cache will not work for rotated text.
> Bitmap caching is probably not the right way to go...

From my experiments, I have found that caching anti-aliased glyphs
with, say, 0.25 resolution on the [x] axis is a good compromise between
rendering quality, speed and memory consumption.

> Caching outlines is good for memory, but bad for CPU because the
> rasterizer needs to perform expensive anti-aliased scan conversion for
> each glyph over and over again. Converting curved glyph to polygon helps
> a bit, but one could run into problems because the polygon approximation
> for the glyph can be either too fine or too coarse.

In my implementation, I am never caching the outlines, since it does
not cost much to produce them on the fly based on the True Type tables.
You may object that keeping the font in memory is already a form of
primitive outline cache :-) but in my case, Windows does it for me.

And of course, I don't use the cache for anything but plain non rotated
glyphs; my purpose it to speed up the "standard" text rendering where
tons of glyphs are painted sequentially.

> A compromise between these two approaches (memory/CPU extremes) is to
> use scanline-shape data structure (already implemented in AGG for
> scanline boolean algebra :)  ) to rasterize glyphs at high resolution
> (large point size). Note that the glyph is rasterized using efficient
> monochrome/binary rasterizer (i.e. no need for anti-aliasing). The
> resulting Shape is called master character and is stored in the cache.

Hmmm. Interesting. If you use a sufficiently large master character (I
prefer the term "glyph" to describe the shape of these objects described
by fonts), then indeed, there is no need to store anything else than the
0 or 1 coverage information. RLE will work fine horizontally, but not
vertically, or will it ?

> All this is described in Foley, van Dam, Computer Graphics, Section 19.4
> "The Special problems of text". The original paper on this topic was
> published in SIGGRAPH 87, pg. 233-242, Naiman and Fournier, "Rectangular
> Convolution for Fast Filtering of characters"

Any idea if this paper is on-line somewhere ?

Kind regards.

    Pierre