Re: Comparion of LogicalFontInstance::ImplGetGlyphBoundRect() between platforms

Date Prev

Date Next

Thread Prev

Thread Next

Date Index

Thread Index

Subject: Re: Comparion of LogicalFontInstance::ImplGetGlyphBoundRect() between platforms

From: Chris Sherlock <chris.sherlock79@xxxxxxxxx>

Date: Sun, 30 Oct 2022 02:26:22 +1100

Cc: Libreoffice Development Mailing List <libreoffice@xxxxxxxxxxxxxxxxxxxxx>

In-reply-to: <60f727a593fb48783a883f58aecaaecab8ba824c.camel@redhat.com>

References: <60f727a593fb48783a883f58aecaaecab8ba824c.camel@redhat.com>

Sent from my iPhone

On 23 Oct 2022, at 5:20 am, Caolán McNamara <caolanm@xxxxxxxxxx> wrote:

On Sat, 2022-10-22 at 01:42 +1100, Chris Sherlock wrote:
Test name: VclLogicalFontInstanceTest::testglyphboundrect
equality assertion failed
- Expected: 51x82@(7,-80)
- Actual : 51x83@(7,-80)

I’ve had another look at the code, with some help from Khaled. The
issue is the way in which we do our final rounding.

On Freetype, it uses 26.6 fixed point, and thus needs it’s own
special FreeType ceil and floor functions. CoreText appears to using
floating point, but the std::ceil and std::floor functions give
slight different results.

I presume that for mac its CoreTextStyle::ImplGetGlyphoundRect and the
CTFontGetBoundingRectsForGlyphs so could print the numbers we get there
vs the ones we get in FreeTypeFont::GetGlyphBoundRect to verify that.

I’ve added some debugging statements. the Freetype library does its own floor and ceil calculations. it’s looking like it isn’t a risky a rounding error, it is just that Freetype calculates one value and MacOS framework for glyphs calculates it differently.

Patch is https://gerrit.libreoffice.org/c/core/+/142006 if anyone would like to review :-)

Chris