Re: FT2 design question

[Stefan Seefeld]

David Turner wrote:

> Just to clarify things, a "raster" in FT2 is the module handling 
> scan-conversion of
> a given glyph image to a pixmap (either monochrome or anti-aliased).

(ok, I'd thought of that as a rasterizer.)

> The auto-hinter works on outlines exclusively, so I'll rather call its results
> "hinted outlines" for clarification.

ok.

> The process of auto-hinting is designed to make text more legible by 
> respecting
> a few simple rules (that are more or less hard to implement :-) like :

[...]

> As you can see, these rules can be applied to rotated outlines as well, with 
> the
> exception of the blue zones. However, I don't think it'd be a good idea, nor 
> that
> it will give good results. Fact is that, for example, the advance width and 
> left
> side bearing of glyphs are modified by the hinting process. A rotated outline 
> will
> surely be hinted differently from its un-rotated version, which will mean 
> different
> metrics.

Yes, I understand.

> Now, do the following :
> 
>   a/ render auto-hinted text on a single horizontal baseline into a series of
>      vector outlines. Then rotate the whole outlines before scan-converting
>      them..
> 
>   b/ render auto-hinted rotated text on a single rotated baseline, i.e. render
>      each rotated glyph separately
> 
> There are great chances to see _very_ different results because the 
> auto-hinting
> will be so different..

Couldn't you try to set up a little doc or even put it into a FAQ to illustrate
how to get text transformation right ? I'm by no means an expert in glyph and 
font
processing (not to speak about text processing). However, I design the berlin 
architecture
and there we don't usually deal with device coordinates. Each node in the scene 
graph
basically knows about it's local coordinate system (like in openGL). Sure, you 
*can*
access the transformation to the device space given a particular DrawingKit 
(the device,
renderer pair). However, I'd prefer to formulate things in a coordinate 
independant manner.
For this to work, I'd like to be able to simply feed in a character (or string) 
and a
transformation matrix into the rasterizer and get a pixmap which is ready to be 
mapped
to the video memory.

> To be clear, there will not be a text-rendering API available with FreeType 2 
> when
> it is first released (I mean, something that can convert "Office" into the 
> glyphs
> for "O", "f", "fi", "ce" or "O", "ffi", "c", "e" depending on the font's 
> content).
> 
> The main reason is that there are too many ways to provide this, and we want 
> to
> stick purely to font services for the high-level interface.

ok. I can live with not having ligatures for the next few months :) Whether this
functionality will be available through FreeType itself or through an extension 
library
doesn't really matter for my own work, I simply want to find out what the 
correct way
is to access this information. I imagine some API where I feed in a sequence of 
characters
and I get back a sequence of glyphs. That should be basically all. The tricky 
part (for
text processing) is that this mapping is font (and therefor DrawingKit) 
dependant. Not
all DrawingKits provide the same fonts. However, the logic in the scene graph 
which must
provide the semantics of character editing, cursor positioning etc. can't 
depend on the
glyph mappings. To complicate things even further, the actual size of the 
glyphs depend
on the DrawingKit as well, so how can we abstract from that if doing the layout 
of the
text ? We currently try to use a 'canonical DrawingKit' which is the one you 
use for
screen rendering. When you pass a different DrawingKit (for printing for 
example) the
text composition must then look up the new sizes and try to compensate metric 
differences
by inserting glues at appropriate places.

Does anyone know of papers or other texts written about this kind of problem ?

Best regards,   Stefan
_______________________________________________________              
              
Stefan Seefeld
Departement de Physique
Universite de Montreal
email: address@hidden

_______________________________________________________

      ...ich hab' noch einen Koffer in Berlin...