[HarfBuzz] A few HarfBuzz-ng questions

[Keith Stribley]

On 11/18/2010 05:51 AM, Khaled Hosny wrote:
> On Wed, Nov 17, 2010 at 05:25:05PM -0500, Ed wrote:
>> 2. SHAPERS: In void hb_shape(...) in hb-shape.cc, I see this:
>>
>>        #if 0&&  defined(HAVE_GRAPHITE)
>>        ...
>>        #endif
>>
>> OK, please correct me if I am wrong, but looking here and at other
>> files (i.e., hb-graphite.cc),  it looks to me like Martin Hosken has
>> provided a way to tie Graphite into HarfBuzz and that "hb_shape()"
>> will eventually be the wrapper function that switches between either a
>> Graphite shaper or the HarfBuzz OpenType shaper.  And for the time
>> being somebody has just commented out processing with Graphite via the
>> "#if 0" statement.
> The code with commented out because of recent changes to the API that
> graphite code weren't ported to, yet.

Yes, there is also a graphiteng in development which has significant 
performance improvements over the old graphite library, so I think 
Martin's intention is to wait for the graphiteng api to stabilize and 
then integrate that.
>
>
>> Also, as I understand it, it is now common for font developers to test
>> their fonts on multiple platforms and to provide not only OpenType but
>> also AAT-specific features in their fonts.  Danh Hong's work on the
>> Khmer fonts comes to mind.  Wouldn't it be nice if a font developer
>> could have a simple program based on HarfBuzz that would allow a font
>> developer to easily and quickly test font rendering using different
>> backends?  This would be especially useful for the complex text layout
>> scripts of India, South East Asia, etc.  It would also be useful for
>> Harfbuzz script module developers.  For example, I might want to take
>> an SIL Graphite-based Burmese font which I know will render correctly
>> using Graphite, and use it while actually writing the HarfBuzz shaper
>> code for Burmese ...
> If I understand correctly, you are considering fonts that would have
> Graphite, OpenType and AAT in the same font file? IMHO that would really
> be a bad idea, each should be in its own font file so the user can
> easily select what complex layout technology to use by selecting the
> appropriate font, I don't see what is the benefit of amalgamating all in
> one font file and I can see possible issues that it would cause.

Most Graphite fonts that I know also have OpenType rules and one or two 
may also even have AAT rules. (Padauk, the Burmese font mentioned above, 
has Graphite and OT rules, but the Graphite rules are faster). In most 
(all?) cases the Graphite rules give equivalent or slightly better 
rendering than the OT rules, so for normal users prefering Graphite with 
such a font makes sense. The main reason for having multiple complex 
layout technologies in the same file is that most fonts are installed as 
system fonts and not all applications support the same rendering 
engines. Graphite rules may be added to give slightly better rendering 
or more feature options, the OT rules are used as a fallback to give 
readable rendering in applications only supporting OT.

In my experience very few non-technical users want to chose the complex 
layout technology (they probably don't even know the names of such 
technologies). However, there is a case for font developers and 
programmers who are including multiple technologies in their fonts to be 
able to compare the results side by side. One way to get hb_shape() to 
support this might be to use a fake feature which was used to force the 
use of a particular renderer, however, an optional, explicit renderer 
parameter might be better.  I created a tool called grsvg which now 
allows ICU, HB and Gr rendering to be compared next to each other, but 
currently it calls the renderers directly rather than with hb_shape. 
Unfortunately I can't compare old-hb and Harfbuzz-ng side by side with 
the same binary because of symbol name clashes.

Regards,
Keith