freetype
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Freetype] The text layout pipeline


From: Antoine Leca
Subject: Re: [Freetype] The text layout pipeline
Date: Wed, 27 Oct 2004 13:27:22 +0200

On Wednesday, October 27, 2004 10:12 AM, Paul Pedriana va escriure:

Interesting work. I will try to improve it.


>    2. Divide the paragraph into runs of same script
>       and direction.
>        * This step is only necessary if there is
>          complex script in the paragraph.

Assuming the usual definitions where Arabic and Nagari are complex scripts
and Latin and Cyrillic are not, why are you saying that?

If the underlying text is in Latin, I do not see exactly what is the
interest to make a distinction between Cyrillic and Nagari here: either you
want to record the change of script, or you do not.

Of course RTL characters, or more exactly a mix of LTR (including digits)
and RTL characters, will force the division, and the use of the (in)famous
bidi algorithm(s).


>    3. Split each of the above runs into runs of
>       same font style.
>    4. Do shaping of text.

Somewhere between 3. and 4. you need to make the mapping from character code
to glyphs ids.
Also, upon your 4. shaping there is also a step usually called positionning,
where the relative position of the glyphs, and sometimes the advance, can be
changed. It may include baseline adjusts between runs/script_changes, too.

>        * This means making a new version of the
>          paragraph text which has the actual
>          characters used in display of the text.

I would say it has glyphs ids instead. I do not believe it is useful to
require them to be "actual characters", because you might end with very
strange "characters", for example some Indic fonts use various glyphs to
built a single character/cluster, some of these glyphs may be "the last
third part of Kannada jha", for example.


>        * It will be useful or necessary to provide
>          a way to map items from this string back
>          to the original string.

There are two separate things here:
 - you might want a way to retrieve the (group of) character given a glyph
(useful to map a mouse click to some character in the buffer)
 - you might want to keep some character-derived properties along with the
glyph (useful to attach a vowel sign to a ligature).

But I am not sure the full explicit mapping is the solution. Particularly
since the combination rules might be very complex (so will cost to maintain
along with the operations).
Also see below.


>        * Use font info to decide if you can merge
>          characters (e.g. à instead of a + `) or
<skip>
>        * This step is only necessary if there is
>          complex script in the paragraph.

So anything except perhaps Braille qualifies as complex here...
You are not gaining much if you want to skip that step while dealing with
arbitrary decomposed sequences.


>    5. Do line breaking.
>    6. Apply justification.

Some high level protocols for line breakings (hyphenation) or justification
may brequire you to get back at shaping again (and again and again). Here
you may need the famous informations for the mapping I spoke above, by the
way.


Antoine







reply via email to

[Prev in Thread] Current Thread [Next in Thread]