bugThe FreeType Project - Bugs: bug #54371, Do varfont interpolation in floats

 
 

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

bug #54371: Do varfont interpolation in floats

Submitter:  Behdad Esfahbod <behdad>
Submitted:  Wed 25 Jul 2018 04:20:01 AM UTC
   
 
Severity:  3 - Normal Item Group:  None
Status:  Fixed Privacy:  Public
Assigned to:  wl Open/Closed:  Closed
Planned Release:  2.10.1

Jump to the original submission

Mon 13 May 2019 08:56:50 AM UTC, comment #15: 

Thanks Werner, I've retested this (with your help re disabling hinting by pressing 'h') in ftmulti with the internal repro font and I can confirm this is working, I see much increased interpolation precision. Thanks for the fix. We will roll FreeType into Chromium.

Dominik Röttsches <drott>
Sat 11 May 2019 08:03:49 AM UTC, comment #14: 

I've fixed this now in git (using a different approach), please test.

Werner LEMBERG <wl>
Group administrator
Wed 24 Apr 2019 02:47:06 PM UTC, comment #13: 

Can you try the attached untested patch?

(file #46824)

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 24 Apr 2019 01:48:39 PM UTC, comment #12: 

My point is that hairline is not an arbitrary concept. Microsoft used to render with 8 levels of gray, i.e. any thickness below 1/8 of a pixel is the same. Therefore any feature (thickness) variations below 1/8 of a pixel is invisible, useless, and possibly mistaken.

Back to font units, at (retina) normal size of 100 ppem, 1 funit in your example is 1/10 of a pixel. This is hardly visible.

Anyway, I see a lot of explicit comments that deltas are applied to unscaled instance. To me, it seems that scaling the "apply" value should work just fine too.


Alexei Podtelezhnikov <podtelez>
Group Member
Wed 24 Apr 2019 01:08:46 PM UTC, comment #11: 


> I very much doubt that you can see 1 funit thickness difference at the normal sizes where 1 funit is a small fraction of a pixel. Of course, you are talking about huge sizes (and a poorly designed variable font).


Wouldn't it be possible that a 1 funit shift in one contour point changes curvature towards the next point through which such a rounding effect is amplified?

I was referring to a use case brought forward to the Chrome team by renowned type foundry Underware. Respectfully, if you were implying that Underware produces poorly designed variable fonts, I invite you to familiarize yourself with their groundbreaking and innovative work.

To me it seems it has been established in this issue that hairline stem thickness is an actual use case for variable fonts, further examples perhaps here: https://djr.com/notes/output-sans-hairlines-font-of-the-month/

> The correct solution to the problem is "first scale than interpolate" as opposed to "first interpolate than scale". I will see if this is easy to implement.


Thank you for looking into it! That might be an alternative way to keep a higher interpolation precision.

Dominik Röttsches <drott>
Wed 24 Apr 2019 12:55:32 PM UTC, comment #10: 

I very much doubt that you can see 1 funit thickness difference at the normal sizes where 1 funit is a small fraction of a pixel. Of course, you are talking about huge sizes (and a poorly designed variable font).

The correct solution to the problem is "first scale than interpolate" as opposed to "first interpolate than scale". I will see if this is easy to implement.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 24 Apr 2019 08:35:12 AM UTC, comment #9: 

An additional use case we have received from underware, paraphrasing what they have said:

Say you have a weight axis with values from 1-1000, and a em box of 1000, for simplicity.

If in a variable font, at one position in the glyph contour, the glyph stem thickness is 1 funit for axis position 0-500, 2 and 2 funits for weight axis position 501-1000.

For rendering a specific instance statically, this precision may be sufficient.

However, particularly when animating axis values, a full funit "jump" from 1 to 2 becomes visible as a jump or discontinuity in an animated axis transition - smooth animations are not possible when variable output precision rounds to full font units.

Dominik Röttsches <drott>
Thu 01 Nov 2018 06:03:05 PM UTC, comment #8: 

On modern high-end displays 200 ppem becomes a normal half-inch title size, with the quantum of stem width of 200/2048 = 6/64 of a pixel. This is still a hardly noticeable quantum of brightness.

I guess I cannot visualize how the problem would manifest itself.

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 01 Nov 2018 05:10:27 PM UTC, comment #7: 

I mean, that's one way to address the issue.

Behdad Esfahbod <behdad>
Thu 01 Nov 2018 05:09:40 PM UTC, comment #6: 


> Are you suggesting that the interpolation be done in device pixel (1/64) units instead of FUnits?


Yes.

Behdad Esfahbod <behdad>
Thu 01 Nov 2018 05:06:37 PM UTC, comment #5: 

Behdad, I still do not follow, sorry.

We seem to be using FT_Fixed for all delta/multiplier calculations, which should certainly be enough. I do not see any rounding up.

Are you suggesting that the interpolation be done in device pixel (1/64) units instead of FUnits?

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 01 Nov 2018 05:51:20 AM UTC, comment #4: 

My request is simple.

Variable fonts are declared as a base font and multiple deltas.  The final font is a (convex) linear interpolation of these.  Ie. the master font plus sum of (delta*multiplier).  The multipliers are numbers between (inclusive) 0 and 1.

Currently, each (delta*multiplier) is rounded up.  This results in too much error, as well as quantizing the possible instances unncessarily.

No, I don't think this has to do with axis granularity.

Behdad Esfahbod <behdad>
Thu 01 Nov 2018 04:18:59 AM UTC, comment #3: 

I was just inviting you to explain the bug better...

Ultimately though, isn’t it a font problem if the axis is not granular enough?

Alexei Podtelezhnikov <podtelez>
Group Member
Thu 01 Nov 2018 02:18:15 AM UTC, comment #2: 

Link, or summary, or something?

Behdad Esfahbod <behdad>
Thu 01 Nov 2018 02:06:17 AM UTC, comment #1: 

I do not know what exactly you are complaining about but I committed some optimizations, which might help.

Alexei Podtelezhnikov <podtelez>
Group Member
Wed 25 Jul 2018 04:20:01 AM UTC, original submission:  

By limiting interpolation output to whole FUnits, we are basically limiting the stem-width to whole FUnits.  When you think about the kind of hairline fonts people are designing with varfonts now, and rendered at high-DPI, or large sizes that such hairlines will be useful, I think supporting fractional stem widths is worthwhile.

Behdad Esfahbod <behdad>

 

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

Attached Files
file #46824:  interpolate_after_scale.diff added by podtelez (6KiB - application/octet-stream - please test)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-05-11 wl StatusNone Fixed
        Assigned toNone wl
        Open/ClosedOpen Closed
        Planned ReleaseNone 2.10.1
    2019-04-24 podtelez Attached File- Added interpolate_after_scale.diff, #46824

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code