Description of problem: Bitstream Vera fonts doesnt seem to have got much attention after being open sourced. Dejavu which is a unified colloborative fork of the font under the same license has been steadily accumulating improvements Actual results: Bitstream Vera fonts is include in Fedora Core and Dejavu is in Fedora Extras repository Expected results: Replace Bitstream Vera in core with Dejavu Additional info: http://dejavu.sourceforge.net/wiki/index.php/ http://dejavu.sourceforge.net/wiki/index.php/Current_status
Bug #166536 is an example where Bitstream fails us. Is Dejavu afflicted by similar problems?
Warren, I am working remotely for a while and I wouldnt be able to check this for quite sometime. Dejavu-fonts is in Fedora Extras if you would like to check out Thanks
I second this proposal, the cyrillic support we need for sr_CS in the Bitstream family is seriously incomplete, DejaVu works much better for us.
warren: re #1 this would be worked around in OOo 2.0.2 itself with some fake italic support, but these fonts appear to have native oblique fonts anyway. caolanm->mclasen: Presumably if these fonts are to replace the Bitstream ones we'd need fontconfig aliases from the old fonts to the new names of these fonts.
There may be some issues between Firefox, recent Pango and Dejavu, see http://bugzilla.gnome.org/show_bug.cgi?id=327907
Hmm, I don't really want to get into a font fight a week before test3, perhaps we'll punt this to fc6.
(In reply to comment #7) > Hmm, I don't really want to get into a font fight a week before test3, perhaps > we'll punt this to fc6. If this is a intrusive change, then I agree that its better to punt it.
dejavu-fonts >= 2.3.0 has also great greek language support. The current situation for a default Fedora install is dissapointing, without installing dejavu-fonts and/or mgopen-fonts from Extras.
before putting dejavu in FC (not sure it's a good idea, FC won't follow the monthly dejavu updates) changing its priority is probably a low-hanging fruit
*** Bug 158032 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > There may be some issues between Firefox, recent Pango and Dejavu, see > http://bugzilla.gnome.org/show_bug.cgi?id=327907 If the problem is dejavu-side report it to the dejavu project and they'll fix it. Speaking from experience they've been incredibly responsive so far (typically putting fixes in their monthly update or the one after) None of the reporters on http://bugzilla.gnome.org/show_bug.cgi?id=327907 seems to think the problem is dejavu side, and none of them even suggested bringing to the dejavu project attention. (This is not and argument to pull dejavu in core BTW, dejavu is nice because it's evolving so fast, and putting it in core would freeze the Fedora version for a full Fedora release cycle. This however is an argument to make its priority higher in fontconfig)
>putting it in core would freeze the Fedora version for a full Fedora release cycle Not necessarily, for example we did get KDE 3.5 pushed for FC4. :-)
(In reply to comment #13) > >putting it in core would freeze the Fedora version for a full Fedora release > cycle > > Not necessarily, for example we did get KDE 3.5 pushed for FC4. :-) I'm not sure monthly updates are OK with core, and that's what dejavu requires Plus right now dejavu needs fontforge as BR. Moving to binary dumps would a severe regression - what's the point of clamoring for FOSS if we don't build from source ourselves ?
fontforge *and* perl-Font-TTF - don't remember my own specs anymore, time to go Zzzzz
'Requires' monthly updates sounds awfully strong - surely it just means you won't get any new characters, corerct? Much like how not updating any other package works.
The "problem" is the dejavu team is churning new/fixed glyphs at an astonishing rate, and there is always someone to kindly remind you he needs the last version if you didn't push a new package in the week following an upstream release. People are incredibly frustrated by the current font state, they tick days on the calendar waiting for the next upstream release. They scour the net for other Vera forks and report them for merging if they include some better/missing glyphs. Other distributions are also feeling the heat - you can check easily all the major ones have to sport the latest or next-to-latest dejavu release
As you can see on http://dejavu.sourceforge.net/wiki/index.php/News the change rate is increasing, not stalling at all
(In reply to comment #18) > As you can see on > http://dejavu.sourceforge.net/wiki/index.php/News > > the change rate is increasing, not stalling at all What I see is that the basic glyphs for Western European, Central European, Cyrillic and Greek are already there and are stable. The glyphs that are being added now are non-common and the aim is to fill in the Unicode blocks as listed at http://www.unicode.org/charts/ From the above URL you can see that either historical glyphs or glyphs in cyrillic extended are being updated.
Also note that Ubuntu Dapper is now setting DejaVu as higher-priority over Bitstream Vera, and there is some additional rationale in: http://launchpad.net/malone/bugs/12016
(In reply to comment #19) > What I see is that the basic glyphs for Western European, Central European, > Cyrillic and Greek are already there and are stable. They're here, they're good but are they stable ? People are still requesting fixes (not because they're bad but because they could be better -> cyrillic style os closer to serbian uses than russian uses, etc) Also I don't think it's nice to freeze the font just because the particular needs of one user group are fullfiled. What if they had been frozen before greek had been completed. Would this have made you happy ? I say as long as new glyphs are being added there are people which need them and filtering changes is doing them a disservice. Especially since rebuilding the package every month is rather trivial (but not consistent with FC habits) I'm perfectly fine with dejavu ending in FC *if* it means the quality of the packaging does not drop (release rates, rebuilding from sfds). Especially since that would make less work for me. But if the end-result is worse than now I don't really see the point (FC6 is supposed to make FC and FE equals) Upping the dejavu prio OTOH is a very good not invasive thing. If Red Hat stalls there I know how to do it safely within dejavu BTW (triggers + xslt)
I've pushed package that does fontconfig reg in devel : http://buildsys.fedoraproject.org/logs/fedora-development-extras/5829-dejavu-fonts-2.3-2.fc5/
This contradicts yourself from some time ago: http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00887.html You have added +# Needed for fontconfig alias registration +Requires: %{_bindir}/xsltproc, /bin/mktemp (and also forgot fontconfig as a Require) Now dejavu-fonts is in the unique position not only to require fontconfig, but also a couple of xml libraries. I think what you are trying to do is changing Core's behavior from within an Extras package. This is best done within Core with a simple edit of fonts.conf (as an example Fedora Core does not ship Times New Roman or Arial, yet these font preferences are included in fonts.conf). Please keep your package as clean as possible.
quite a lot of noise.
(In reply to comment #24) > This contradicts yourself from some time ago: > http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00887.html > > You have added > > +# Needed for fontconfig alias registration > +Requires: %{_bindir}/xsltproc, /bin/mktemp > > (and also forgot fontconfig as a Require) 1. fontconfig is not a require. Nothing bad will happen if it's not there 2. I need to check if xsltproc and mktemp are in default install (mktemp probably), and add some conditions if needed. Right now I spent more time getting a safe transform than worrying about its requirements > I think what you are trying to do is changing > Core's behavior from within an Extras package. sure > This is best done within Core with a simple edit of fonts.conf There is a reason this change is pushed to devel only. It's pretty much an experiment and probably needs a little more work (on the requires front) The change is more than safe and at least it will give us a little more visibility on what it would mean to have DejaVu in fontconfig aliases.
(In reply to comment #26) > 1. fontconfig is not a require. Nothing bad will happen if it's not there > 2. I need to check if xsltproc and mktemp are in default install (mktemp > probably), and add some conditions if needed. Right now I spent more time > getting a safe transform than worrying about its requirements You are correct here, but the requirement of xlstproc is bogus if fontconfig is not there. > The change is more than safe and at least it will give us a little more > visibility on what it would mean to have DejaVu in fontconfig aliases. Just had another look at your patch at the specfile, and it introduces a trigger. +%triggerin -- fontconfig, %{_sysconfdir}/fonts/fonts.conf I admit not knowing much about the trigger mechanism, but I thought the consensus was that they were considered harmful. See for example: http://www.redhat.com/archives/fedora-extras-list/2005-May/msg00337.html for an opinion. (OK, this is getting out of scope for this bug, will continue in extras list if necessary).
(In reply to comment #27) > Just had another look at your patch at the specfile, and it introduces a trigger. > > +%triggerin -- fontconfig, %{_sysconfdir}/fonts/fonts.conf > > I admit not knowing much about the trigger mechanism, but I thought the > consensus was that they were considered harmful. Triggers are dangerous if you don't understand their scope. This is why the fonts.conf munging is done in xslt which lots of defensive programming conditions to keep the trigger safe
(In reply to comment #27) > (In reply to comment #26) > > > 1. fontconfig is not a require. Nothing bad will happen if it's not there > > 2. I need to check if xsltproc and mktemp are in default install (mktemp > > probably), and add some conditions if needed. Right now I spent more time > > getting a safe transform than worrying about its requirements > > You are correct here, but the requirement of xlstproc is bogus if fontconfig is > not there. > Kindly avoid reviewing package specifications in this RFE. Keep discussions on the list and focus on only providing information that helps make a discussion in support of or against the RFE as specified in the topic. Thanks.
DejaVu 2.3 Coverage: http://svn.sourceforge.net/viewcvs.cgi/*checkout*/dejavu/tags/version_2_3/dejavu-fonts/unicover.txt?rev=574 (In general, see http://dejavu.sourceforge.net/wiki/index.php/Current_status). Fragment of the unicode coverage file: Sans Serif Sans Mono U+0000 Basic Latin 100% (95/95) 100% (95/95) 100% (95/95) U+0080 Latin-1 Supplement 100% (96/96) 100% (96/96) 100% (96/96) U+0100 Latin Extended-A 100% (128/128) 100% (128/128) 100% (128/128) U+0180 Latin Extended-B 64% (126/194) 58% (113/194) 58% (113/194) U+0250 IPA Extensions 100% (96/96) 100% (96/96) 100% (96/96) U+0370 Greek and Coptic 88% (110/124) 88% (110/124) 88% (110/124) U+0400 Cyrillic 77% (193/248) 48% (120/248) 46% (116/248) U+2580 Block Elements 100% (32/32) 100% (32/32) 100% (32/32) U+25a0 Geometric Shapes 100% (96/96) 100% (96/96) 100% (96/96) a. Basic Latin, Latin 1 Sup, Latin Extended-A are fully covered. Most of Latin Extended-B is covered as well. All this includes almost all languages that are based on the Latin script. b. Greek is full covered. Some glyphs are missing for Coptic; Coptic is used in liturgy in Egypt and afaik, has no extensive use in Linux yet. In addition, Coptic is nowdays covered in a separate block (not together anymore with Greek), starting at U+2c80. c. Most of Cyrillic is covered (this includes the Russian alphabet and other cyrillic characters found in other cyrillic-based alphabets. It is important to note that without DejaVu, characters not found in Vera are rendered from FreeFont which shows differently. As Vera has limited coverage, many languages are affected (Greek, Central European, Cyrillic). With DejaVu, text containing Latin, Central European (=Latin Extended), Greek or Cyrillic appear more uniform and characters do not stand out. Without DejaVu, Greek appears really ugly in Fedora Core 5.
(In reply to comment #30) > DejaVu 2.3 Coverage: ... Please relember some of the listed glyphs are a work in progress > Without DejaVu, Greek appears really ugly in Fedora Core 5. Sure, but do think about other users. If DejaVu had been frozen in FC4 you would still have no support in Fedora (FC-4 would have had dejavu 1.10 at best). Freezing it now your langage is supported is rather selfish.
Please excuse me because I know nothing about the development of fonts, but I am curious. It is necessary to freeze the version of a font forever because some future version may improve other language glyphs, but will cause regressions on previously supported languages?
I don't know where all this talk of freezing comes from. The reason for moving dejavu into core is to have better coverage in the default installation. If new versions of dejavu appear during the lifetime of fc5, which further improve the coverage, it would only be natural to update dejavu. Of course, not having controversial packaging tricks like triggers to thing about makes such an upgrade much more likely to happen. If don't think if there is precent for mentioning non-core fonts in the fontconfig configuration, but I would have no problem putting dejavu before bitstream vera if it allows us to avoid ugly trigger tricks in dejavu...
(In reply to comment #31) > > DejaVu 2.3 Coverage: > ... > > Without DejaVu, Greek appears really ugly in Fedora Core 5. > > Sure, but do think about other users. If DejaVu had been frozen in FC4 you > would still have no support in Fedora (FC-4 would have had dejavu 1.10 at > best) And for people not following the DejaVu project here is what the font coverage was one FC release ago (DejaVu 1.10): U+0000 Basic Latin 100% (95/95) U+0080 Latin-1 Supplement 100% (96/96) U+0100 Latin Extended-A 80% (103/128) U+0180 Latin Extended-B 12% (25/208) U+02b0 Spacing Modifier Letters 11% (9/80) U+0300 Combining Diacritical Marks 0% (1/112) U+0370 Greek and Coptic 1% (2/144) U+0400 Cyrillic 37% (96/256) U+fb00 Alphabetic Presentation Forms 2% (2/80) > Freezing it now your langage is supported is rather selfish. I fully expect DejaVu to win Thai, Vietnamese and fix Cyrillic before FC-6 > (In reply to comment #32) > It is necessary to freeze the version of a font forever because some > future version may improve other language glyphs, but will cause regressions > on previously supported languages? Warren, the problem is not regressions - DejaVu as a rule improves from release to release. The problem is to link the font package release to the FC release cycle, when upstream is very dynamic and introduces fixes/enhancements/new glyphs every month. Of course if you're in a region that is already covered by DejaVu moving the font from FE to FC is a net win. But for people waiting for the next DejaVu release that means they have to wait 6/9 months instead of 1 month before the font coverage includes their langage. I'm perfectly fine with moving DejaVu from FC to FE if the FC maintainer understands he needs to follow upstream releases. But if he does not intend to continue the current release speed I'd rather have the package stay in FE. > (In reply to comment #33) > If don't think if there is precent for mentioning non-core fonts in the > fontconfig configuration, mgopen is in the fontconfig conf and it's not in core > but I would have no problem putting dejavu before bitstream vera if it allows > us to avoid ugly trigger tricks in dejavu... 1. you don't need to put dejavu before vera - dejavu includes vera unchanged so it can perfectly be put after vera 2. however you do need to put it before the fonts that follow vera 3. and since the vera prio is not too high upping the vera/dejavu prio would do no harm 3. the uggly trigger was in FE dejavu proper for ~ 1 day - I've pushed it to a subpackge 4. it was ugly mainly because we don't have an XSLT engine in the core install - maybe it's time to recognize XML is not a fringe langage anymore?
Note that adding Thai to Deja Vu (as opposed to a companion font) will likely break everyhing because Thai requires radically different line spacing. But then again, the Deja Vu maintainers will presumably find that out in practice when they try it... Not actually looking at the what the subpackage is doing: Editing fonts.conf in %pre/%post (or a trigger!) is ugly no matter what technology is used ... XSLT doesn't seem noteably better than sed/perl/python/whatever in the end. The aggregate opinion of triggers that I've got from watching Red Hat development for 8 years can be summed up as "triggers are the devil incarnate" Even triggers that were used as a last resort when no other solution seemed possible have usually ended up causing significant grief down the road. If an addition to fonts.conf can avoid that, it seems like a good idea to me. There's actually quite a bit in fontconfig not in core ... usually because it's in the upstream configuration. It seems to me that the right place to add "Deja Vu" is immediately before or after where the Vera fonts are currently (*). The only reason to do any reordering would be to make sure that the Deja Vu preceeds the CJK fonts, since those have broken greek glyphs, but that's already true for the Vera fonts, which are high up in the various aliases. In terms of FC vs. Extras I don't see that fonts are any different then any other package that has upstream releases... (*) Generally I think before is better ... otherwise you might have multiple fonts being loaded and switched between for no reason. I guess the reason for putting them after would be if there was a worry that the user might have a buggy copy of Deja Vu on their system.
> I'm perfectly fine with moving DejaVu from FC to FE if the FC maintainer > understands he needs to follow upstream releases. But if he does not intend to > continue the current release speed I'd rather have the package stay in FE. As long as dejavu's development process ensures no regressions and we have adequate testing to ensure this, then it is possible that FC can both incorporate dejavu and occasionally upgrade it during the months after a FC release. This may be a good way to leverage the updates/testing repository until everyone is sure it wont break anything, then push it as a real update. It all depends on the details when we get there. And yes, please avoid triggers at all costs.
> I'm perfectly fine with moving DejaVu from FC to FE if the FC maintainer > understands he needs to follow upstream releases. But if he does not intend to > continue the current release speed I'd rather have the package stay in FE. From what Nicolas has said, I do not see this as a stable font to be included in FC yet. At the moment, we propose fontconfig is going to be updated (definitely not for gold, maybe in update) and Deja Vu is added into fontconfig conf, before Bitstream Vera, then I think users can just install FE packages if they choose to, and have it effectively preferred and used by default than Bitstream Vera - which sounds like a better way for this until the fonts get stable.
> At the moment, we propose fontconfig is going to be updated (definitely not for > gold, maybe in update) and Deja Vu is added into fontconfig conf, before > Bitstream Vera, then I think users can just install FE packages if they choose > to, and have it effectively preferred and used by default than Bitstream Vera - > which sounds like a better way for this until the fonts get stable. The fonts are stable but the pace of development is fast just like lets say the Linux kernel. If we are going to wait for it to mature and to slow down, that may effectively never happen. Clearly there is momentum being this font and thats a good thing since we get a lot better out of the box coverage. If we include it in FC and there are new releases with significant advantages and less chances of regression, the maintainer needs to just track that and provide the new releases as updates within the same release. If there are potential regressions, use the updates-testing repository and request help with testing citing the advantages in fedora-test, fedora-devel lists, blogs and what not. Obviously the spec file in the FE package might need to be cleaned up but thats a different discussion.
Regarding the existence of triggers to edit fonts.conf: As far as I understand, the installation package of a font does not and should not touch /etc/fonts/fonts.conf. The contents of /etc/fonts/fonts.conf is the sole responsibility of the fontconfig package. If someone wants to add a fonts in fonts.conf, they do it at bugzilla.freedesktop.org, product fontconfig. That's how we added MgOpen, just over the CJK fonts. Are we happy with the current CVS version of fonts.conf.in? If not, Fedora keeps and distributes a custom version, suitable for the release. That's how they do it with Ubuntu. In other words, no need for trigger or xslt dependancy. "fonts.conf" can and does include fonts that you will never see installed on your system. If such a font is enountered, fontconfig simply ingores it. Therefore, the strategy is to set a proper fonts.conf file (fontconfig package responsibility) and then add specific fonts to have installed by default on the system. OpenOffice.org has a separate file with fonts preferences, VCL.xcu. No font installation package touches this file, it's up to the OpenOffice.org package's responsibility what to put in there. Rahul mentions that the pace of development of DejaVu is fast and that we should wait for it to stabilise. I personally think that the suggested metrics are not suitable here. Vera is stabilised because the font designer decided not to add central european/greek/cyrillic glyphs at the moment (they are expected some time in the future) and I do not know if there is any way to send suggestions to enhance existing glyphs. As I mentioned above, the development of DejaVu is focused on increasing the coverage, with the addition of glyphs in more uncommon Unicode blocks. The fast pace of development is an advantage for DejaVu.
> Rahul mentions that the pace of development of DejaVu is fast and that we should > wait for it to stabilise. I personally think that the suggested metrics are not > suitable here. No. I didnt say that. Remember that I filed the RFE in the first place. > The fast pace of development is an advantage for DejaVu. Right.
Sorry Rahul, my comment about the pace of development/"freezing the fonts" was on Nicolas.
(In reply to comment #41) > Sorry Rahul, my comment about the pace of development/"freezing the fonts" was > on Nicolas. I didn't write we should wait for it to stabilize either. I wrote that unlike Vera, DejaVu is bringing valuable enhancements every months, and whoever takes DejaVu maintenance @rh must be ready to follow upstream changes (at least in rawhide) People have asked about regressions - DejaVu has no concept of stable/instable, it's a work in progress and one reason it works is if someone notices a regression he can report it and it'll be fixed by next release (a month later). A dynamic which will obviously not work if package releases do not occur shortly after upstream releases, and if some upstream releases are skipped (who will judge what upstream release is worthy and how?) Also, the current Vera prio is a distribution choice, and it's based in part on its glyph coverage, so I doubt any upstream-fontconfig-level change would apply as-is in this particular case
(In reply to comment #42) > (In reply to comment #41) > > Sorry Rahul, my comment about the pace of development/"freezing the fonts" was > > on Nicolas. > > I didn't write we should wait for it to stabilize either. > I wrote that unlike Vera, DejaVu is bringing valuable enhancements every months, > and whoever takes DejaVu maintenance @rh must be ready to follow upstream > changes (at least in rawhide) Like the Linux kernel, Fedora picks a specific version and keeps that for the duration of the distro version. There might be updates to solve significant problems, however there is generally no update to a new kernel version. > People have asked about regressions - DejaVu has no concept of stable/instable, > it's a work in progress and one reason it works is if someone notices a > regression he can report it and it'll be fixed by next release (a month later). The stable release is the one you can download from the Website (now it's 2.3). If you want to view the bleeding edge work, you can download from SNV and build the font yourself. There is a release candidate period before the final release. The release candidate is a full package with TTF fonts that one can easily try. See Management Notes at http://dejavu.sourceforge.net/wiki/index.php/Developer%27s_Corner > A dynamic which will obviously not work if package releases do not occur shortly > after upstream releases, and if some upstream releases are skipped (who will > judge what upstream release is worthy and how?) You deem a font "complete" when it fully covers the needs of certain languages you want to support; it has the necessary glyphs. For example, you would not want a font that has 10 glyphs of a 24 letter alphabet (for example, Doulos SIL has glyphs for a few Greek characters). You also deem a font "complete" if the representation of glyphs is generally acceptable by the audience of the specific languages it is about to support. For example, I can vouch for Greek that DejaVu 2.3 is acceptable. > Also, the current Vera prio is a distribution choice, and it's based in part on > its glyph coverage, so I doubt any upstream-fontconfig-level change would apply > as-is in this particular case I do not understand this point. Vera has the three common faces, Sans, Serif and Mono, it supports Western languages (the major audience) and has a free license. The coverage of Vera is limited. fonts.conf got Vera in it quite early, and due to the Vera publicity, it trickled down to the distributions quite fast.
> Like the Linux kernel, Fedora picks a specific version and keeps that for the > duration of the distro version. There might be updates to solve significant > problems, however there is generally no update to a new kernel version. This is untrue. Fedora Updates regularly upgrades to newer upstream kernel versions.
*** Bug 183457 has been marked as a duplicate of this bug. ***
Reassignment to the new package maintainer - Mayank.
i tried dejavu from extras with a fresh install of FC5. If user keeps unchanged the font preferences, then Greek letter pi (Ï) is displayed by Bitstream Vera's pi and not by dejavu's pi. This has to be a fontconfig issue? Also in English character set, letter "T" is diplayed not so properly. If there is a word like "Trash" i see "r" to be too close with "T", this is also the case for English letter "Y".
Created attachment 126977 [details] English letter T and Y congestion with other characters
The kerning issues have been extensively discussed upstream, see http://bugzilla.gnome.org/show_bug.cgi?id=334758
This case of specific letters being too close together is a "kerning" issue that has gone bad, probably due to a bug in Pango. A new test version of DejaVu has been released that provides a workaround and a stable version is expected to come in mid-April. For more on Kerning, see http://en.wikipedia.org/wiki/Kerning The DejaVu mailing list archives is http://lists.sourceforge.net/lists/listinfo/dejavu-fonts
Please do not pollute this bug with the kerning issues. 1. they're handled in bug 186662 2. upstream has released a version that workarounds the pango limitations, and it would already be in FE if FE cvs was working
Nicolas, Are you eventually packaging DejaVu 2.4.1 for Fedora Extras or are you waiting for 2.5 to be released in mid-April?
As I've just written, the packaging is already done (was done when Ben Laenen release 2.4.1 and re-done when he re-released it) but the FE buildsystem/CVS has been dead for a few days
*** Bug 140504 has been marked as a duplicate of this bug. ***
You might want to consider packaging and using DejaVu LGC as a default instead of Bitstream Vera. I'm saying DejaVu LGC because the Arabic in DejaVu Sans is currently not approriate for heavy screen use with Arabic script. The Arabic characters need hinting, kerning and other adjustments. DejaVu LGC Sans is the same font as DejaVu Sans, without Arabic. Besides additions to Bistream Vera, DejaVu also sports a few improvements such as better umlauts in Sans at small sizes
FC6 test1 is scheduled to be released this month. The development freeze is June 14th. Is it possible to get DejaVu installed as the default font (default installation, default font due to /etc/fonts/fonts.conf) in this test release? If there are any unmet requirements/requests towards DejaVu, could you please list them? Ubuntu Linux has been released on 1st June (defaults to DejaVu) and we are following closely any reports on the issue of the fonts at https://launchpad.net/people/dejavu+fonts
Where is this DejaVu LGC located? Is it a fork to DejaVu Sans? There may be more problems like this where this is the highest in the order of fonts.conf and it overrides another fonts with better glyphs on scripts. (In reply to comment #55) > You might want to consider packaging and using DejaVu LGC as a default instead > of Bitstream Vera. I'm saying DejaVu LGC because the Arabic in DejaVu Sans is > currently not approriate for heavy screen use with Arabic script. The Arabic > characters need hinting, kerning and other adjustments. DejaVu LGC Sans is the > same font as DejaVu Sans, without Arabic. > > Besides additions to Bistream Vera, DejaVu also sports a few improvements such > as better umlauts in Sans at small sizes
(In reply to comment #61) > Where is this DejaVu LGC located? Is it a fork to DejaVu Sans? There may be more > problems like this where this is the highest in the order of fonts.conf and it > overrides another fonts with better glyphs on scripts. DejaVu LGC is just another way to build DejaVu that will strip some ranges of glyphs from the result. I'm not building it in the Fedora Extras package now because the build scripts do not make it easy to build both DejaVu and DejaVu LGC (the LGC upstream build path is clearly a quick and dirty hack), and I personnaly think DejaVu LGC is a mistake. IMHO with monthly releases and responsive glyph authors if you find some glyphs are suboptimal you just have to open a bug and wait till the next release for it to be fixed. The only scenario where DejaVu can not be "fixed" is when some glyphs are shared by several scripts which have slightly differing drawing conventions (for example arabic and persian). FOSS font tools just can't cope with this scenario right now so you have to manually put the font with the variant you need most first in the fontconfig substitution table. There is nothing font authors can do till the font tools are made smarter (unfortunately after forcefully making the DejaVu authors aware of this fact the Pango authors didn't lobby hard enough for the corresponding SoC projects, and Google scrapped them). And of course it's a mistake in the unicode spec in the first place. You can check on http://www.fileformat.info/info/unicode/font/index.htm the DejaVu glyph coverage is quickly approaching the coverage of the standard java fonts, for example. And unlike other font project the wide coverage is not achieved by sacrificing quality : even glyphs which have been in the font a long time are being reworked if the authors do not feel they are good enough yet. And they are all progressively hinted.
The DejaVu LGC is available at http://dejavu.sourceforge.net/wiki/index.php/Download At the moment fonts can be designed with the required feature for localized glyphs, the problem is that very few (if not none) of the font shapers can use that feature. Pango is still the best option we have to use that feature, all we have to do is submit good patches :D The other feature we could seriously use is the BASE table, which would allow different metrics for different scripts or even languages.
I think that in any case, there will be a general issue that the coverage of one font conflicts with that of another. Therefore, in the preference list in /etc/fonts/fonts.conf, one font will inevitable mask another. This issue can be controlled at the fontconfig level, by adding special instructions in fonts.conf: http://mail.gnome.org/archives/gtk-i18n-list/2006-March/msg00044.html ("for language LL, please ignore font FFFF"). This becomes more important when Arabic and Persian is involved. Both share the Arabic script, thought the style of the glyph each audience expects is different. What I see as the important question is, - Are there any users that would really benefit from Arabic in DejaVu? - If not, remove Arabic. - If yes, keep Arabic and figure out a better fonts.conf or use custom fonts.conf files.
CC'ing behdad, as the future owner of this problem complex.
DejaVu Sans is very annoying for Arabic/Persian users, and I don't see why we should go out of our way to ensure that the Arabic in DejaVu Sans never shows up on screen. If DejaVu's goal is to cover all Unicode, I'm against putting it in Core. If there's a DejaVu LGC that is maintained by upstream, I'm all for it. But like others, I think we need a lot of testing before pushing every version of DejaVu in. I've seen just too much bug reports in Pango with DejaVu fonts.
(In reply to comment #66) > DejaVu Sans is very annoying for Arabic/Persian users, and I don't see why we > should go out of our way to ensure that the Arabic in DejaVu Sans never shows up > on screen. You'll have the very same problem with *any* arabic font higher in the substitution table than your persian fonts. Does this mean Fedora should not ship arabic fonts? The project is ready to draw arabic *and* persian variants of these glyphs. Right now glyph selection *will* mean some obscure fontconfig magic, but that's hardly the fault of this particular font. As for the bugs they are getting fixed as fast as they're reported upstream (unlike other software Fedora does ship), provided they're actually bugs in the font itself (and not in the system font infrastructure, as is unfortunately often the case). And even when the bugs are not on the font side workarounds are implemented when they can sanely be (not covering one unicode block is not an acceptable workaround, as I'm sure you realise)
Even better just give me the fontconfig block that's needed to blacklist the glyph range which annoys persian users and I'll release a dejavu-fonts-behdad which inserts it automagically in fonts.conf while this package is installed. I know the packaging side well enough to do it safely. What I *don't* know is the fontconfig magic you need
<match> <test name="lang"> <string>fa</string> </test> <selectfont> <rejectfont> <pattern> <patelt name="family"><string>DejaVu</string></patelt> </pattern> </rejectfont> </selectfont> <edit name="family" mode="prepend" binding="same"> <string>SomeOtherFontThatSupportsBetterPersian</string> </edit> </match> I did not test the above. Would this ignore a font in preference of another font for a specific language? (Reference: Behdad's replies from http://mail.gnome.org/archives/gtk-i18n-list/2006-March/thread.html#00011) It would be good to use a mechanism like above until the system font infrastructure supports those OpenType features of language selection. As far as I know, the default font in Fedora currently is Luxi, covered by the license http://www.xfree86.org/current/LICENSE11.html#34 which states "The Font Software may not be modified, altered, or added to, and in particular the designs of glyphs or characters in the Fonts may not be modified nor may additional glyphs or characters be added to the Fonts. This License becomes null and void when the Fonts or Font Software have been modified.", which would not allow to add more glyphs to them. The default font discussion in Fedora first took place in 2003, when Bitstream Vera was introduced, http://www.redhat.com/archives/fedora-desktop-list/2003-December/msg00056.html If the Arabic coverage in DejaVu is unsuitable for any Arabic-based language audience, please say so.
Nicolas The right question to answer is why should Fedora prefer DejaVu Sans over DejaVu LGC? With the poor quality of the Arabic glyphs, I see no reason. And no, it's not just about me. I don't know any Persian or Arabic users that uses or likes DejaVu's Arabic glyphs, but I know several who don't like it. Another question is: why do you ask DejaVu's Arabic glyphs are good? If you want to put Arabic glyphs in (that I'm hardly agaist, but still) go get the ones from FarsiWeb. The license shouldn't be a problem. As for mixing all scripts into one font, Owen Taylor doesn't like that approach, and I don't either. So I'm quite sure that we don't want to go that way in Fedora.
(In reply to comment #70) > Nicolas > > The right question to answer is why should Fedora prefer DejaVu Sans over DejaVu > LGC? With the poor quality of the Arabic glyphs, I see no reason. Because the "poor quality of the Arabic glyphs" is a transient state, and I'm convinced they will get better as the other blocks did. Before greek for example became so good greek users started lobbying forcibly for dejavu, it was poor and incomplete, the difference being some greek users spend the necessary time to report why it was poor and incomplete, and now as you can see they are quite happy with the result. > And no, it's not just about me. I don't know any Persian or Arabic users that > uses or likes DejaVu's Arabic glyphs, but I know several who don't like it. So they just have to say why they don't like it and it will get better. Just like cyrillic is getting better by little touches every release. The *huge* difference between dejavu and other font projects is the designers do listen to users and do correct mistakes in a timely manner when they are reported. Look at the changelog. A short while ago (in distro terms) dejavu was little more than vera. Today they don't compare anymore. > Another question is: why do you ask DejaVu's Arabic glyphs are good? If you > want to put Arabic glyphs in (that I'm hardly agaist, but still) go get the ones > from FarsiWeb. The license shouldn't be a problem. If the licensing and the style (line widths...) is compatible this may happen. If they are not - it won't. This is not a project which achieves coverage by mashing up hugely dissimilar fonts. > As for mixing all scripts into one font, Owen Taylor doesn't like that approach, > and I don't either. So I'm quite sure that we don't want to go that way in Fedora. I'll just write here once and for all that the quest to get Vera for Gnome was long and difficult, getting Vera fixed afterwards has proved impossible, and in these conditions making life harder for the one project that succeeded beyond our wildest hopes (both in openess and dynamic) is downright silly. Dejavu may be a pain to support in Fedora/Pango but it's also a golden opportunity, a small project is a fragile thing, if you smother them today you won't find any replacements tomorrow when you will have support for complex fonts. I didn't notice you or Owen pointing up another project which was achieving the glyph coverage Fedora users need in the "right way". Dejavu is miles ahead of what Fedora ships now (licensing, quality, responsiveness). Like any real-world solution, it's not a perfect solution. But who would say today getting Firefox in Fedora (despite its numerous and well-known-problems) and not waiting for the perfect Gnome Browser was a mistake ?
------- Additional Comments From nicolas.mailhot 2006-06-11 08:36 EST ------- A test set of packages with all sorts of fancy scripting and config munging to accomodate greek, arabic and farsi speakers will hit Fedora Extra Devel with the next push http://buildsys.fedoraproject.org/build-status/job.psp?uid=10883 Please everyone test. Proponents of not_doing_it_this_way are welcome to propose patches as appart from the help of Simos this has been a long and solitary work
------- Additional Comments From simos.bugzilla 2006-06-11 15:11 EST ------- I tried the generated RPM packages on my FC5 box and they worked like a charm for Greek (as expected). I tested visually the fonts at http://dejavu.sourceforge.net/wiki/index.php/Testing_font_sizes and they looked ok for 1. Latin 2. Greek 3. Cyrillic I suppose we can use the practice: Unless someone complains in due course, everything is perfect :).
Τried the Fedora Extras Development packages on my system. Everything seems to work great. Also checked them at the dejavu Testing page, everything looked ok. Screenshots can be found at the Greek L10N page: http://fedoraproject.org/wiki/L10N/Teams/Greek
I installed Fedora Core 6 Test 1 and verified that DejaVu *did not* replace Bitstream Vera in the default installation. Greek installation was very ugly. I uploaded some screenshots on the following page: http://fedoraproject.org/wiki/L10N/Teams/Greek/Issues#head-6355afab18e12a4bc80288e6476fbfecb8530a24 Then, I added the new dejavu packages: dejavu-fonts, dejavu-fonts-makedefault and dejavu-fonts-block. The result is, as expected, orders of magnitute better. At the bottom of the above page one can find "before and after" the dejavu package installation screenshots. Submitted bug #196328 for the installation (anaconda), and it seems it depends on the resolution of this bug too. The installation was almost unusable due to the fonts lacking. DimitrisGlezos Fedora ambassador for Greece
Hello, i'm also a Fedora Ambassador for Greece and i can confirm that the FC6-test1 installation is unusable in Greek. The fonts are so messed up it makes it hard to work through the installation options. We definetly need to get a proper font in the core. Currently, we can't ask for any local magazines to include Fedora along with their DVDs (the free CD/DVDs they include within the mazagine). Their readers will just freak out the minute they see the installation....
Just did a clean install of FC5 (from fedora unity respin, dated 5-23-06), set greek locale for system default, encountered the usual font problems with some characters being substituted from other fonts, etc. I then installed the dejavu fonts packages from FC5 extras -- *not* extras devel, just the straight extras repo -- and it all seems ok now with the exception of gdm. I think there is still a substitution problem with Ï coming from some other font. I"m using the default gdm screen. Other than that, it looks (so far) very good. A huge step forwards.
Right now FC-5 and devel are in synch (I pushed the changes to FC-5 after 10 days of devel testing) This may change in the future if a fontconfig patch which is gently maturing is merge upstream and push to FC6 before the deadline (basically the patch does clean blacklisting of fonts in aliases when some specific lang is used, which is much nicer than the current hack in the Fedora rpm and hopefully will put to rest definitively all the but-dejavu-is-not-perfect-for-script-foo objections)
More on gdm and fc5 with dejavu: default theme is /usr/share/gdm/themes/FedoraBubbles This has Bitstream Vera hardcoded in it many places, e.g. font="Bitstream Vera Sans Oblique Bold 11" CHange these occurrences to Sans and all is well. The same for Bluecurve for folks who use that. I wonder what FC6T1 has for gdm theme fonts?
I looked at FC6T1 and found that it still uses hardcoded bitstream fonts. I'll open a new bug report and request that they are changed to a generic family like "Sans".
Here we go: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=197035
The DejaVu packages are aliasing Vera (and a lot of Vera derivatives now) so if you uninstall Vera from your system fontconfig will substitute it DejaVu (you may need to use --nodeps because of the stupif dep of OO.o on Vera)
For people who may have missed it: http://fedoraproject.org/wiki/Fonts/DejavuFeedbackCall
Yes we've seen it, it was also posted in fedoranews.org. I've tested Dejavu with FC6-test1 and they worked perfectly, appart from a problem with GDM. Apparently, GDM themes have hard-coded font names for Bitstream Vera Sans. Thus, GDM looks ugly all the time, even after we install Dejavu. The only solution is to edit the /usr/share/gdm/themes/FedoraBubble/*.xml files and rename "Bitstream Vera Sans" into "Sans". As a result the system will search for "sans" family fonts and properly use Dejavu (or whatever font family is the default).
Well, it's official Vera 2 won't happen : « Cambridge, Mass.-based Bitstream apparently doesn't envision an update to Vera, though the company doesn't close the door to the possibility. "Regarding our updating Bitstream Vera: If we were paid by the GNOME Foundation or another organization, we would be open to listening to offers and discussing it here at Bitstream," said Bob Thomas, director of product management at the company. "We'd consider doing it, depending on the updates and the time involved to complete the work." » (http://news.com.com/2102-7344_3-6092398.html?tag=st.util.print) One less long-term alternative to Vera
Some user feedback on DejaVu Sans arabic: http://sourceforge.net/mailarchive/forum.php?thread_id=22750205&forum_id=40874
Thats definetly great news. Any chance we can have Dejavu as the default font in FC6-test2?
I went through all the blocker bugs listed in FC6Blocker and FC6Desktop (see below), however I could not find any relevant bug reports that show DejaVu causes issues. For example, is was mentioned that the JVM crashes when Dejavu is present. Is this report in the Fedora bugs? Can we have the list of Fedora bugs that block the inclusion of DejaVu?
We had several reports of problems with the bytecode interpreter. The bytecode interpreter will never make it in Fedora, so it's not a problem with inclusion in core We had some reports of problems with the autohinter (sometimes on other fonts Fedora Core currently ships). I pushed them to the freetype people yesterday. We had 1 (one) report of someone having JVM problems. You'll note : 1. the Sun JVM is not in Fedora Core, nor is likely to made it any time soon 2. it uses its own "standard" fonts by default, so the user has to force DejaVu to get a bug (not easy to do except in a few specific java apps which allow font selection - also last time I looked the jvm pulled its font list from the core font system, and we do not declare dejavu there) 3. and anyway IMHO the bug looks like a pure Sun bug - I wish them luck getting Sun to fix it this year (was about to write decade, but Sun is feeling c# and classpath heat nowadays)
Simos, DejaVu LGC will probably be in FC6test2. We'll probably get reports then.
Since the decision has been made to include Dejavu LGC as default instead of the current default (package review in progress in https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198922), should we close this RFE?
I believe we should leave it open until we've decided if the full dejavu or just the light version is going to be included. Since Bitstream is no longer beign updated and Dejavu has backing from a large and active community, its possible Dejavu to become the default font for everything. Once FC6-test2 is out, we'll test it further and we may then decide for test3.
only LGC is a candidate for core inclusion at this point
I'm seeing extremely ugly fonts in Firefox after I began using dejavu-fonts-2.8.0-0.2.rc1.fc6. Is this a known problem?
(In reply to comment #95) > I'm seeing extremely ugly fonts in Firefox after I began using > dejavu-fonts-2.8.0-0.2.rc1.fc6. Is this a known problem? > Could you please provide a screenshot? Also the URL(s) you visited. (one thing you may want to check is to restart your session).
(In reply to comment #95) Check that Firefox uses the system fonts families (Serif, Sans serif, monospace) and not any other fonts.
Closing this as DejaVu LGC is now the default in rawhide.