Re: [Fwd: [Fwd: FT2 design question]]

[Werner LEMBERG]

> > sequence of normalized unicode characters
> > 
> > "wysiwyg is difficult"
> > 
> > breaks into sequence of minimally nonconflicting chunks
> > 
> > w:y:s:i:w:y:g: :i:s: :d:i:ffi:c:u:l:t

But exactly this is the problem!  If you don't use the `ffi' ligature
character of Unicode (which should be avoided in general) it is
font-dependent whether you will get `ffi' or `ff'`i' or `f'`f'`i'.  In
Arabic, it might be possible that, say, `dta' is replaced with a
single ligature, and other fonts output `d'`t'`a' which needs three
times more space or even more, compared to the single ligature -- so
stretching and squeezing on a glyph by glyph basis (as you've
suggested) won't work.

The outlined algorithm works fine IMHO for a 1:1 model
(character:glyph ratio); it will even work (but worse) for, say,
1:0.8-1:1.2, but it will fail for smaller and larger ratios.

A possible solution is that the features of the font (say, the GSUB
and GPOS data) are analyzed by a tool during installation of the font,
but I doubt whether that is (a) possible in general and (b) a good
design decision.

Another possible solution is not to work on a glyph by glyph basis but
rather comparing glyph strings: Send the character string to the
drawing kit, which returns the total length l_dk of all glyphs for a
particular font.  Then send the same character string to the rendering
engine of the graph scene, using the display device's font, and you
will get another total length l_gs of all glyphs.  Using the ratio
l_dk/l_gs it is now possible to adjust the display device's font to
the drawing kit's font.

But I doubt that the results are still WYSIWYG (at least for
Arabic)...


    Werner