Hi behdad, On Thu, Aug 6, 2015 at 7:05 PM, Behdad Esfahbod <[email protected]> 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 > > [email protected] > > http://lists.freedesktop.org/mailman/listinfo/harfbuzz >
_______________________________________________ HarfBuzz mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/harfbuzz
