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 <spepp...@leverkruid.eu>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
>

Reply via email to