bugThe FreeType Project - Bugs: bug #40820, Advances incorrect with b0962ac34...

 
 

bug #40820: Advances incorrect with b0962ac34 and rotation.

Submitted by:  bungeman <bungeman>
Submitted on:  Thu 05 Dec 2013 09:57:17 PM UTC  
 
Severity: 3 - NormalItem Group: None
Status: InvalidPrivacy: Public
Assigned to: Werner LEMBERG <wl>Open/Closed: Closed
Planned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

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

 

Fri 06 Dec 2013 08:35:33 PM UTC, comment #2:

OK, closing.

Werner LEMBERG <wl>
Project AdministratorIn charge of this item.
Fri 06 Dec 2013 07:36:33 PM UTC, comment #1:

I attempted to reproduce with ftstring form the ftdemo project. However, the issue is not reproduced. It appears that the reason for this is that ftstring is using FT_Glyph_Transform to transform the glyphs on demand where Skia is using FT_Set_Transform. It does not appear that any of the demos are using FT_Set_Transform for anything other than forcing identity.

However, I was able to modify the code for ftstring so that it uses FT_Set_Transform instead of FT_Glyph_Transform. Interesting this also did not cause the issue to reproduce.

Upon further inspection I have determined that this is a bug in Skia. It appears that Skia has had this bug for a very long time and it is surprising that no one has noticed before.

Feel free to close this bug as invalid.

bungeman <bungeman>
Thu 05 Dec 2013 09:57:17 PM UTC, original submission:

The reproduction case I currently have is to build FreeType and Skia, and run Skia's SampleApp like

LD_LIBRARY_PATH=$HOME/src/freetype2/objs/.libs/ out/Debug/SampleApp --slide GM:blurs

and then hit the 'r' key to get things rotating. I believe that this depends on the font being used having the 'snap to pixel height' bit (it appears most do). The result is that as the text rotates the advances jiggle quite a bit depending on the angle. This does not happen with the system FreeType.

This jiggling isn't often seen in the wild since most distros appear to be patching out b0962ac34. If one does not patch out b0962ac34, linear metrics like FT_Face->glyph->linearHoriAdvance, which should in theory remain the same no matter the rotation, vary quite a bit and somewhat awkwardly.

The issue appears to be that when snapping to integer heights, metrics->x_scale is modified, but this is also the only interesting variable in the calculation of linearHoriAdvance. I have confirmed that commenting out just the assignment of metrics->x_scale in tt_size_reset makes the linearHoriAdvance stop jumping about. This obviously isn't a real fix, but does narrow down where the effect is coming from.

Note that this also affects regular non-linear advances as well as they also jiggle about as the text rotates. After some cursory examination of the code I'm unsure as to why the rotation is making a difference here.

bungeman <bungeman>

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

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 bungeman (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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 06 Dec 2013 08:35:33 PM UTCwlStatusNone=>Invalid
      Assigned toNone=>wl
      Open/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup1