Thanks for trying out. Keep in mind the following: - the resulting output is completely font sensitive, if a font lacks the appropriate tables, or those tables are inaccurate, then it will be reflected in the output; - newer versions of some of fonts have more complete and accurate tables; e.g., the newer SimplifiedArabic 5.0 font from Win7 has more and better data than the earlier versions from WinXP; - probably most relevant here is some temporary code I used, in which I wired in some specific properties of the SimplifiedArabic font, namely, which glyphs are non-spacing mark glyphs, that is normally obtained from a third table, called the GDEF table; in fact, i have been implementing the GDEF table yesterday, and expect to finish shortly, after which I will push to github; that will generalize the process of determining which glyphs (not characters) in a font represent base glyphs, ligatures, and marks, and which is needed to correctly process the IgnoreBase, IgnoreLigatures, and IgnoreMarks lookup flags in GSUB/GPOS processing;
Could you send me the FreeSerif font or provide a link to the one you used that produced the exception? Regards, Glenn On Tue, Sep 14, 2010 at 2:48 AM, Simon Pepping <[email protected]>wrote: > Thanks for this explanation. I tried it with the code from your git > branch, with mixed results. Simplified Arabic is a Windows font, so I > had to get it from there. My output with this font is not as nicely > positioned as yours. I also tried other fonts on my machine with the > first arabic block (Mark to Base, first line). With some fonts I had a > nice result. With other fonts I got each of the four characters on a > separate line, with no diacritical marks. With one font, FreeSerif, I > got an exception: > > java.lang.UnsupportedOperationException: unsupported device table > delta format: 0 > > I can send you the generated pdf file if you wish. > > Is saving space in the if file important enough to devise a compressed > notation? You could also simply list the tuples in the attribute > value, e.g. dp="{ 0, 0, 0, 0 } { 5600, 1952, -6432, 0 } { 0, 0, 0, 0 } > { 608, -9664, -6400, 0 } { 0, 0, 0, 0 }", which would make > understanding of the code to interpret it easier. > > Regards, Simon > > On Sun, Sep 12, 2010 at 11:42:37AM +0800, Glenn Adams wrote: > > For those following the work on complex script support, attached is a > sample > > showing a combination of GSUB (glyph substitution) and GPOS (glyph > position) > > table functions operating on Arabic text as produced by FOP 1.0 with > complex > > script features enabled: > > > > -- > Simon Pepping > home page: http://www.leverkruid.eu >
