bugThe FreeType Project - Bugs: bug #56321, Autohinting breaks after...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #56321: Autohinting breaks after a113e5df0c src/truetype/ttgload.c (TT_Process_Simple_Glyph): Minor.

Submitter:  Dominik Röttsches <drott>
Submitted:  Tue 14 May 2019 01:06:25 PM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Works For Me Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.1

Jump to the original submission

Fri 17 May 2019 07:17:10 AM UTC, comment #6: 

At least I wasn't aware of the consequences of such slight changes.  Thanks for the explanations on freetype-devel!  We will try to find a modus operandi that should help avoid complications as much as possible in the future.

Werner LEMBERG <wl>
Group administrator
Fri 17 May 2019 06:42:08 AM UTC, comment #5: 

This is slightly off-topic on this bug. But since you're commenting about the broader issue, I'll reply here as well:

I am not saying pixel rendering of FreeType needs to always stay the same, however in the case of the optimizations I've been bringing up on the mailing list, I don't quite understand the justification. Pixel differences and new baselines cause work in all embedding projects. See also https://bugs.chromium.org/p/pdfium/issues/detail?id=1295#c4 for how this roll is causing trouble in PDFium and hits test failures there.

From my perspective it's okay to change pixel values if the pros and cons have been weighed and if it improves correctness or performance. But if the aim is performance, then I would prefer to see benchmarks which indicate that such improvements are measurable.

For Chrome, Skia and PDFium pixel comparison testing, we cannot relax the thresholds, Ben has separately explained why in https://bugs.chromium.org/p/chromium/issues/detail?id=962932#c4

Dominik Röttsches <drott>
Wed 15 May 2019 06:05:09 PM UTC, comment #4: 

Also, please afford us some "pixel differences" as long as they are invisible. Human eye cannot detect 1/256 difference in brightness, so we will explore this wiggle room for speed-ups and optimizations.

Bit-to-bit consistency is unnecessary. We even use slightly different rendering algorithms on 32- and 64-bit platforms. May I suggest that you relax your tests to permit deviations < 4?

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 15 May 2019 06:26:44 AM UTC, comment #3: 

It was suboptimal (to say it with nice words :-) to include the revert in a larger patch.  Sorry for that.  Normally I try to commit stuff in the smallest possible chunks, but I failed this time.

Closing.

Werner LEMBERG <wl>
Group administrator
Tue 14 May 2019 02:21:19 PM UTC, comment #2: 

This was with Tinos, which we're using for Linux layout tests:
https://fonts.google.com/specimen/Tinos

Okay, I missed the revert - since in my bisecting I was stopping before the 1178227b39a4eeecbefad226d4a753b345a16eb1 commit (variable fonts internal precision increase). (I had trouble identifying several separate issues, I will explain in a post to the mailing list.)

Then this may already be fixed.




Dominik Röttsches <drott>
Tue 14 May 2019 02:15:44 PM UTC, comment #1: 

Well, I've already reverted a113e5df0c in commit 94ebc248...

I don't see your issue with my test fonts.  Which font is this?  Can you reproduce it with one of the FreeType demo programs?

Werner LEMBERG <wl>
Group administrator
Tue 14 May 2019 01:06:25 PM UTC, original submission:  

Hi Werner,

I am trying to roll FreeType in Chrome and I am facing various issues with pixel differences in layout tests. There are two more issues that I will bring up on the mailing list, however, this one seems to be rather clear-cut.

In a checkout in which I have reverted

  • 7a81b63abc2b3da0d7f0950f69377d2b3f54b0fb Bezier optimisations
  • 39ee52b7f19c2f3136b54aa9444f53109e17d48f Bezier flattening

since they cause other pixel failures, I see that after

a113e5df0c it seems that autohinting starts failing and I get inferior glyph rendering.

I suggest we revert this change or find a better spot for the call to zone_prepare.

Thanks,

Dominik

Dominik Röttsches <drott>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attached Files
file #46904:  font-size-adjust-expected.png added by drott (14KiB - image/png - Illustration of auto hinting doing weird things - probably due to incorrect zone identifications)
file #46905:  font-size-adjust-actual.png added by drott (13KiB - image/png - Illustration of auto hinting doing weird things - probably due to incorrect zone identifications)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by podtelez (Posted a comment)
  • -email is unavailable- added by wl (Posted a comment)
  • -email is unavailable- added by drott (Submitted the item)
  • -email is unavailable- added by drott
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

     

    Follow 8 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-15 wl StatusNeed Info Works For Me
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.1
    2019-05-14 wl StatusNone Need Info
        Assigned toNone wl
    2019-05-14 drott Attached File- Added font-size-adjust-expected.png, #46904
        Attached File- Added font-size-adjust-actual.png, #46905
    2019-05-14 drott Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-caa5.
    Corresponding source code