search

adobe-fonts / source-sans

Sans serif font family for user interface environments
https://adobe-fonts.github.io/source-sans
SIL Open Font License 1.1
3.49k stars 230 forks source link

Source Sans (Pro) not rendered properly in some Windows applications #258

Closed viggekj closed 1 year ago

viggekj commented 1 year ago

On my Windows 10 PC I see that Source Sans (Pro) is not rendered well. I installed the latest versions of Source Sans Pro and Source Sans 3 by using the .ttf files.

In the font list of MS Word:

Rendering issue - MSWord The samples in the font list seem to be rendered without anti-aliasing. As you can see the Source Sans fonts do not get a similar sleek look as the Arial, but end up with a garbled blocky appearance. The Source Sans font samples look significantly worse than any other fonts in the list.

In a WPF (Windows Presentation Foundation) test application:

The application renders some text with different settings of TextOptions.TextFormattingMode and TextOptions.TextRenderingMode: Rendering issue - WPF The Aliased texts at the top look similar to what MS Word displays. But also the anti-aliased modes have some very strange effects, especially at the top and the bottom of the characters. For most cases Source Sans 3 performs significantly better than Source Sans Pro.

Regarding reproducibility:

The issues are not reproducible on all machines. My colleague's PC gets nicely rendered Source Sans both in the MS Word font list and when running the same WPF test program. I have tried what I can think of (turning ClearType on / off, turning Aliasing on/off, hardware acceleration on/off, reinstalling latest version of fonts from different sources) without making a difference to the output.

Any ideas on what is going on here?

fitojb commented 1 year ago

This is a bug limited to Microsoft Word’s font list. AFAICT, they do it that way for performance reasons. But it’s nothing that can be fixed from the font’s side.

viggekj commented 1 year ago

This is a bug limited to Microsoft Word’s font list. AFAICT, they do it that way for performance reasons. But it’s nothing that can be fixed from the font’s side.

Well, that is not the whole truth. Yes, as far as I have understood MS Word disables font anti-aliasing in the font list. But then the font should be shown without smoothing. Not with the garbled look that we see. Other fonts in the font list do not have the same problem as Source Sans Pro here, so there is something special about this font.

Also, it is not just in MS Word that Source Sans Pro does not render well. The test program that I showed a screenshot from is a simple Windows application with a WPF UI layer. There too Source Sans Pro is rendered significantly worse than any other font I have tried. Source Sans 3 works better, but also looks terrible when antialiasing is disabled. So again this indicates that there is something special about how this font is defined that Windows does not agree with.

fitojb commented 1 year ago

Source Sans Pro is an old version that isn’t developed further

frankrolf commented 1 year ago

Getting fonts rasterized “like Arial” in “Display, Aliased” environment (which means b/w 1-bit rendering) is a significant effort, and basically requires drawing pixel images of every glyph, at every point size.

I don’t think there is a good reason to use aliased type today.

As @fitojb correctly said, the current version of Source Sans is Source Sans 3. Source Sans Pro is version 2. The “Pro” suffix was dropped because it does no longer carry much meaning (“Pro” originally communicated Adobe Latin-2 character set support).

I can see SS3 performing well in the WPF test app – which app is this, BTW?

pauldhunt commented 1 year ago

I view this as a cosmetic issue within an edge case scenario. As such, I feel that a fix is not necessarily beneficial. I am closing this issue.

viggekj commented 1 year ago

I can see SS3 performing well in the WPF test app – which app is this, BTW?

It is just a quick WPF based test application that I made in five minutes. It does nothing except displaying some text with different fonts and rendering modes.

I view this as a cosmetic issue within an edge case scenario. As such, I feel that a fix is not necessarily beneficial. I am closing this issue.

OK, I understand your reasoning. It clearly works better in Source Sans 3, with the exception of aliased rendering. We do actually use that in some of our test applications (to get text rendered the same way on different machines that have different anti-aliasing setup). But I agree that this is more of an edge case scenario.