<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - REGRESSION (r172008): Icon fonts using hinting blurred at odd window widths"
href="https://bugs.webkit.org/show_bug.cgi?id=152393#c13">Comment # 13</a>
on <a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED INVALID - REGRESSION (r172008): Icon fonts using hinting blurred at odd window widths"
href="https://bugs.webkit.org/show_bug.cgi?id=152393">bug 152393</a>
from <span class="vcard"><a class="email" href="mailto:ono@java.pl" title="Adam Strzelecki <ono@java.pl>"> <span class="fn">Adam Strzelecki</span></a>
</span></b>
<pre><span class="quote">> 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.</span >
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.
<span class="quote">> 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.</span >
This is what I have already explained above. I know the reason, yet I am telling that such behavior causes blurry rendering.
<span class="quote">> All the major browsers which run on OS X all have the same behavior here.</span >
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.
<span class="quote">> For your use case of showing icons in web content, I would suggest using SVG. Fonts were never designed for this purpose.</span >
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.
<span class="quote">> A "solution" is simply to make sure your markup always results in these icons being drawn at integer pixel locations.</span >
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.
<span class="quote">> 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?</span >
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>