Comparion of LogicalFontInstance::ImplGetGlyphBoundRect() between platforms
Chris Sherlock
chris.sherlock79 at gmail.com
Mon Nov 7 05:23:16 UTC 2022
On Sun, Oct 30, 2022 at 2:26 AM Chris Sherlock <chris.sherlock79 at gmail.com>
wrote:
>
>
> Sent from my iPhone
>
> On 23 Oct 2022, at 5:20 am, Caolán McNamara <caolanm at redhat.com> 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
>
A polite ping to the mailing list as people are now asking me for the
rationale behind the patch, could someone please advise the way forward?
Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20221107/6d10b388/attachment.htm>
More information about the LibreOffice
mailing list