From Fedora Project Wiki
Comments
- there are a few typos, mostly lower/upper case letter ones
- I've updated a bit though, I'm not quite sure which one you were referring here. if it's still there, please let me know. --tagoh 10:42, 20 July 2012 (UTC)
- use Fedora 18 instead of f18, especially in Release Notes
- Updated. --tagoh 10:42, 20 July 2012 (UTC)
- provide more info for Contingency Plan/How To Test to include the metrics of the issues, the detailed how to test - with hints to recognize autohinting issues, also I'd pick a few prominent apps in different toolkits as a part of test coverage
- Well, it may not looks like an usual testing perhaps since it may depends on what one likes. for instance, see I've uploaded screenshots on http://tagoh.fedorapeople.org/tmp/hints/, the suffixed -hintfull.png is what we usually see on f17 etc. and -autohint.png is basically what this feature is proposing. as it mentioned in the bug, with auto-hinting, it looks naturally being rendered according to the pixel size. however I personally like no-auto-hinting behavior for smaller sizes. --tagoh 10:42, 20 July 2012 (UTC)
- the autohinting fix how-to should be moved from Release Notes to Detailed Description section as I'm not sure it should be a part of end-users Release Notes
- Updated. --tagoh 10:42, 20 July 2012 (UTC)
See my email, thank you, Jaroslav.
- Fonts with included hinting:
- "Although it's supposed to work better for most of fonts, there may be the case not working better, for instance, due to the own hinting data gives much better."
- If a font has its own hinting data, is it ever worse than the autohinter? Wouldn't it make sense (and would it be possible) to only enable autohinting for fonts that don't have their own hinting data? --Mitr 16:34, 20 July 2012 (UTC)
- For instance, Lohit fonts has already been using the autohinting, because of the poor rendering on the own hinting. so it's not that easy to figure out. --tagoh 04:08, 23 July 2012 (UTC)
- Looking at the pictures linked above, the hinting change has pretty visible impact on metrics. How does this affect layout compatibility for e.g. office documents? Better/worse/indeterminate? --Mitr 16:34, 20 July 2012 (UTC)
- Well, indeterminate. actually those screenshots has been taken on LibreOffice though, as you can see, how much it affects depends on fonts. for instance, the glyph widths are similar on DejaVu but a bit different on Liberation. --tagoh 04:08, 23 July 2012 (UTC)
- I don't understand this feature at all! Freetype already uses auto-hinting for fonts which do not provide hinting data, in fact that was one of the prerequisites for enabling the bytecode interpreter in Fedora, and I cherry-picked the relevant change from the huge Infinality patchset and got it upstreamed. Forcing auto-hinting for all fonts effectively means disabling the bytecode interpreter by default, which is surely not a good idea. --Kkofler 16:32, 24 July 2012 (UTC)
- Yes, I know. I'm rather thinking this feature as to improve our fonts packages to get more better rendering. honestly I don't think this feature will be done by changing it in fontconfig only. in fact it has both advantage and disadvantage. on some pixel size, BCI pretty works but on some pixel size, it doesn't. for another example, https://bugzilla.redhat.com/show_bug.cgi?id=842568. we need to optimize a lot. though we may revisit here to have another optimization with the sub-pixel hinting in the near future.
- Then what exactly is this feature about? As for the fonts which don't render correctly with the BCI (due to incomplete or bad hinting), I think the proper solution is to force autohinting instead of BCI hinting for those fonts only (as we have been doing since F15), not by default for all fonts. The BCI should be opt-out, not opt-in, unless the font does not provide any bytecode at all (case which is already handled by FreeType). --Kkofler 13:16, 25 July 2012 (UTC)
- because I'm assuming the fonts packages that is comfortable with auto-hinting is more than using hinting data in a font. if it's wrong, I'll just revert it. that's it. anyway, to figure it out, I'll prepare the comparison for the default fonts for languages at least. if it's worth go ahead, then publish the changes to the world. doesn't it make sense yet? as of now there are various opinions on the list though, how to measure, as nim-nim pointed out in the list, I don't like "sudden thickness jumps when moving from one size to another" behavior too on hinting data in a font. my goals to optimize is to reduce this behavior as far as possible and not break readability as well. I'd like to settle them. --tagoh 08:10, 26 July 2012 (UTC)
- Then what exactly is this feature about? As for the fonts which don't render correctly with the BCI (due to incomplete or bad hinting), I think the proper solution is to force autohinting instead of BCI hinting for those fonts only (as we have been doing since F15), not by default for all fonts. The BCI should be opt-out, not opt-in, unless the font does not provide any bytecode at all (case which is already handled by FreeType). --Kkofler 13:16, 25 July 2012 (UTC)
- Yes, I know. I'm rather thinking this feature as to improve our fonts packages to get more better rendering. honestly I don't think this feature will be done by changing it in fontconfig only. in fact it has both advantage and disadvantage. on some pixel size, BCI pretty works but on some pixel size, it doesn't. for another example, https://bugzilla.redhat.com/show_bug.cgi?id=842568. we need to optimize a lot. though we may revisit here to have another optimization with the sub-pixel hinting in the near future.