[Webkit-unassigned] [Bug 152393] REGRESSION (r172008): Icon fonts using hinting blurred at odd window widths

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sat Dec 19 02:28:38 PST 2015


https://bugs.webkit.org/show_bug.cgi?id=152393

--- Comment #13 from Adam Strzelecki <ono at java.pl> ---
> In one respect, this is working as intended. Sub-pixel placement of layout objects is a progression. Fonts, in general, benefit greatly from sub-pixel positioning, and it greatly improves readability of text.

You call progression something that causes blurriness and degrades readability. This does not sound convincing at all, actually it sounds even worse because "it greatly improves readability of text" is exactly contradicting screen-shots attached to this issue.


> The cause of this bug is pretty straightforward - the font is trying to draw something exactly n pixels wide, but it starts halfway through the first pixel. Therefore, your edges which you thought appeared at discrete pixel boundaries all actually happen halfway through the pixel, leading to 50% coverage and grey pixels.

This is what I have already explained above. I know the reason, yet I am telling that such behavior causes blurry rendering.


> All the major browsers which run on OS X all have the same behavior here.

If you are talking about Chromium and WebKit, then yes, they have regressed in same moment ~Jul 2014 sharing the same set of patches introducing text rendering at fractional offsets.

If we speak about Firefox, then Firefox never respected font hinting until ver. 25 where it started to work when the offsets were integer.


> For your use case of showing icons in web content, I would suggest using SVG. Fonts were never designed for this purpose.

I am sorry but this argument is completely untrue and fanciful. Computer fonts were always meant to be drawn on computer screen and optimized for underlying pixel grid. That's why we had bitmap fonts, and then we moved to vector representation in same time introducing font hinting (I stated explicitly in the subject that's the regression makes browsers not obey font hinting at fractional offsets). That's why computer fonts are always designed keeping in mind pixel grid (eg. San Francisco font presentation at WWDC 2015).

Moreover if fonts were not meant to carry icons, what the heck do all the icons and web-dings in Unicode standard v7, what do all Emojis in Unicode standard!? Unicode committee don't know well the purpose of fonts too? Sorry but you are stating something completely opposite to reality.


> A "solution" is simply to make sure your markup always results in these icons being drawn at integer pixel locations.

I said in the issue "This cannot be worked around using some CSS tricks." I've seen ppl trying but so far I don't see a real solution to ensure that some inline text box is aligned to pixel boundary. Only working solutions I have seen so far are JavaScript, but honestly using JavaScript to fix such regression is a real pity.

> Another idea for a solution is to allow something like a "round()" function which can be used inside the "calc()" CSS function. Presumably something like this would suit your needs?

Presumably. Any solution that brings us to sharp rendering as it was in May 2014 would be good. Best if it was working without extra tweaking. If it needs some extra but not enormous CSS then it is good to. But so far I've seen no such solution.


Altogether I disagree with your points, I disagree to close this issue especially when:

1. The issue shows rendering degradation and affects all users

2. No workaround was given


Therefore I humbly request to reopen it until a solution other than "it is working as intended" is given.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20151219/bc7d6b77/attachment.html>


More information about the webkit-unassigned mailing list