[Devel] Semi-WYSIWYG and WYSIWIG Text layouts

[Keil Claudia]

Hello,

I'm  working with freetype 2.0, and I'm testing text processing described in
"Freetype Glyph-Conventions".
The freetype library is compiled with TT_CONFIG_OPTION_BYTECODE_INTERPRETER.
In the example below I used the font file arial.ttf with 12 pt and a
resolution of 96 dpi with FT_LOAD_DEFAULT.


Semi-WYSIWYG text layout:

I tested sub-pixel positioning when rendering text (described in "Freetype
Glyph-Conventions" as Semi-WYSIWYG  text layout).
But the advance in fractional pixel (FT_GlyphSlotRec.metrics.horiAdvance)
returned by freetype is always rounded.

On the one hand freetype rounds the value (respective loader->pp2.x -
loader->pp1.x) , 
on the other hand the value is overwritten by the advance of the hdmx table
(if there is one) , which is rounded also.
I am not sure whether this is intended, because there is no difference
between pixel and sub-pixel postioning.

WYSIWYG text layout:

In addition, I tested,  positioning with the linear scaled advance when
rendering text 
(described in "Freetype Glyph-Conventions" as way for WYSIWYG  text layout).
This works fine, but I have some problems with the linear scaled advance of
composite glyphs 
(among other glyphs german umlauts "äöüÄÖÜ").

As I described in my other mail "linear scaled advances of german umlauts"
the linear scaled advances are much too small.
I took a look in the freetype code to find out whether this is a problem of
freetype or the truetype file.

The FT_GlyphSlotRec.linearHoriAdvance is based on  loader->advance  which is
set by the function load_truetype_glyph (),
 after calling the function GetHMetrics ().
When I loaded the composite char 'ä' which has glyph index 108, the function
Get_HMetrics () is called for 
glyph index 108 and the two sub glyph indezes 68 and 142.
For glyph index 108 and 68 the returned advance is 1139 funits for glyph
index 142 the advance is 682 funits.
(The 1139 funits seems to be the correct one, because char 'a' has the same
advance in funits, and the text is ok with this advance).
The value returned for glyph index 142 (= 682) is used for
FT_GlyphSlotRec.linearHoriAdvance.
It seems to me, that unlike this,  the advance in fractional pixel
(FT_GlyphSlotRec.metrics.horiAdvance) which is based on 
loader->pp2.x - loader->pp1.x , is deliberately saved, to avoid overwriting
by the value of the subglyphs.


Thanks for any help

regards 

Claudia