Bug 46987 - Font sizes are rounded to the nearest 1px
Summary: Font sizes are rounded to the nearest 1px
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Text (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Major
Assignee: Myles C. Maxfield
URL: http://www.chatative.com
Keywords: InRadar
: 228545 244527 244994 (view as bug list)
Depends on:
Reported: 2010-10-01 09:18 PDT by Gaurav Misra
Modified: 2023-03-20 06:20 PDT (History)
24 users (show)

See Also:

test-case (74 bytes, text/plain)
2012-09-17 23:34 PDT, Ohad Eder-Pressman
no flags Details
WIP (37.98 KB, patch)
2018-09-07 22:38 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
WIP (37.98 KB, patch)
2018-09-07 22:42 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff
WIP (40.06 KB, patch)
2018-09-07 22:47 PDT, Myles C. Maxfield
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Gaurav Misra 2010-10-01 09:18:17 PDT
Fractional font sizes are ignored in safari and used only upto 1 decimal place in chrome. Firefox reads up to 3 decimal places making the font sizes render perfectly.

Use case:
On chatative.com I need every line to fit across the screen. Firefox fits every line exactly on the screen due to its proper handling of fractional font sizes and safari and chrome show the text slightly off the right edge.
Comment 1 Ohad Eder-Pressman 2012-09-17 23:34:57 PDT
Created attachment 164498 [details]
Comment 2 Ohad Eder-Pressman 2012-09-17 23:36:02 PDT
I confirm this is not working on Webkit. I can confirm that fractional/non-integer word-spacing is supported on IE (I tested PC IE 9.0.8112.16421IC) and Firefox-for-Mac (I tested Mac Firefox 10.0.2).

See http://ohad-etc.s3.amazonaws.com/eReader%20content%20bugs/test3/index.html for screenshots of all major browsers and how they handle this case.
Comment 3 Jonas Munk 2013-11-01 02:37:04 PDT
I realize that this is something done in order to be compatible with small font sizes in older IE versions in the past.

Maybe having a CSS property to trigger "perfect" font-size is a good first step - like font smoothing.

I find it especially annoying when animating the font-size since I know webkit has good font rendering support.

I guess it complicates calculating the layout.

Can you elaborate on that?
Comment 4 jrajeshwar 2018-06-05 07:36:04 PDT
Fractional font sizes are still being dropped/rounded as of Safari 11.1 / Webkit 605.1.15

Test cases:

Canvas: http://jsfiddle.net/w6xh4mu5/5/
HTML: http://jsfiddle.net/64hwk8bt/1/
SVG: http://jsfiddle.net/osLr6zdv/1/

Firefox, Chrome, and Edge all support fractional font sizes.
Comment 5 Radar WebKit Bug Importer 2018-06-05 17:05:55 PDT
Comment 6 Myles C. Maxfield 2018-06-18 15:24:48 PDT
Yeah, we purposely round the font sizes so that we get a higher hit rate in our various caches.
Comment 7 Myles C. Maxfield 2018-06-18 15:27:24 PDT
See FontDescription::computedPixelSize()


unsigned computedPixelSize() const { return unsigned(m_computedSize + 0.5f); }
Comment 8 Myles C. Maxfield 2018-09-07 22:38:18 PDT
Created attachment 349244 [details]
Comment 9 Myles C. Maxfield 2018-09-07 22:42:21 PDT
Created attachment 349245 [details]
Comment 10 Myles C. Maxfield 2018-09-07 22:47:03 PDT
Created attachment 349247 [details]
Comment 11 Shane Brinkman-Davis Delamore 2018-10-25 11:11:40 PDT
I'd like to add my vote for getting this fixed.

This is an important bug for my company. We use HTMLCanvas extensively. When using fractional font-sizes combined with transformation matrices, this bug leads to large rendering errors:

jsFiddle: http://jsfiddle.net/w6xh4mu5/26/

- Safari Version 12.0 (14606.

All other major browsers render fractional fonts correctly:

- Chrome 70.0.3538.77
- Microsoft Edge 42.17134.1.0
- Firefox 63.0 
- Opera 56.0.3051.52
- Internet Explorer 11 (yes, even IE11 renders correctly!)


In some cases our apps could multiply the font-size and scale the matrix down, but if we are, say, stroking an outline, or if the x/y scale ratio is not 1:1, this technique doesn't work.

Does rounding the font-size (before scaling) actually meaningfully increase cache-hits in the HTMLCanvas context? The rendered pixels are different as the scale changes anyway. Caching is good and all, but it should never lead to errors greater than about a pixel.
Comment 12 Myles C. Maxfield 2021-07-29 11:41:23 PDT
*** Bug 228545 has been marked as a duplicate of this bug. ***
Comment 13 Ashley Gullen 2021-08-03 05:50:58 PDT
This appears to be causing issues for us too: if you smoothly scale or zoom text, it jumps around. Worse, it looks like measureText() does use fractional sizes, but when you draw text it doesn't use a fractional size, which throws off our word wrap code and causes the edges of text to be cut off. If this is some kind of limitation in Safari, then measureText() should at least implement the same restriction, otherwise you can get text measurements that do not match what will be drawn.

Ref: https://github.com/Scirra/Construct-3-bugs/issues/4978
Sample video: https://photos.app.goo.gl/hN3CE6KtwbbLoeuq5
Comment 14 Ashley Gullen 2021-08-03 05:55:38 PDT
Actually I'm not sure what measureText() does, maybe it is the same, but either way this interacts badly with our word wrap code.
Comment 15 Ahmad Saleem 2022-05-31 13:35:50 PDT
I am able to reproduce bug from JSFiddle present in Comment 11 on Safari 15.5 (macOS 15.5). Chrome Canary 104 and Firefox Nightly 103 does not seems to have any issue on the test and matches each other. Thanks!
Comment 16 Théophile Avoyne 2022-08-24 01:56:14 PDT
That's critical to my company as well. We use fractional font sizes to scale up/down printable documents based on the viewport height/width. Resizing is smooth in every browser except Safari.
Comment 17 Myles C. Maxfield 2022-08-29 21:17:16 PDT
*** Bug 244527 has been marked as a duplicate of this bug. ***
Comment 18 Myles C. Maxfield 2022-08-29 21:17:44 PDT
Pull request: https://github.com/WebKit/WebKit/pull/3795
Comment 19 Antoine Quint 2023-03-20 06:20:06 PDT
*** Bug 244994 has been marked as a duplicate of this bug. ***