bugThe FreeType Project - Bugs: bug #52683, erratic results for glyph advances...

 
 

bug #52683: erratic results for glyph advances when using variation fonts

Submitted by:  Jonathan Kew <jfkthame>
Submitted on:  Sun 17 Dec 2017 04:17:40 AM UTC  
 
Severity: 3 - NormalItem Group: Incorrect behaviour
Status: FixedPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: 2.8.2

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Mon 18 Dec 2017 08:42:32 AM UTC, comment #5:

I've missed the case for unhinted fonts, now fixed – in case you are preparing some tests I suggest that you cater for this situation also :-)

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Mon 18 Dec 2017 08:37:10 AM UTC, comment #4:

Looks much better, thanks! Results now look sensible with both the HVAR and non-HVAR fonts.

Jonathan Kew <jfkthame>
Mon 18 Dec 2017 06:33:50 AM UTC, comment #3:

Thanks a lot for your detailed analysis and demo program! I've applied your patches, and I've additionally fixed the remaining issues (I hope :-).

Please test!

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Sun 17 Dec 2017 08:53:09 AM UTC, comment #2:

Looking at the variations code, I think there's some confusion in the indexing of phantom points in TT_Vary_Apply_Glyph_Deltas. See attached patch for ttgxvar.c for details.

However, fixing this (if it is indeed an error, and not just my misunderstanding) does not appear to help the testcases described here.

(file #42666)

Jonathan Kew <jfkthame>
Sun 17 Dec 2017 04:28:44 AM UTC, comment #1:

The attached patch seems to help with one aspect of this: the wildly-incorrect results from FT_Get_Advance when using LOAD_NO_SCALE, seen with the Gingham font and on the first call after setting variation coordinates with AvenirNext.

This does not fix the issue of failing to account for the variation, or double-applying the adjustments (depending on presence of 'HVAR', apparently).

(file #42665)

Jonathan Kew <jfkthame>
Sun 17 Dec 2017 04:17:40 AM UTC, original submission:

I'm seeing results that don't seem to make sense in some cases when applying variation coordinates to fonts.

See attached testcase ft-var-test.cpp, compiled with a command such as

As test fonts, I've used a couple of examples from the Axis-Praxis site:

Some sample runs of the test program, with the output they report:

These results are OK, I believe. However, if I run it with the -n flag (to use LOAD_NO_SCALE and get results in font units when loading glyphs), I get:

Two things appear wrong here. First, when the variation coordinates have been set, the results from FT_Get_Advance are wildly wrong (looks like an incorrect scaling has happened at some level). And second, neither the horiAdvance field in the GlyphSlotRec's metrics nor the "shorthand" advance field in the slot properly reflects the variation settings, although the linearAdvance field does.

Now let's try the AvenirNext-Variable font. A key difference between this font and Gingham is that it contains an 'HVAR' table, whereas Gingham does not. Again, we'll run with FT_LOAD_DEFAULT first:

Again, I believe the values returned in the GlyphSlotRec's linearAdvance field are correct. But both the FT_Get_Glyph_Advance values and the metrics advance fields are significantly larger than expected; it looks as though the change resulting from the variation coordinates has been doubly applied to these.

And now with LOAD_NO_SCALE:

This time the metrics look correct, except that the first result returned by FT_Get_Advance after setting the variation coordinates is wildly out (similar to what we saw with Gingham); but the subsequent results of this function are OK, including the second time it is called for the 't' glyph.

The inconsistencies here make it tricky to know what fields can be trusted to return useful glyph advances when variations are in effect, and the answer seems to differ depending on the presence/absence of an 'HVAR' table.

Jonathan Kew <jfkthame>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #42666:  ttgxvar.c.patch added by jfkthame (1KiB - application/octet-stream - proposed patch for ttgxvar.c to fix apparent phantom point index errors)
file #42665:  ftadvanc.c.patch added by jfkthame (1KiB - application/octet-stream - possible patch that addresses part (but NOT all) of the issues discussed)
file #42664:  ft-var-test.cpp added by jfkthame (4KiB - application/octet-stream - test program referred to in the report)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by wl (Posted a comment)
  • -unavailable- added by jfkthame (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 7 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 18 Dec 2017 06:33:50 AM UTCwlStatusNone=>Fixed
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed
      Planned ReleaseNone=>2.8.2
    Sun 17 Dec 2017 08:53:09 AM UTCjfkthameAttached File-=>Added ttgxvar.c.patch, #42666
    Sun 17 Dec 2017 04:28:44 AM UTCjfkthameAttached File-=>Added ftadvanc.c.patch, #42665
    Sun 17 Dec 2017 04:17:40 AM UTCjfkthameAttached File-=>Added ft-var-test.cpp, #42664

    Back to the top


    Powered by Savane 3.1-cleanup1