Re: [Freetype] Some newbie questions

[David Turner]

Hello,

Nitzan Shaked a écrit :
> 
> Hello David, all:
> 
> Two follow-ups, with your permission:
> 
> 1) To "dramitically reduce memory consumption", I'm guessing that I would
> have to write a font loader module which will NOT store any dynamic data,
> but rather re-parse everything whenever it is needed. Thus, the size of a
> "Face" object can be almost 0, and all the dynamic data I would need is the
> cache and the raster pool. I don't even have to have a bitmap object,
> because I can use the span-callback to draw directly to the buffer. So
> basically, what's involved here is reducing the size of a face object to as
> close as zero as possible.
>
Yes, the idea is to avoid creating too many things in the heap when the font
data is already available from memory (i.e. from ROM or a memory-mapped file).

This means however that you need to re-parse the file content's whenever you
need it, instead of storing a more convenient version for your own use in
the heap..

As an example, I'm currently doing some re-engineering of the FT2 internals
in the HEAD CVS branch. One of the latest changes is direct-access to the
TrueType character maps as found on the file, instead of loading them
through specific structures of the heap (compare src/sfnt/ttcmap.c and
src/sfnt/ttcmap0.c to see what I mean)

This approach can be extended to _many_ parts of a font driver. There are
however many reasons to require dynamic memory:

  - if you enable the bytecode interpreter, you'll need some memory
    to perform CVT scaling and glyph bytecode interpretation (most
    importantly, the runtime bytecode stack can add up to 8Kb for
    certain fonts, and this is not negociatable)

  - any other kind of hinting requires memory whose size

  - the scan-line converters also need memory to work correctly

The good news is that these memory areas are never used concurrently
and can be shared within the same memory block. I also suppose that it
would fit 20Kb. The bad news is that this would require quite a
few non-trivial changes to the font engine and will _not_ guarantee
very high performance..

Glyph hinting/rasterizing is indeed a complex thing and requires a
certain amount of horsepower. If you're not using a cache to store
rendered bitmaps, you'll save on memory but lose in rendering performance.


In short, FreeType 2 isn't currently suitable for your environment. It
can be modified to suit it but you won't get stellar rendering performance.

> 2) According to my understanding, the linear metrics are NOT sampled to the
> pixel grid, as opposed to the hinted metrics. Are they transformed, though?
> And also, if they're not hinted, then they might be incorrect! Then hinter
> may ENLARGE the actualy metrics! Otherwise, I'm sorry to say I don't
> understand the point.
>
The hinter may enlarge or srhink the metrics. You should use the hinted
metrics when performing device-specific glyph positioning.

The linear metrics are used to perform device-independent glyph
positioning (for example in WYSIWYG text layouts, think about
Word processors or PDF readers, etc..). They're critical to
compute line-breaks that are independent of the current display
or print resolution, for example..

You never actually use them directly to position glyphs, unless
you've disabled hinting..


Hope this helps,


- David Turner