Hinting issues in CFF2 Variable Font

[santhoshtr]

The sample page https://adobe-fonts.github.io/source-serif/ when viewed(I am using latest Firefox, Chrome in latest Ubuntu) there is a visible pixel bleed as illustrated in the below image.

From my experiences, if we have nodes like this in the glyph outline, rasterization has above issue. Is this a known issue with the current state of variable fonts?

[frankrolf]

Hi, thank you for the report, I am aware of it.

The construction you show indeed is the way in which Source Serif’s outlines are assembled (what is the difference between the left and the right example?). However, I don’t understand how the exact same y-coordinate is allowed to rasterize at different heights, so I would assume this being a rasterizer problem.

It also depends a lot on the environment used (black on white/white on black, which browser). One additional variable might be that at the time of your report, you were most likely looking at an unhinted VF. If you check the page now (4.005 CFF2, hinted), do you see a difference?

I will consider modifying the outlines if I get lots of feedback about this, but I am reluctant because it seems like an inconvenient workaround for a purely technical problem. Also the workload for this is big, because roughly 5000 glyphs would need to be changed.

[santhoshtr]

One additional variable might be that at the time of your report, you were most likely looking at an unhinted VF. If you check the page now (4.005 CFF2, hinted), do you see a difference?

The 'bleeding' issue is not visible now, but a more important issue appeared. Letters are aligning to different baselines and you see letters with nonuniform size as shown below:

I also took a full page screenshot of the site- https://i.imgur.com/fQVx6J1.png using site-shot.com and the issue is quickly noticeable.

Are you aware of any existing bug report against the rasterizers about this issue?

[frankrolf]

Huh, that’s interesting – thanks for sharing. Source Serif is (to my knowledge) the first hinted CFF2 font, so I am not surprised to see some odd rasterization behavior. “Party Baseline” is unexpected, though 🥳

Do you know which browser site-shot uses? (I poked around a bit, but couldn’t tell). Also, https://www.screenshotmachine.com shows the same result.

[kenmcd]

There have been some other similar rasterization issues (with other fonts) when there are co-linear paths from overlapping elements. See: Artifact on some letterforms with variable WOFF2s #493 https://github.com/microsoft/cascadia-code/issues/493 and [Linux/FreeType + VariableTTF-specific] Some glyphs (e.g. a '4', or the bottom-right stem of lowercase 'u') look weird at certain sizes, due to mis-handling overlapping paths of variable font. Needs FreeType 2.10.3 and font flag OVERLAP{SIMPLE, COMPOUND} #350_ https://github.com/microsoft/cascadia-code/issues/350

And I have seen some others (which I cannot find again ATM).

Note: they talk about it being TTF-specific, but I think that it is probably really variable-specific (as compared to static OTFs and TTFs) because of the co-linear overlaps. It may also appear with static fonts with co-linear overlaps. Since it does not happen with all OS/application combos it does not appear to be a font issue.

So it does appear to be a rasterizer issue. Examples have of the issue have been noted on both Mac and Linux.

[santhoshtr]

Thanks for the link to those issues @kenmcd. It seems cascadia fixed this issue in the font by setting OVERLAP_COMPOUND flag in the glyph.

[skef]

@santhoshtr - we're trying to determine the scope of the baseline alignment problem. Can you clarify whether you've seen this in the browsers you list outside of the screen-shot tool you're using, or whether it's just in the tool? If it's not just in the tool, can you provide the version of Windows and of the browser? Thanks.

[skef]

To clarify, this question is about the second, baseline-related problem, not the initial bleed-through problem.

[santhoshtr]

If it's not just in the tool, can you provide the version of Windows and of the browser?

• Firefox 109.0.1 (64-bit), Ubuntu 22.08
• Google Chrome Version 109.0.5414.119 (Official Build) (64-bit), Ubuntu 22.08

[akrawitz]

I'm seeing the baseline alignment problem as well: Google Chrome Version 111.0.5563.111 (Official Build) (64-bit), Windows 10

I'll note that it seems to be more than just a problem with baseline alignment. Look at the "e" next to the "z" in the word "sizes" in the screenshot above. The "e" extends above and below the "z".

Unfortunately, this version of the font is really unusable at the moment.

Also, I would suggest either renaming this issue to reflect this new issue or perhaps move it to a new issue. Something so that it is easier for others to find the "baseline alignment issue" as opposed to the bleeding issue.

[akrawitz]

Note that this problem (baseline alignment and unequal letter sizes) exists in version 4.5.0, but NOT in 4.4.0 with: Google Chrome Version 111.0.5563.111 (Official Build) (64-bit), Windows 10

[frankrolf]

@akrawitz This is expected. 4.005 is the first hinted release, while the CFF2 files for 4.004 are unhinted. The font seen at https://adobe-fonts.github.io/source-serif/ are the CFF2 fonts. At this point, I am considering a new release to carry over the bugfixes of 4.005, but without hinting.