search

badges / gh-badges

Go to badges/shields. Especially if you don't know why. (This repo is old.)
http://img.shields.io/
Creative Commons Zero v1.0 Universal
86 stars 29 forks source link

Inform browsers on how to optimize text rendering #6

Closed alrra closed 10 years ago

alrra commented 10 years ago

The text-rendering svg property provides a hint to the user agent about how to optimize its text rendering.

In this particular case, the value specified for the text-rendering property is geometricPrecision, indicating that the user agent should emphasize geometric precision over legibility and rendering speed.

This is done because certain aspects of fonts — such as kerning — don't scale linearly:

If geometricPrecision is fully supported by the rendering engine, it will allow users to scale text fluidly, making the text look good.

References:

See also:

espadrine commented 10 years ago

Does it give less blurry results for you? Can you provide a comparison snapshot?

In my case, the result is just as sharp, but the letters are "rearranged" (as a result, I presume, of a suspended kerning) in an improbable way:

No text rendering: firefox-no-text-rendering

Text rendering applied: firefox-text-rendering

Note the weird space between "w" and "hiz" in "whiz", and in other places.

I'd love to have more comparisons before we settle on this choice.

alrra commented 10 years ago

Does it give less blurry results for you?

There are some browsers where it does, but in most cases, there isn't any difference:

Note the weird space between "w" and "hiz" in "whiz", and in other places.

Can you specify the browser / OS / device where that happened ? I didn't see this exact behavior in any of the browsers I've tested in.

I'd love to have more comparisons before we settle on this choice.

Of course, that is why I've open this pull request, so we can discuss this potential addition.

espadrine commented 10 years ago

Thanks a lot for all this work!

It's surprising but very welcome to see that IE10 doesn't have the blur bug.

It usually doesn't make a difference, but if it makes it that much better in Firefox, it's worth it.

However, it seems like it changes the width of the text significantly. On HEAD, we are computing that dynamically (using canvas). Is there a way to ensure that what is computed matches?

espadrine commented 10 years ago

Note the weird space between "w" and "hiz" in "whiz", and in other places.

Can you specify the browser / OS / device ? I didn't see this exact behavior in any of the browser I've tested in.

Firefox + Linux KDE + Thinkpad (desktop)

alrra commented 10 years ago

However, it seems like it changes the width of the text significantly. On HEAD, we are computing that dynamically (using canvas). Is there a way to ensure that what is computed matches?

Maybe I'm missing something (and I apologize for that), but isn't the font-size hard-coded into template.svg ?

Theoretically, geometricPrecision should ensure the text is rendered at the correct size, but the other way around, doesn't always happen.

From MDN:

In SVG, when text is scaled up or down, browsers calculate the final size of the text (which is the specified font size and the applied scale) and request a font of that computed size from the platform's font system. But if you request a font size of, say, 9 with a scale of 140%, the resulting font size of 12.6 doesn't explicitly exist in the font system, so the browser rounds the font size to 12 instead. This results in stair-step scaling of text.

But the geometricPrecision property—when fully supported by the rendering engine—lets you scale your text fluidly. For large scale factors, you might see less-than-beautiful text rendering, but the size is what you would expect—neither rounded up nor down to the nearest font size supported by Windows or Linux.

WebKit precisely applies the specified value, but Gecko treats the value the same as optimizeLegibility.

Note the weird space between "w" and "hiz" in "whiz", and in other places.

Can you specify the browser / OS / device ? I didn't see this exact behavior in any of the browser I've tested in.

Firefox + Linux KDE + Thinkpad (desktop)

Ok, thanks.

Updated my previous comment to include screenshots for Ubuntu (it seems, for this OS, Firefox also doesn't have any problems).

@espadrine @mathiasbynens just a heads-up (if you haven't notice already): <filter> doesn't work for most of the default Android browsers (personally, don't think this is a major issue, but I thought it would be best to point it out).

espadrine commented 10 years ago

Maybe I'm missing something (and I apologize for that), but isn't the font-size hard-coded into template.svg ?

Yes, that's correct. However, I am talking about the width of the text used, not the height. For instance, "dependencies" is something like thrice as wide as "build".

@espadrine @mathiasbynens just a heads-up (if you haven't notice already): doesn't work for most of the default Android browsers (personally, don't think this is a major issue, but I thought it would be best to point it out).

Good to know! So, that's also why it isn't blurry… All the better. Android updates are rarer than Chrome updates.

alrra commented 10 years ago

However, I am talking about the width of the text used, not the height.

Ok, I now understand what you where referring to.

On HEAD, we are computing that dynamically (using canvas). Is there a way to ensure that what is computed matches?

Don't think so.

Do note that: the result of node-canvas's measureText(text).width differs significantly from want browsers report. So, even now, you're not getting the same values as what you would get in browsers. Plus, to make things worse, different browsers report different values!

espadrine commented 10 years ago

A 10px difference is much bigger than I expected. I guess I didn't see it because both Firefox and node-canvas use the Cairo library as their backend.

I'm back to the drawing board. Might there be a way in SVG to force the rectangle to be of the size of a specified text?

espadrine commented 10 years ago

Closing because this repo is no longer the main one.