Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MacType: Better Font Rendering for Windows

github.com

Post reply on HN
Print view View original

91–100 of 130 posts

Re: MacType: Better Font Rendering for Windows

#91

Post by mgdlbp »

andrewmcwatters wrote: post #46
nwallin wrote: post #18

Earlier quoted context omitted.

It's wild to me that on both Windows and OSX that something that is obviously just personal preference is baked into the operating system, with no method for changing it. It's on the same level as having an operating system that didn't let you change your desktop background.

As soon as you realize that changing rasterization strategies alters the bounding box of character textures, and that a lot of UI positions are hardcoded, it makes sense.

This likely isn't much of an issue for the operating systems themselves, as they are well globalized and (in my experiences with Windows) adapt fine to RTL and CJK scripts.

Third-party apps, on the other hand, do seem rife with clipped text, even in English at nonstandard DPIs.

Edit: Ah, this was already said by the existing sibling comment.

Re: MacType: Better Font Rendering for Windows

#92

Post by mastazi »

girvo wrote: post #86
mastazi wrote: post #74

Earlier quoted context omitted.

> macos is clearly better. I disagree. Yes I do prefer MacOS on high DPI screens but, at low DPI, I prefer Windows. It's about how the edges of characters look, as I was saying here https://news.ycombinator.com/item?id=28031314

Which is a fair enough point, but considering the only screens I own are high DPI, MacType is quite interesting to me

Of course, it all depends on your needs. I'm a fan of repurposing old PCs for less demanding tasks so I have a few of those low DPI monitors around the house.

Re: MacType: Better Font Rendering for Windows

#93

Post by uranusjr »

Didn’t see it mentioned yet, so I’m going to drop the link. Joel Spolsky did a very good writeup in 2007 (back when Apple released Safari for Windows) on the different font rendering strategies Mac and Windows take. MacType is, fundamentally, an attempt to implement Mac’s font rendering algorithm on Windows.

https://www.joelonsoftware.com/2007/06/12/font-smoothing-ant...

Re: MacType: Better Font Rendering for Windows

#94

Post by FpUser »

hsn915 wrote: post #54
crazygringo wrote: post #7

It's bizarre that neither the README nor the associated minimal site explains what it does in detail, with screenshots or anything. I'm assuming this is a modern version of GDI++, which a decade ago brought Mac-style font rendering to Windows, but stopped being maintained a while ago. For people who aren't aware of the difference, it's essentially that Windows uses heavy font hinting to try to align character strokes…

I never understood _why_ but text rendering on windows has always looked like garbage to me. It was obviously not the screen resolution or anything, because you can run a linux vm (say, on virtualbox) and the text rendering inside the VM will look much better than the text in windows. > Nobody's "right", it's just personal preference. I don't think that's true. macos is clearly better.

>"I don't think that's true. macos is clearly better."

It is easier for me to read fonts on Windows. And that is all that really matters to me. Fonts on Mac look fuzzy. This "clearly better" is just your perspective. It is not universally shared.

Yes I do use large 4K monitors but I keep text scale at 100%. Otherwise what's the point. The more text I see when programming the happier I am

Re: MacType: Better Font Rendering for Windows

#95

Post by vborovikov »

Joeri wrote: post #16
didibus wrote: post #9

I just switched from Windows to a Mac, and I immediately found that the colors and contrast and the clarity of images and text on the same monitor I connect my laptop too improved. I wasn't sure if it was just in my head, but something about the rendering in Mac seems better to me. I don't know if they have better calibration for colors and contrast, better anti-aliasing, etc., but I seem to see the screen much bette…

Have you tried to use the windows ClearType Text Tuner to improve the font rendering? Windows tries to take advantage of subpixels to improve crispness but it can cause color fringing which makes text harder to read. The tuner utility helps with that. You can also disable cleartype entirely to get standard anti-aliasing, which is what macOS does on non-retina screens. Personally I find the macOS way of rendering on s…

There is a fix for apps that are blurry on the non-primary low-res display. Go to the app properties and on the Compatibility tab click the button 'Change high DPI setting' and check 'Override high DPI scaling behavior' option. Make sure 'Application' is selected in the 'Scaling performed by:' drop-down list.

The blurry apps will render a bit bigger on the non-primary low-res display but everything will be crisp.

Re: MacType: Better Font Rendering for Windows

#96

Post by danybittel »

garaetjjte wrote: post #27
krona wrote: post #15

Earlier quoted context omitted.

I always thought the biggest difference was subpixel vs grayscale anti-aliasing. Prior to very high pixel density screens, I hated the Mac/android font rendering, mostly due to the migraines caused by my eyes straining to correct for the seemly out-of-focus text blur.

>I always thought the biggest difference was subpixel vs grayscale anti-aliasing. It's mostly hinting. Windows actually doesn't do subpixel antialiasing in many applications anymore. (such as Start menu or new Settings panel)

Of course it does.

Re: MacType: Better Font Rendering for Windows

#97

Post by kmeisthax »

vborovikov wrote: post #95
Joeri wrote: post #16

Earlier quoted context omitted.

Have you tried to use the windows ClearType Text Tuner to improve the font rendering? Windows tries to take advantage of subpixels to improve crispness but it can cause color fringing which makes text harder to read. The tuner utility helps with that. You can also disable cleartype entirely to get standard anti-aliasing, which is what macOS does on non-retina screens. Personally I find the macOS way of rendering on s…

There is a fix for apps that are blurry on the non-primary low-res display. Go to the app properties and on the Compatibility tab click the button 'Change high DPI setting' and check 'Override high DPI scaling behavior' option. Make sure 'Application' is selected in the 'Scaling performed by:' drop-down list. The blurry apps will render a bit bigger on the non-primary low-res display but everything will be crisp.

On later Windows 10 builds, you might want to try "System (enhanced)" mode, it manages to get proper DPI scaling on entirely DPI-oblivious apps.

(It basically does what Microsoft should have done decades ago and changes GDI pixels to be virtual rather than physical.)

Re: MacType: Better Font Rendering for Windows

#98

Post by hashhar »

breakfastduck wrote: post #67
ascom wrote: post #40

Earlier quoted context omitted.

Another possibility is that macOS actually does proper color management throughout the entire OS - the Windows shell/desktop is simply not color managed and it's especially irritating when you have a wide color gamut monitor.

Another of the staggering deficiencies for windows. Right next to audio management. Because audio drivers and colour management aren't important ofc....

Audio management better on MacOS?

There is no system level volume mixer, you can't route audio between apps, you can't even monitor an audio output device. To do anything sane with audio on MacOS requires external applications like Loopback or Blackhole or any of the virtual cable applications.

Re: MacType: Better Font Rendering for Windows

#99

Post by ascom »

navjack27 wrote: post #84
breakfastduck wrote: post #67

Earlier quoted context omitted.

Another of the staggering deficiencies for windows. Right next to audio management. Because audio drivers and colour management aren't important ofc....

Sure uh huh. Mac is great when I want to open up GarageBand on my M1 Mac Mini that's connected to my TV over HDMI. It yells at me to change the sample rate to 44.1. I can't do that there is no way to do that. I also can not control the volume using keyboard volume or system OS volume. Mac OS is great! Also the HDR is questionable unless you are using an Apple display which I am not. Edit: basically what I'm getting a…

Re: sample rate: you might be looking for the Audio MIDI Setup application.

Re: MacType: Better Font Rendering for Windows

#100

Post by bruhsfx2 »

mgdlbp wrote: post #91
andrewmcwatters wrote: post #46

Earlier quoted context omitted.

As soon as you realize that changing rasterization strategies alters the bounding box of character textures, and that a lot of UI positions are hardcoded, it makes sense.

This likely isn't much of an issue for the operating systems themselves, as they are well globalized and (in my experiences with Windows) adapt fine to RTL and CJK scripts. Third-party apps, on the other hand, do seem rife with clipped text, even in English at nonstandard DPIs. Edit: Ah, this was already said by the existing sibling comment.

I believe Windows's approach is localisation not globalisation. Many programmes runs properly only in designed locales, not that programmes run well in any locale.

Chinese/Korean rendered incorrectly on English UI because system hardcoded a font fallback, which put Japanese font first, regardless of how languages are ordered in the Settings. This is largely true for traditional Win32 programmes, like Chrome, Edge, Explorer.exe, etc. However UWP apps using the new UI framework (like Unigram, Intel Command Centre etc) behave correctly if setting Chinese/Korean as secondary language.

It's different on macOS or iOS however, if you set a system locale order as 1. English, 2. Chinese, then Chinese content will render correctly with correct Chinese system font PingFang.

Another issue that is also very important is that Chinese (Simplified or Traditional), Korean and Japanese share amount of the same characters but written differently. That means system must render the glyph in correct variant, like in the example of Source Han Sans

https://github.com/adobe-fonts/source-han-sans/raw/release/S...

Post reply on HN