Re: [NTG-context] [Dev-luatex] State of OpenType support
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
signature.asc
Description: Digital signature
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
Re: [NTG-context] [Dev-luatex] State of OpenType support
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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [Dev-luatex] State of OpenType support
Khaled Hosny wrote: 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). 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 - ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [Dev-luatex] State of OpenType support
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 signature.asc Description: Digital signature ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://tex.aanhet.net archive : https://foundry.supelec.fr/projects/contextrev/ wiki : http://contextgarden.net ___
Re: [NTG-context] [Dev-luatex] State of OpenType support
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:
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
-
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://tex.aanhet.net
archive : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___
