On Tue, Sep 20, 2011 at 04:46:40PM -0400, Behdad Esfahbod wrote: > On 09/20/11 14:32, Khaled Hosny wrote: > > I just noticed that feature ranges assume byte not character count, e.g. > > to apply a feature for first 10 Arabic characters I've to pass > > [:20] not [:10], I can live with that but it wasn't obvious at first. > > Right. They are indices into the UTF-8 text. I can provide a mode to count > characters. I agree that it would be easier that way. Maybe it should be the > default?
That would make more sense, I can't even think if use case where counting by bytes would be preferred over characters. > I'll also add a markup mode so you can add the features directly in > the text. Finally, I'll add support for escaped Unicode characters ala > '\u06cc\u0641...'. Nice :) > > And it arrived just in time :) I was about to try writing something like > > that to facilitate writing unit testing for my complex Arabic fonts. > > Thanks very much! > > Cool. I'm very interested in your unit tests! Just a file of plain text with > one test per line would do. I ended up using a csv file so I can specify options to pass to hb-shape (I want to test optional and script/language sensitive features etc.) and a python script to parse the file, run hb-shape and compare the results (if anyone interested, check [1]) > >> There are options to disable outputing the cluster value or the positions, > >> or > >> use glyph indices instead of glyph names. > > > > It seems that --no-positions suppresses outputting clusters as well. > > Fixed. Thanks. [1] http://amiri.git.sourceforge.net/git/gitweb.cgi?p=amiri/amiri;a=commitdiff;h=2c56128948f7180e8714c533193b0cda70483266 Regards, Khaled -- Khaled Hosny Egyptian Arab _______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
