[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tanween variants and Unicode
- To: General Arabization Discussion <general at arabeyes dot org>
- Subject: Re: Tanween variants and Unicode
- From: Meor Ridzuan Meor Yahaya <meor dot ridzuan at gmail dot com>
- Date: Mon, 29 Aug 2005 08:47:15 +0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O1jWjlPUOHswEASOhtA35gMzCmUWE3uIhjKdWWjcjgCGG0Nl0VSEd6iF+Z0oss5xxl+pmq8MXRnOrRlPAgQj4koSkWuiIK+gtaihEdcE55zq4yepqw0+34P8gxly2qRT8xArs4N8Wk/HLkuV+cRwESm2ciFNth1iI25ktjV15TE=
> > GPOS table with fontlab, and I think you will go crazy. Maybe Gregg
> > know better.
> I think in principle it should be possible to write specs for these
> tables in a higher level language, so that they can be shared among font
> developers. I found I was able to make some GSUB tables the way I
> wanted, but it turns out none of the OT engines out there supports the
> full logic of Open Type! For example, I wrote contextual tables to
> select the proper glyph for tanween, so e.g. <damma><tanween> would do
> the right thing. Worked just great inside of the Fontlab environment,
> but not in any of the editors I tried (notepad, word, some mac editors,
> etc.) Fontlab tech support told me that only a few Adobe products
> support contextual substitution in GSUB. :(
Well, I'm not sure this is true or not, but when I created the
contectual subtitution using VOLT for a similar case, it just works,
both under Windows and Linux. Notepad, Wordpad, Word, Gedit, etc... no
problem. I do had some other problems, but not typical CALT feature.
What I suspect is Fontlab's implementation of the GSUB table that have
problems. I've seen Fontlab under windows (Demo version) reading
arabic fonts, displaying some wierd GSUB table structure. I'm not sure
how the Mac version works. Maybe you can show me some of your work
and I'll try to find out what is the problem.
> So it looks like we really need to write an OT Service provider to work
> with Freetype. Anybody game? I've started looking at the Freetype
> code; it's very clean and well-organized, and they have a bunch of OT
> stuff that they're migrating out of FT, since it is outside of the scope
> of FT.
I don't think we need to create one, Pango and ICU is out there. We
just need to improve it to get it all right.