Browser Stack confirms that at least the Courier New waterfall rendered correctly in Chrome 37 i.e. the version where font rendering under Windows switched from GDI to DirectWrite. Versions 35/36 (GDI) rendered incorrectly, as did all versions after 37 (DirectWrite). So this did indeed work before, albeit briefly:

https://www.browserstack.com/screenshots/f3de9ab9cc44f0fe5554b3944578351a38d1dc4b

Seeing the same effect on Linux.

Able to reproduce the issue on Windows 7, Ubuntu 14.04 using chrome latest stable M49-49.0.2623.110 and latest canary M51-51.0.2695.1. Observed the geometric precision not rendering correctly as it's shown correctly on Mac OS 10.11.4.

This is a non-regression issue seen from past M35-35.0.1851.0 and M40-40.0.2192.0 , Hence marking it as untriaged.

Note: Unable to find the regression range to provide bisect information so removing bisect label.

Thanks!

The reporter said: "...at least the Courier New waterfall rendered correctly in Chrome 37..." (https://bugs.chromium.org/p/chromium/issues/detail?id=599046#c1), so it ought to be possible to bisect from M37 to a later version - potentially no further than M38. Could we try that? (It's possible you already did this since you said "...seen from past M35-35.0.1851.0 and M40-40.0.2192.0." - in that case just remove the label again...)

On windows this is intentional for DOM content for a handful of legacy fonts to improve legibility. For SVG and on other platforms it should not be the case however. 

pdr, are you aware of any changes to svg text handling lately?

I don't think this is recent, but I do think it's a bug. Even on linux this does not look correct to me.

We actually support text-rendering on html elements too and this looks wrong:
http://jsbin.com/yitobij

@eae, would you mind looking into this one?

We disable geometricPrecision for bitmap fonts and for certain legacy fonts to improve legibility. Switching to another font makes it render as expected.

Calling them "legacy" fonts trivialises the issue: the affected fonts are very widely used, and Chrome's inability to render them accurately under Windows means the browser cannot be considered for use with professional web-based design applications.

The fact that almost every other Windows browser can render these fonts both accurately and legibly means that browsers other than Chrome will more likely be used for such applications.

If Chrome chooses to sacrifice accuracy for legibility by default, then that is a choice of the browser. However, to disregard the specification and to rob web developers of the choice to prioritise accuracy should not be acceptable.

Is there any reason why geometricPrecision, when explicitly specified, can't cause Chrome to render fonts in a geometrically precise way, always?

FWIW, I agree with what you're saying, and will use up some of my supposed brownie  points by reopening this bug.

The "original intention" of the 'geometricPrecision' property is indeed to try to achieve linear font scaling - for purpose such as scaling animations and decorative text. (Outside of such use cases you should really shy away from it though... this value is not for making text readable.)

That being said though, using bitmap fonts for such use cases is pretty counterintuitive.

Maybe we could get a (TextRun) flag to force enable it for SVG content?

Thank you for re-considering fixing this.

You're right fs, if geometricPrecision is specified we should override legacy fonts check.

Adding to back-log.

Thanks!

This issue has been available for more than 365 days, and should be re-evaluated. Please re-triage this issue.
The Hotlist-Recharge-Cold label is applied for tracking purposes, and should not be removed after re-triaging the issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 12:

> That being said though, using bitmap fonts for such use cases is pretty counterintuitive.

Bitmap fonts, isn't that issue 797496? While issue 797496 might only have Linux as the specified OS where it occurs the code in question there also appears in FontPlatformDataWin.cpp