Re: [Devel] freetype layout -- Where?

[David Turner]

Hello Tobias,

> 
> >   - provides "styles" [...]
> >
> >     (For a better idea, have a look at ATSUI, i.e. Apple Text
> >      Layout Engine)
> 
> Any URLs about ATSUI?
>
  http://developer.apple.com/techpubs/macos8/TextIntlSvcs/ATSUI/atsui.html

  or try Google.. :o)

 
> I don't think we will need styles at this level of our API-stack:-)
>

Well, well, well.. I knew that talking about "styles" without describing
them in more details would create some confusion. I'm currently preparing
a paper on the design/requirements of FT Layout to elucidate this question.

Anyway, my idea is that proper display of internationalized text
requires as much abstraction as possible of the "font" concept, mainly
because there is no way that a single "font" could support all scripts,
languages and features we're interested in. and asking the developer to
"switch fonts" when _he_ thinks is appropriate is calling for disaster..

Scripts are a good way to group "attributes" together, and may also
provide a surprisingly simple solution to this problem, without
introducing "virtual fonts" and other atrocities.

I won't develop this for the moment though, sorry..

 
> >   - we'll most probably start using UCI as the back-end for
> >     most layout operations [...]
> 
> URL for UCI? (or do you mean ICU?). Will you write FTlayout in C++? That
> way you propably won't need most of your support library;-)
>
It's ICU actually, sorry :-)

I don't intend to write it in C++, but I'm still interested to know what
developers on this list think about it..

Even in C++, we will need a specific support library since we want
quite a number of features not provided by the STL (e.g. cleanup-stack
based exception handling, pluggable malloc/free, etc..)
 
> We won't need the unicode layout functionality (at least not the
> bidir-part), we just need a way to get to the font-data (GSUB, GPOS and
> maybe some other tables iirc) and use that.
> 
> >   - the text layout library will depend on external providers
> >     for things like font installation lists, font metadata [...]
> 
> Pango has this implemented quite well afaik. Actually I like the
> architecture of pango very much.
>
Allow me to disagree with this. Again, this will be developed in an
incoming paper. It's not that Pango is bad (it _really_ isn't), but it
simply isn't appropriate for our requirements..


> >   - no rendering support [...]
> 
> I don't get this. Rendering should be possible through some backends
> like freetype and maybe others. How does underlining come in here,
> expecially in a no-rendering context?
>
Ahh.. I wanted to say that:

  - FT Layout shouldn't depend on any explicit graphics sub-system
    or rendering model. Ideally, it should only provide layout
    information to client applications (i.e. glyph codes + metrics
    + a few attributes ).

  - Rendering should be supported through specific back-ends. These
    would need to implement things like underlining themselves, but
    we'll most probably provide some routines to do that more or less
    automatically..


> > PS: I suggest you to look at UCI for Berlin, since it's written
> >     in C++ and works pretty well right now..
> 
> UCI? I know ICU (IBMs Components for Unicode). We started our own
> unicode library because of some sticky licensing issues (which are now
> resolved, ICU is under X-license). We might give up our own lib now.
> But that does not solve our Fonthandling issues: We need something like
> the virtual fonts pango has, we need to combine several unicode chars
> into one glyph (ligature support), we need to do what pango calls glyph
> shaping (arranging unicode characters to form a single glyph), we need
> exact sizes for those glyphs and we might need to transform those glyphs
> (replace a char by it's mirrored equivalent provided by the font, we
> could do that by replacing chars in the string by their mirrored
> equivalent, but I'd like to do that at this level if possible) and
> finally render the result.
> 
> We don't need fancy unicode layout (Bidir and stuff), that happens
> somewhere else, we don't need support for styles (just a way to switch
> between diffrent fonts), we don't need any fancy string handling, ...
>

"just a way to switch between different fonts" won't bring you very far
if you need to support advanced international and typographic features
in my opinion.

there is no reason that FT Layout, nor even ICU Layout, couldn't support
what you're describing (ATSUI already supports all of these, by the way).

Regards,

- David