[HarfBuzz] harfbuz uniscribe backend and firefox.

[Tom Hindle]

Hi behdad,

On Thu, Aug 6, 2015 at 7:05 PM, Behdad Esfahbod <behdad.esfahbod at gmail.com>
wrote:

> Hi Tom,
>
> On 15-08-07 01:15 AM, Tom Hindle wrote:
> > Hello,
> >
> > Recently I created a experimental patch for Firefox to allow use of
> harfbuz's
> > uniscribe backend, selectable via a about:config option.
> >
> > The patch can be seen here:
> > https://hg.mozilla.org/try/rev/08eef5e76a40
>
> I'm curious.  Why did you do this?
>

I will try and be as concise as I can :)

In general, our application used to use uniscribe (via IE) now it uses
halfbuzz (via Firefox), for the most part this is a very good thing,
however if users use fonts which may not be modified and they prefer how
uniscribe shaped these fonts, then having a optional uniscribe fallback
is a good, quick and safe solution.

The specific case is that harfbuzz + uniscribe behave differently for the
font "Noori Nastaliq MT" when handling GPOS Mark to Ligature attachments.
(I believe due to NULL entry in the LigatureAnchor table for class 0)
Although I couldn't determine if this was a bug in uniscribe or a bug in
Harfbuzz. (Plus I was informed that OT shaping implementation behavior
differences was just reality - which due to the complexity of some of the
tables didn't seem unsurprising.)

If I was allowed to share the font then, I would describe the problem
something like this:

hb-view Noori-Thorn-v20a2-sb3-pr1.ttf "دینا" --output-format=png
--output-file=uniscribe.png  --shaper=uniscribe
hb-view Noori-Thorn-v20a2-sb3-pr1.ttf "دینا" --output-format=png
--output-file=ot.png  --shaper=ot

Now even if, dispute not being able to file a proper bug report, this was
determined to be a halfbuz bug and was fixed, a uniscribe fallback option
would still be useful for:

1. Similar use cases where it's a uniscribe bug.
2. A quicker and lower risk solution while, either halfbuz gets updated in
firefox, and then the firefox version is updated in our app, or I build a
custom firefox, with a updated halfbuz.
(I could justify the lower risk if required - but trying to be concise)



>
> > In order to get it work I had to make a couple of changes to
> hb-uniscribe.cc
> >
> > This was because when Firefox code calls
> >
> > hb_font_set_scale(mHBFont, scale, scale);
> >
> > Its scale values are "16.16 fixed point" format (floats converted to int
> by
> > multiplying by 65536) and so it expects values returns by
> > hb_buffer_get_glyph_positions to be the same format.
>
> Yes, I had become aware of this, and that's why I stopped building the
> Win32
> binaries with uniscribe backend enabled, until I fix it.
>
>
> > I made hb-uniscribe.cc comply with this by scaling by ratio between
> > font->(x|y)_ppem and font->(x|y)_scale.
> >
> > Is this something hb-uniscribe.cc should already be doing or is the
> Firefox
> > code making unsafe assumptions?
>
> The uniscribe backend should do this indeed.  I did this in the CoreText
> backend.  Will check your code and fix it eventually.
>

Thank you appreciate the feedback!


>
> Thanks,
> behdad
>
> > The latest gfxHarfBuzzShaper.cpp source code can be seen here:
> >
> https://hg.mozilla.org/mozilla-central/file/03e3d77d1b6b/gfx/thebes/gfxHarfBuzzShaper.cpp
> >
> >
> >
> > Thanks
> > Tom
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > HarfBuzz mailing list
> > HarfBuzz at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/harfbuzz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/harfbuzz/attachments/20150806/6caf45f6/attachment.html>