Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre
testcase is here:
It's not *required* to do anything. And we even document that it doesn't on Mac. But it does seem odd that it isn't on Windows. (It works on Linux.)
It does exactly what it says on the tin...
Whether you can see a significant visible effect is a different matter.
Created attachment 474591 [details]
screenshots, Fx 3.6 and current trunk in Win XP
This is a regression, I don't think it's intended.
e.g. 20px font has kerning and ligatures enabled, 19.9px font has not
(Testcase requires "DejaVu Serif" or "Constantia" font)
Is it related to DirectWrite being turned on?
j.j., what happens if you disable directwrite?
unrelated to directwrite
This is just the fact that Harfbuzz landed for Windows. We no longer have a shaping "fast path", we always use HB shaping. It's pretty fast, we didn't regress performance. Since there is no longer a special fast code path, optimizeSpeed no longer selects it.
Ok, this needs documentation then
1. it is impossible to disable inadequate ligatures on Windows, right?
2. the "browser.display.auto_quality_min_font_size" pref is useless on windows
Also, bug 463413 is fixed now?
(In reply to comment #9)
> Ok, this needs documentation then
> 1. it is impossible to disable inadequate ligatures on Windows, right?
You could specify
in CSS to disable default ligatures. Or use a font that doesn't have the ligatures!
> 2. the "browser.display.auto_quality_min_font_size" pref is useless on windows
I think it still has an effect on how glyph bounds are measured for drawing/refreshing the display, though you may not notice any visible difference.
> Also, bug 463413 is fixed now?
It should be, I believe (for Mac OS X and Windows), though I have not tested that particular font. (As suggested in comments there, it still represents a misuse of Unicode, though. Sinhala script should be encoded using the Sinhala block beginning at U+0D80, not Basic Latin characters.)
(In reply to comment #10)
> You could specify
> -moz-font-feature-settings: "liga=0"
oops... it was me who added "dev-doc-needed" keyword to bug 511339
(In reply to comment #8)
> This is just the fact that Harfbuzz landed for Windows. We no longer have a
> shaping "fast path", we always use HB shaping. It's pretty fast, we didn't
> regress performance. Since there is no longer a special fast code path,
> optimizeSpeed no longer selects it.
Actually, this change was made earlier as part of the font restructuring done to prepare for harfbuzz. When breaking up the text handling code into shapers, we explicitly enabled Uniscribe shaping by default, ignoring the text-rendering setting. Unfortunately, there are bugs with Uniscribe shaping on XP so our code is now somewhat convoluted:
So, on XP we'll pay attention to the text-rendering setting but ignore it on Vista/Win7. The text-rendering setting has always been ignored on OSX. Clear as mud? ;)
(In reply to comment #12)
> So, on XP we'll pay attention to the text-rendering setting
but there is no longer a visual difference in Gecko 2 on XP, right?
Given bug 463413 comment 17, is authoring "text-rendering" for HTML content useless at all now (on Mac, Windows, Linux soon)?
Or has "text-rendering" any visual effect in Gecko 2, on any platform, that is worth to document here:
geometricPrecision is still useful, it will turn off hinting (although we don't implement that yet)
So is it accurate to say that the documentation issue here is that optimizeSpeed no longer does anything because the normal font rendering code is fast enough that we do not (for now at least) have a faster code path?
I should add that I've updated the article here to say that, and if further changes are needed, point them out and re-tag this as doc needed (or make the changes for me and make me extra happy).
Looks great, thanks.