[HarfBuzz] Question about HarfBuzz-ng CTL Shaper Status

[Ed]

Thanks, Keith, for your very informative email!

I myself am quite tempted to just use a bunch of ligatures for glyph
reordering -- at least in this first round of the implementation.  It
seems easy enough, and I can get very precise positioning of the
reference glyphs through a visual interface in FontForge.

Also, although I have been trying to figure out context-specific
substitutions, I have yet to actually get anything that works.  While
in principle it makes sense, in practice it is a bit of a mystery to
me.

One other approach to glyph reordering that I have found does work is
kerning.  But this only works when the reordering is limited to
swapping the position of a single pair of glyphs.  If you give the
first glyph a large delta-x and the second glyph an equivalently large
negative delta-x, then they appear swapped.  But I am a bit hesitant
to use this approach ; using a ligature seems a bit safer.  What I
really should do is check what differences there are in file size when
using ligatures (composed only of references to other existing glyphs)
vs. the swap-by-kerning approach.  Of course swap-by-kerning doesn't
work in all cases, but may still be a valid option for the subset of
cases where only pairs of glyphs need to be swapped.

Best - Ed

On Tue, Sep 21, 2010 at 8:04 AM, Keith Stribley <devel at thanlwinsoft.org> wrote:
> On 21/09/10 13:21, Kenichi Handa wrote:
>>
>> For certain combinations, such as Tai Tham's "Medial R" which needs to
>>>
>>> precede the base consonant, using ccmp substitutions will work.  This
>>> requires creating a lot of "ligature" glyphs.  But it works.
>>>
>>
>> I think it's far from:
>>   a "pure" version of the font that uses only proper OpenType features
>>
>
> It may not be "pure" but it may be pragmatic. If you want a font to work on
> Windows and Linux today, then taking advantage of the default GPOS and GSUB
> features which are already enabled is a reasonable approach. The Myanmar
> 5.1/5.2 Unicode fonts that exist take advantage of features such as clig,
> liga, kern and in one case mark/mkmk to give correct rendering under
> Uniscribe and in some cases Harfbuzz-NG and Pango without having a specific
> shaper.
>
> There are 2 ways to get reordering working without a script specific shaper.
> Ligatures is probably faster, but requires a lot of glyphs, which will
> probably need to be autogenerated. The other approach is using multiple
> context specific substitutions to perform the insertion and then remove the
> unwanted glyphs from their original position. The later requires a lot of
> lookups and may need guard glyphs to be inserted temporarily between
> syllables to prevent reordered glyphs matching unordered patterns.
>
> I think it is a shame that Firefox 4 is not enabling Harfbuzz-NG for complex
> scripts, at least for those which don't have a specific platform shaper.
>  Uniscribe on Vista and Win 7 should support default features for these
> scripts, but many computers still run Win XP and don't have Complex Script
> support specifically enabled since it is off by default. Perhaps harfbuzz
> could be enabled at least if the web developer actively uses the CSS3
> font-feature-settings or font-language-override. This might help encourage
> people to move away from quasi-Unicode fonts for these scripts, to fonts
> which properly conform to the standard.
>
>> The right approach will be:
>>
>> (1) Write a specification document something like what
>> Microsoft does for various scripts:
>>     <http://www.microsoft.com/typography/SpecificationsOverview.mspx>
>> This should be a base of Tai Tham font&  layout-engine
>> developpers, and for that, it may be good that this document
>> is officially approved by a proper Tai Tham authority
>> (perhaps by the one who proposed Tai Tham script to Unicode
>> or ISO10646).
>>
>> (2) Implement a Tai Tham layout engine as a pango module or
>> a harfbuzz-ng's shaper according to (1).
>>
>
> With some scripts it is possible that there is still insufficient
> information available to write a reliable shaper that will work with every
> language using the script. In the case of Myanmar, a shaper was written for
> the original harfbuzz for one interpretation of the ambiguous Unicode 4
> specification for Myanmar. However, that was never updated for Unicode 5.1
> which removed the ambiguities and actively prevents correct rendering of
> fonts which would work with the default shaper. Fortunately Pango doesn't
> use that shaper, though other apps do.
>
> In the interim, I would suggest that if (1) and (2) are implemented for a
> script without a current shaper on all platforms, that it actively checks
> whether the font has been written for that shaper e.g. by checking for the
> presence of non-default features, which would only be present in a font
> specifically targeting that shaper. If those features are not present, then
> it should just use the default features. There is also the danger that even
> if (1) is written there is no guarantee that other rendering engines will
> implement it in the same way, but I admit it will give a faster rendering
> solution for the long term.
>
> By the way, for OpenType font testing I use grsvg with its python GTK user
> interface. You can build it from
> http://scripts.sil.org/svn/graphite/grutils/trunk on Linux. Use CMake for
> the build and install the ICU and harfbuzz-ng libraries first. It will allow
> you to compare the output of the 2 renderers and if graphite / graphiteng is
> available it will also show the graphite rendering. It is using SVGs as an
> intermediate format underneath (not SVG fonts), so it won't show hinting,
> but is alright for testing OT/Gr rendering.
>
> Best regards,
>
> Keith Stribley
>
>
>
> _______________________________________________
> HarfBuzz mailing list
> HarfBuzz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>