CFF (in OTF) font rendering issue on Windows only

Question

CFF (in OTF) font rendering issue on Windows only

Roger Khoueiri 20

We have a situation where some fonts render with artifacts only when rendering them on Windows.

The same test works perfectly on Linux, macOC, iOS, Android and curiously, on Windows but only when rendering the glyphs using FreeType.

Might be an indication that the font rendering subsystem on Windows lacks proper support for the cases in these fonts. (I tried rendering with GDI, GDI+ and DirectWrite - all the same.)

Here's a small test that can be used to demonstrate. The link to the test files (and zip file) https://apryse-my.sharepoint.com/:f:/p/roger_khoueiri/IgCiiO8vCZFlSpvNzwq-XHAnAUfkHbt-7BihC-uidMyEXBY?e=OcIEo9 contains a very simple test. Extract the content to a folder then:

**
On Windows**, double-click font-test.html to open in Edge, Chrome or FireFox. Zoom out and in to see the artifacts in the rendering of some of the letters at different zoom levels.

**
On Linux**, the same test renders all the letters fine.

In addition, on Windows, you can double-click the .otf font files to preview them in Windows font viewer. You will see the artifacts at different pt sizes. For example in cff1.otf, notice the capital T at pt sizes 12, 18 and 24, and in cff2.otf, notice the letter e at the same pt sizes.

The font files are perfectly valid and when rendering the glyphs using FreeType they are correct.

If Microsoft can provide a fix for rendering these on Windows that would be great.

This is an issue that has been happening on Windows with similar fonts for a number of years now.

e.g.:
Screenshot 1.png

Thanks,
Roger

0 comments

Answer accepted by question author

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hello @Roger Khoueiri ,

Thank you for the detailed report and the sample files. I spent some time looking at cff1.otf and cff2.otf, and I would like to share what I found.

Inspecting the CFF outlines directly, the affected glyphs appear to be built from overlapping or self-intersecting contours. The capital T in cff1.otf, for example, is two separate rectangles (stem and crossbar) that overlap near the top rather than a single merged outline, and the e glyph in cff2.otf is a self-intersecting contour. The contours also use clockwise winding, while the PostScript/CFF convention for outer contours is counter-clockwise, and there are no per-glyph hints.

These shapes still fill correctly at large sizes, but when the Windows CFF rasterizer grid-fits at small sizes, the coincident edges of the overlapping contours can round to slightly different pixel boundaries, which seems to be what exposes the spikes and notches. FreeType appears to be more tolerant of this geometry, which may explain why it renders cleanly.

I tested this by rendering the original fonts through GDI+ (the same rasterizer used by GDI and DirectWrite) and reproduced the artifacts, then ran an overlap-removal pass and rendered again through the same path, after which they were gone.

Based on this, running "Remove Overlap" and "Correct Direction" on the glyphs, and optionally re-hinting, may resolve the issue. This can be done in FontForge (Element > Overlap > Remove Overlap, then Element > Correct Direction), or with fontTools and skia-pathops:

pip install fonttools skia-pathops

from fontTools.ttLib import TTFont
from fontTools.ttLib.removeOverlaps import removeOverlaps

for path in ("cff1.otf", "cff2.otf"):
    font = TTFont(path)
    removeOverlaps(font)
    font.save(path.replace(".otf", "_fixed.otf"))

It might be worth trying the cleaned fonts in your original HTML test and in the Windows font preview to see whether the artifacts are resolved on your end. If any glyphs still show issues, I would be happy to take another look if you can share the updated files. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.

Roger Khoueiri 20 Reputation points

2026-08-17T15:15:10.63+00:00

Hello @Taki Ly (WICLOUD CORPORATION)

Thank you for the concise explanation. I had suspected this is a contour overlap issue and tried to provide a work around in our SDK for glyphs with this issue. FreeType gives this information.

The problem we have is that we generate these CFF fonts when opening a PDF that contains partially embedded TrueType fonts and we need to resave the PDF or save to other formats but we cannot use the original TTF font as is. So we generate equivalent CFF fonts with the same path data for the glyphs coming from the TTF.

We will not be able to pre-process the CFF font before embedding it in the final document using 3rd party external tools like FontTools with skia-pathops.

Alternatively we may need to build and link with skia-pathops directly and run the removeOverlap() on the paths we have before generating the CFF.
This is a big undertaking as it may require building more from skia that just the path-ops part.

I understand that Windows CFF rasterizer is strict but do you think that Microsoft might provide an internal fix/tweak for this (very old) issue in the CFF rasterizer to make it work the way FreeType or other operating systems render these fonts ?
Roger Khoueiri 20 Reputation points

2026-08-17T17:10:16.06+00:00

Also an additional question.
Do you think that if we generate CFF v2 fonts vs CFF, Windows CFF rasterizer might do a better job?
I read that one of the differences between CFF2 and CFF is that CFF2 allows overlapped contours while CFF does not.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-18T06:04:38.6866667+00:00
Hi @Roger Khoueiri ,

Thank you for the additional context about your PDF pipeline.

On whether Microsoft might make the CFF rasterizer as tolerant as FreeType: I cannot speak to internal roadmap, and I would treat a change as unlikely. The current behavior is largely by design, as the Type2/CFF charstring spec advises against overlapping or self-intersecting contours, so the rasterizer is following the spec rather than misbehaving. You are welcome to file it as product feedback, but I would suggest planning around it.

Since your pipeline already starts from TrueType path data, one option that may fit well is to emit a glyf (TrueType outline) font instead of a CFF font when you re-embed. The Windows glyf rasterizer handles overlapping contours much more gracefully, so the same paths tend to render cleanly with no overlap removal, and it avoids both skia-pathops and the quadratic-to-cubic conversion a CFF path requires. In my testing, the same path data in a glyf container rendered without the spikes that the CFF version showed.

On CFF2: your reading is correct that CFF2 permits overlaps where classic CFF does not, but I would be cautious. In my testing the same overlapping paths in a CFF2 font still showed the artifacts on the GDI/GDI+ path, and CFF2 support across the Windows stack (especially classic GDI) is uneven, so it may introduce compatibility issues without solving this one. I would not recommend it as a workaround.

If keeping CFF is a hard requirement, an overlap-removal pass before generating the charstrings remains the reliable route, but a glyf-based container is likely the least invasive option.

For your references:

OpenType glyf table (overlapping contours, OVERLAP flags)

OpenType CFF table

OpenType CFF2 table

Adobe Type 2 Charstring Format (Tech Note 5177)
Roger Khoueiri 20 Reputation points

2026-08-18T12:00:18.61+00:00

Thank you very much for you valuable feedback
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-19T02:13:03.28+00:00

You’re very welcome, @Roger Khoueiri .

I’m glad the information was helpful. I’ll go ahead and close the case now. If you have any new questions in the future, please feel free to post a new question on Microsoft Q&A.

Have a great day!

1 additional answer

Your answer

Roger Khoueiri 20 Reputation points

2026-08-17T15:15:10.63+00:00

Hello @Taki Ly (WICLOUD CORPORATION)

Thank you for the concise explanation. I had suspected this is a contour overlap issue and tried to provide a work around in our SDK for glyphs with this issue. FreeType gives this information.

The problem we have is that we generate these CFF fonts when opening a PDF that contains partially embedded TrueType fonts and we need to resave the PDF or save to other formats but we cannot use the original TTF font as is. So we generate equivalent CFF fonts with the same path data for the glyphs coming from the TTF.

We will not be able to pre-process the CFF font before embedding it in the final document using 3rd party external tools like FontTools with skia-pathops.

Alternatively we may need to build and link with skia-pathops directly and run the removeOverlap() on the paths we have before generating the CFF.
This is a big undertaking as it may require building more from skia that just the path-ops part.

I understand that Windows CFF rasterizer is strict but do you think that Microsoft might provide an internal fix/tweak for this (very old) issue in the CFF rasterizer to make it work the way FreeType or other operating systems render these fonts ?
Roger Khoueiri 20 Reputation points

2026-08-17T17:10:16.06+00:00

Also an additional question.
Do you think that if we generate CFF v2 fonts vs CFF, Windows CFF rasterizer might do a better job?
I read that one of the differences between CFF2 and CFF is that CFF2 allows overlapped contours while CFF does not.
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-18T06:04:38.6866667+00:00

Hi @Roger Khoueiri ,

Thank you for the additional context about your PDF pipeline.

On whether Microsoft might make the CFF rasterizer as tolerant as FreeType: I cannot speak to internal roadmap, and I would treat a change as unlikely. The current behavior is largely by design, as the Type2/CFF charstring spec advises against overlapping or self-intersecting contours, so the rasterizer is following the spec rather than misbehaving. You are welcome to file it as product feedback, but I would suggest planning around it.

Since your pipeline already starts from TrueType path data, one option that may fit well is to emit a glyf (TrueType outline) font instead of a CFF font when you re-embed. The Windows glyf rasterizer handles overlapping contours much more gracefully, so the same paths tend to render cleanly with no overlap removal, and it avoids both skia-pathops and the quadratic-to-cubic conversion a CFF path requires. In my testing, the same path data in a glyf container rendered without the spikes that the CFF version showed.

On CFF2: your reading is correct that CFF2 permits overlaps where classic CFF does not, but I would be cautious. In my testing the same overlapping paths in a CFF2 font still showed the artifacts on the GDI/GDI+ path, and CFF2 support across the Windows stack (especially classic GDI) is uneven, so it may introduce compatibility issues without solving this one. I would not recommend it as a workaround.

If keeping CFF is a hard requirement, an overlap-removal pass before generating the charstrings remains the reliable route, but a glyf-based container is likely the least invasive option.

For your references:

OpenType glyf table (overlapping contours, OVERLAP flags)

OpenType CFF table

OpenType CFF2 table

Adobe Type 2 Charstring Format (Tech Note 5177)
Roger Khoueiri 20 Reputation points

2026-08-18T12:00:18.61+00:00

Thank you very much for you valuable feedback
Taki Ly (WICLOUD CORPORATION) 4,440 Reputation points Microsoft External Staff Moderator

2026-08-19T02:13:03.28+00:00

You’re very welcome, @Roger Khoueiri .

I’m glad the information was helpful. I’ll go ahead and close the case now. If you have any new questions in the future, please feel free to post a new question on Microsoft Q&A.

Have a great day!

Answer 1

Taki Ly (WICLOUD CORPORATION) 4,440 Microsoft External Staff Moderator

Hi @Roger Khoueiri ,

I'm working on this issue and will try to get back to you soon. Thank you for your patience.

0 comments