Re: More than Combining characters

[Jungshik Shin <jshin mailaps org>]

On Tue, 9 Sep 2003, Maung TunTunLwin wrote:

> > on rendering engines for script-specific 'intelligence'. For instance,
> > even if you have an opentype font for a script X, it'd be of no use unless
> > Pango (or Uniscribe on MS Windows) had no knowledge of the script X and

                        s/no knowledge/knowledge/

> > opentype layout features for the script X used in your font.

> available my script to many platform I have to Implement on Opentype Font.

  Mac OS X doesn't support opentype fonts, though. It only works with
AAT fonts at the moment. To me, Graphite is certainly more flexible than
opentype. With opentype, whenever a new script needs to be supported, you
need to write a new Pango module *in addition to* creating an opentype font.
With Graphite, once a generic Graphite support is written for Pango,
adding a new script can be simply  done by creating a new Graphite font.
You don't have to tell your users to upgrade their Pango to version x.y.z
or later.

> How Pango work with Opentype font, especially unknown script? Free Type 2

  It's just treated as a dumb truetype font (no glyph substitution,
no glyph positioning).  Without script(or language)-specific information
built-in, Pango (or Uniscribe) can't do much with opentype fonts.

> doesn't do rendering. Is that mean need to call cmap table and manual
> rendering or is there better way?

  That is one way. See how Thai shaper is written in Pango. Currently it
doesn't use opentype features. Instead, it maps a sequence of Unicode
characters to a sequence of regular and PUA Unicode characters where
PUA codepoints(U+F700) are used for 'presentation forms'. To use this
approach, all your glyphs have to be mapped. This works for Thai
because most Thai truetype fonts have presentation forms in the U+F700
block. In the long run, those fonts had better be converted to opentype
fonts if not already.

   Alternative is : You propose a spec. for your  script to MS/Adobe,
register a set of opentype features with them, implement a Pango module
and keep your finger crossed that MS also follows your suit and implements
them in Uniscribe.

  Judging from your address, I guess you're interested in Myanmar/Burmese
script.  Allegedly, MS has been working on it, but Uniscribe supporting
it won't be available very soon. Until MS is ready to ship their fonts
and Uniscribe, you're kinda stuck because they wouldn't release their
opentype spec for Myanmar/Burmese. [1]  If you don't care what Uniscribe
does, you can just go ahead with your own opentype spec. for Myanmar by
implementing it in Pango. However, that wouldn't work well because most
foundries are more likely to follow MS' spec than yours.

One way to work around is to map your 'presentation forms' to PUA code
points and write a Myanmar shaper that's similar to Thai shaper.
When the time comes, you can turn your 'truetype fonts' to opentype
fonts by adding GSUB/GPOS tables.


> But on my problem, it need more than that. Even if I have Opentype font, I
> still need feature like line wraping calculation and glyph repositioning,
> mean swapting with front or back. Can Pango do thing like that works.

  Script (or language in some case)-dependent reordering has to be done
by rendering/layout engines like Pango and Uniscribe if you use opentype
fonts. Glyph 'repositioning' has to be specified in opentype GPOS table
that, in turn, has to be taken advantage of by Pango and Uniscribe.
Pango layout APIs support line wrapping.

  Jungshik

[1] In case of Korean, they didn't release their spec until two years
after the first product supporting it had been released(in sometime in
2001?). It's possible that it's still unavailable if I had not
proposed an independent spec. for Korean in April.