Created attachment 30368 [details] Comparisons for letter spacings before and after adjustment It appears to me that many kerning pairs in DejaVu Sans are a little bit overdone and make the spacing between letters uneven. This is particularly visible for pairs with T/V/R leading. I adjusted a number of pairs with fontforge, and the results seems to be a little better (see the attached screenshot). I am wondering if anyone want to take a look and see if this change is acceptable.
Created attachment 30369 [details] [review] svn diff output (modified with fontforge 20090916)
more kerning adjustments. New pairs include the following: YaYeYuYoYx WoWrWeWa Vu Screenshots before and after the adjustments are attached below.
Created attachment 30510 [details] Before (top) and after (bottom) adjustment for Y?, W? and V? Before (top) and after (bottom) adjustment; 10pt font rendering results are shown as insets.
Created attachment 30511 [details] accumulative svn diff for all kerning adjustments Here is the accumulative diff for all kerning adjustments. Because I am using a different version of fontforge, so, it seems only the diffs in the header section are related to this change, and others are most likely fontforge formatting variations.
I'm not really keen to modify kerning of the base glyphs, as this could too easily corrupt existing documents. We've always had this "policy" to not change the base glyphs. Sure, the kerning is quite a lot, but it looks like you're not using proper font hinting either but the freetype autohinter (although it's hard to tell, it could be the font hinting but then the subpixel hinting could cause this), which at those small font sizes apparently applies more kerning than the amount that's actually in the font. btw, to make patches, you have to do "make pre-patch" first to get all the garbage out of the diffs. Check http://dejavu-fonts.org/wiki/index.php?title=Developer's_Corner for details.
Created attachment 30534 [details] [review] kerning adjustment patch (In reply to comment #5) > I'm not really keen to modify kerning of the base glyphs, as this could too > easily corrupt existing documents. We've always had this "policy" to not change > the base glyphs. DejaVu sans is the most widely used screen font in FOSS desktops. I think it is more important to keep its fitness for its primary use (screen display) than to concern the consistency in documents. This is indeed a long standing issue and you can find a number of reports in the opened bugs: https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=DejaVu&content= > > Sure, the kerning is quite a lot, but it looks like you're not using proper > font hinting either but the freetype autohinter (although it's hard to tell, it > could be the font hinting but then the subpixel hinting could cause this), > which at those small font sizes apparently applies more kerning than the amount > that's actually in the font. I am pretty sure this visual defect is largely caused by the fact that the kerning is too close. As you can see from the large-size characters in the previous screenshots, the letter spacing is not uniform even in large sizes. > > btw, to make patches, you have to do "make pre-patch" first to get all the > garbage out of the diffs. > Check http://dejavu-fonts.org/wiki/index.php?title=Developer's_Corner for > details. > A cleaner patch is attached. Please let me know how this looks to you.
(In reply to comment #6) > DejaVu sans is the most widely used screen font in FOSS desktops. I think it is > more important to keep its fitness for its primary use (screen display) than to > concern the consistency in documents. This is indeed a long standing issue and > you can find a number of reports in the opened bugs: We know that we're a screen font, and we've never pretended to be a good document font. However, since we are the default on most Linux distros, you get DejaVu by default if you make a document and don't bother to change the font. Therefore I consider the amount of documents made with DejaVu big enough to not ignore. But I'm just saying here that changing base glyphs is not something we do lightly. I think the number of times we've edited a base glyph in DejaVu until now in a way that made a visual effect can be counted on one hand. And probably all of those changes was to fix a real error. And they all were done after discussion. So that means that this will also have a lot of discussion first before thinking about putting it in DejaVu.
(In reply to comment #7) > We know that we're a screen font, and we've never pretended to be a good > document font. However, since we are the default on most Linux distros, you get > DejaVu by default if you make a document and don't bother to change the font. > Therefore I consider the amount of documents made with DejaVu big enough to not > ignore. > > > But I'm just saying here that changing base glyphs is not something we do > lightly. I think the number of times we've edited a base glyph in DejaVu until > now in a way that made a visual effect can be counted on one hand. And probably > all of those changes was to fix a real error. And they all were done after > discussion. > > So that means that this will also have a lot of discussion first before > thinking about putting it in DejaVu. > I totally agree with you. I've sent emails to dejavu-fonts list (which you may have already noticed), if there are other ways to attract more discussions on this issue, please let me know, or feel free to forward.
Closely related kerning issues, some of which are duplicates: https://bugs.freedesktop.org/show_bug.cgi?id=7450 (If there's a better way to link a bug, I apologize.)
(In reply to comment #9) > Closely related kerning issues, some of which are duplicates: > https://bugs.freedesktop.org/show_bug.cgi?id=7450 > (If there's a better way to link a bug, I apologize.) > Since Bug#7450 contains a subset of the pairs. I prefer to mark #7450 as a duplicate of this bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.