Re: [NTG-context] [Dev-luatex] State of OpenType support
(Moved from lautex mailing list, more bellow) On Thu, May 08, 2008 at 02:11:38PM +0300, Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:53:56PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:22:16PM +0200, Hans Hagen wrote:
On Thu, May 08, 2008 at 10:10:23AM +0200, Taco Hoekwater wrote:
Hans Hagen wrote: > Khaled Hosny wrote: > >> I also tried "Nafees Nastaliq" font >> http://www.crulp.org/software/localization/Fonts/nafeesNastaleeq.html >> with also broken result. >> >>> See also the arabic chapter (XIII) in mk.pdf: >>> >>> http://pragma-ade.com/general/manuals/mk.pdf >> I was actually testing the fonts under its guidance :) > Can you two team up on this issue? the problem is that esp the > scripting part of OT is not really defined, only has de facto > specs i.e. reversed engineered uniscribe. I had a quick look at the font with fontforge. It could that (part of the) problems are related to the fact that most of the glyph encodings in the font do not follow unicode, even though the font claims to be a UnicodeBMP encoded font. It is quite possible that that confuses the contextual analyser in MkIV. I'm relaying solely on OpenType here, i.e. the actual glyphs aren't encoded and using isol, init, etc features to map characters to the appropriate glyphs.
I tested it with two other OpenType implementations, and I got the expected result.
Khaled Hosny wrote: this mkmk feature ...
(1) is it directionally sensitive? some features are marked as r2l, some not
No its not, I think r2l is applicable for cursive anchors and should mean nothing here (I was trying some thing but forget to remove it after). I removed r2l marl from all tables (except curs), but this changed nothing.
(2) do you use proper mark -> basemark? or just mark to mark?
keep in mind that when you update your font, you have to remove the cached version
I removed the enteries in fonts/otf of the cache dir, is this enough?
Uploaded Pango output of the same string for comparison, http://khaled.djihed.com/context/ (Note: the dots are marks, not part of the base glyph; the dot is basemark and the haraka is mark). Thanks, Khaled
Khaled
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
-- Khaled Hosny Arabic localizer and member of Arabeyes.org team
-- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
(Moved from lautex mailing list, more bellow)
char 1614 and 1617 are to be relatively positioned using mkmk, so we need a mark and a basemark match an donly anchor-11 qualifies as basemark but ... { ["anchors"]={ ["basemark"]={["Anchor-11"]={["x"]=0,["y"]=250,},}, ["mark"]={["Anchor-13"]={["x"]=0,["y"]=-100,},["Anchor-7" ]={["x"]=0,["y"]=0,},}, }, ["name"]="shadda", ["unicode"]=1617, }, { ["anchors"]={ ["mark"]={["Anchor-13"]={["x"]=0,["y"]=-100,},["Anchor-7"]={["x"]=0,["y"]=0,},}, }, ["name"]="fatha", ["unicode"]=1614, }, there is no mark reference in 1614 ... i'm not that fluent in fontforge so i cannot play further
On Thu, May 08, 2008 at 02:11:38PM +0300, Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:53:56PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:22:16PM +0200, Hans Hagen wrote:
On Thu, May 08, 2008 at 10:10:23AM +0200, Taco Hoekwater wrote: > Hans Hagen wrote: >> Khaled Hosny wrote: >> >>> I also tried "Nafees Nastaliq" font >>> http://www.crulp.org/software/localization/Fonts/nafeesNastaleeq.html >>> with also broken result. >>> >>>> See also the arabic chapter (XIII) in mk.pdf: >>>> >>>> http://pragma-ade.com/general/manuals/mk.pdf >>> I was actually testing the fonts under its guidance :) >> Can you two team up on this issue? the problem is that esp the >> scripting part of OT is not really defined, only has de facto >> specs i.e. reversed engineered uniscribe. > I had a quick look at the font with fontforge. It could that > (part of the) problems are related to the fact that most of the > glyph encodings > in the font do not follow unicode, even though the font claims to be a > UnicodeBMP encoded font. It is quite possible that that confuses the > contextual analyser in MkIV. I'm relaying solely on OpenType here, i.e. the actual glyphs aren't encoded and using isol, init, etc features to map characters to the appropriate glyphs.
I tested it with two other OpenType implementations, and I got the expected result.
Khaled Hosny wrote: this mkmk feature ...
(1) is it directionally sensitive? some features are marked as r2l, some not No its not, I think r2l is applicable for cursive anchors and should mean nothing here (I was trying some thing but forget to remove it after). I removed r2l marl from all tables (except curs), but this changed nothing.
(2) do you use proper mark -> basemark? or just mark to mark? keep in mind that when you update your font, you have to remove the cached version I removed the enteries in fonts/otf of the cache dir, is this enough?
Uploaded Pango output of the same string for comparison, http://khaled.djihed.com/context/ (Note: the dots are marks, not part of the base glyph; the dot is basemark and the haraka is mark).
Thanks, Khaled
Khaled
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
-- ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Thu, May 08, 2008 at 08:02:10PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
(Moved from lautex mailing list, more bellow)
char 1614 and 1617 are to be relatively positioned using mkmk, so we need a mark and a basemark match an donly anchor-11 qualifies as basemark but ...
Actually, 1617 (shadda) and 1615 (fatha) will form a shadda-fatha ligature, thus there is no proper mkmk anchors between both. But, for example, 1615 (damma) has the appropriate anchor.
{ ["anchors"]={ ["basemark"]={["Anchor-11"]={["x"]=0,["y"]=250,},}, ["mark"]={["Anchor-13"]={["x"]=0,["y"]=-100,},["Anchor-7" ]={["x"]=0,["y"]=0,},}, }, ["name"]="shadda", ["unicode"]=1617, },
{ ["anchors"]={
["mark"]={["Anchor-13"]={["x"]=0,["y"]=-100,},["Anchor-7"]={["x"]=0,["y"]=0,},}, }, ["name"]="fatha", ["unicode"]=1614, },
there is no mark reference in 1614 ...
i'm not that fluent in fontforge so i cannot play further
On Thu, May 08, 2008 at 02:11:38PM +0300, Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:53:56PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
On Thu, May 08, 2008 at 12:22:16PM +0200, Hans Hagen wrote:
Khaled Hosny wrote: > On Thu, May 08, 2008 at 10:10:23AM +0200, Taco Hoekwater wrote: >> Hans Hagen wrote: >>> Khaled Hosny wrote: >>> >>>> I also tried "Nafees Nastaliq" font >>>> http://www.crulp.org/software/localization/Fonts/nafeesNastaleeq.html >>>> with also broken result. >>>> >>>>> See also the arabic chapter (XIII) in mk.pdf: >>>>> >>>>> http://pragma-ade.com/general/manuals/mk.pdf >>>> I was actually testing the fonts under its guidance :) >>> Can you two team up on this issue? the problem is that >>> esp the scripting part of OT is not really defined, only >>> has de facto specs i.e. reversed engineered uniscribe. >> I had a quick look at the font with fontforge. It could >> that (part of the) problems are related to the fact that >> most of the glyph encodings >> in the font do not follow unicode, even though the font claims to be a >> UnicodeBMP encoded font. It is quite possible that that confuses the >> contextual analyser in MkIV. > I'm relaying solely on OpenType here, i.e. the actual glyphs aren't > encoded and using isol, init, etc features to map characters to the > appropriate glyphs. > > I tested it with two other OpenType implementations, and I got the > expected result. this mkmk feature ...
(1) is it directionally sensitive? some features are marked as r2l, some not No its not, I think r2l is applicable for cursive anchors and should mean nothing here (I was trying some thing but forget to remove it after). I removed r2l marl from all tables (except curs), but this changed nothing.
(2) do you use proper mark -> basemark? or just mark to mark? keep in mind that when you update your font, you have to remove the cached version I removed the enteries in fonts/otf of the cache dir, is this enough?
Uploaded Pango output of the same string for comparison, http://khaled.djihed.com/context/ (Note: the dots are marks, not part of the base glyph; the dot is basemark and the haraka is mark).
Thanks, Khaled
Khaled
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl ----------------------------------------------------------------- -- Khaled Hosny Arabic localizer and member of Arabeyes.org team
--
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
-- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
On Thu, May 08, 2008 at 08:02:10PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
(Moved from lautex mailing list, more bellow)
char 1614 and 1617 are to be relatively positioned using mkmk, so we need a mark and a basemark match an donly anchor-11 qualifies as basemark but ...
Actually, 1617 (shadda) and 1615 (fatha) will form a shadda-fatha ligature, thus there is no proper mkmk anchors between both.
hm, they won't because 1615 becomes an initial and therefore an other character also, i wonder if this is ok: ["char"]="shaddaKasra", ["components"]="shadda fatha", ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Fri, May 09, 2008 at 06:34:22PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
On Thu, May 08, 2008 at 08:02:10PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
(Moved from lautex mailing list, more bellow)
char 1614 and 1617 are to be relatively positioned using mkmk, so we need a mark and a basemark match an donly anchor-11 qualifies as basemark but ...
Actually, 1617 (shadda) and 1615 (fatha) will form a shadda-fatha ligature, thus there is no proper mkmk anchors between both.
hm, they won't because 1615 becomes an initial and therefore an other character
I'm not sure if I understand this, do marks have initial and other forms?
also, i wonder if this is ok:
["char"]="shaddaKasra", ["components"]="shadda fatha",
The ligature is OK, just the name is wrong (I named it wrongly while asleep or something).
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
-- Khaled Hosny Arabic localizer and member of Arabeyes.org team
Khaled Hosny wrote:
On Fri, May 09, 2008 at 06:34:22PM +0200, Hans Hagen wrote:
Khaled Hosny wrote:
Khaled Hosny wrote:
(Moved from lautex mailing list, more bellow)
char 1614 and 1617 are to be relatively positioned using mkmk, so we need a mark and a basemark match an donly anchor-11 qualifies as basemark but ... Actually, 1617 (shadda) and 1615 (fatha) will form a shadda-fatha
On Thu, May 08, 2008 at 08:02:10PM +0200, Hans Hagen wrote: ligature, thus there is no proper mkmk anchors between both. hm, they won't because 1615 becomes an initial and therefore an other character
I'm not sure if I understand this, do marks have initial and other forms?
also, i wonder if this is ok:
["char"]="shaddaKasra", ["components"]="shadda fatha",
The ligature is OK, just the name is wrong (I named it wrongly while asleep or something).
no, but we have \char 1605\char1617\char1614 which becomes: \char57392\char1617\char1614\par so, if you want such a ligature you need to ligature \char57392\char1617 ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
participants (2)
-
Hans Hagen -
Khaled Hosny