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.