On Fri, 2008-07-25 at 20:50 +0100, Dave Crossland wrote:
> 2008/7/25 Vasile Gaburici <vgaburici(a)gmail.com>:
> > On Fri, Jul 25, 2008 at 4:18 PM, Nicolas Mailhot
> > <nicolas.mailhot(a)laposte.net> wrote:
> >> — We should not hide general-purpose fonts in app-specific directories.
> >> TEX should use system fonts directly.
> > XeTeX can do that. TeX probably NEVER will because that violates TDS.
> > If you don't what that means, then don't take on the subject of TeX
> > fonts.
> I second the idea that TeX ought to be an exception to the guideline
> "not hide general-purpose fonts in app-specific directories"; TeX
> predates all other programs in a GNU/Linux system, and TeX users have
> hardended expectations about how it works; if Fedora's TeX package
> fiddles with things, that will be a loss for users.
We're under a *nix. The TEX packagers can symlink the files to TEX
internal directories if that makes TEX users feel better. Though we've
been resorbing various private font repositories in the past years
(starting with the xorg ones) and mid term I don't see how TEX can
escape the trend.
That's the bad thing of switching to a common font format. (The good
thing being of course that you get access to the fonts other groups
> (I'm still not getting Nicolas' emails :-(
I'm routing lab6.com through another smtp now. Of course that won't
change mails sent directly to the list. Someone is blackholing me
between Red Hat servers and yours.
I did not have time finish writing all the details below, I'll write
some more tonight, but before this Type 1 bashing gets out of hand,
read the stuff below. If you don't want the gory details, the bottom
line is that the mainstream TeX still works best with type-1 fonts.
And it isn't likely to go away soon. So I would not rush to deprecate
type 1 fonts, unless you want TeX users to stop using Fedora. This
isn't likely to change anytime soon. XeTeX is not as robust as the old
TeX, and still lacks some features next to pdftex. XeTeX's acceptance
with academic publishers is virtually nil today. And they, the
publishers dictate what most academics use to write papers, books etc.
The mainstream TeX (and by that I mean dvips, dvipdfm and pdftex)
cannot currently use OpenType/CFF, but only Type 1 (and some TeX font
specialties that are irrelevant in this discussion). CFF fonts need to
be converted to Type 1 using otftotfm. Several tools exist to automate
the CFF to Type 1 conversion for large font families because this can
be a LOT of work using otfotfm directly for fonts that have optical
sizes (like the Adobe Pro series). The most notable automation tools
are, in order of how complete they are: autoinst from fontools,
otfinst, and otftofd. Each has some features the other lacks, however.
Most notably fontools lacks optical size support. Some LaTeX packages,
like MinionPro, have their own otfotfm wrapper scripts, which are a
lot easier to use because some files (enc, fd) come pre-generated.
Furthermore, dvips and dvipdfm cannot use TrueType fonts directly
(regardless whether they have OpenType features), but can convert them
to bitmap PK fonts, which print ok, but may look bad on screen. In
contrast pdftex can embed TrueType as outlines in the pdf using
\DeclareTruetypeFont. Unfortunately, generating the TeX infrastructure
(tfm font metrics, encodings) for TrueType fonts requires MORE work
than generating the Type 1 from a CFF. This happens because a
different, less featured tool must be used: ttf2tfm. There are some
wrappers like ttf2tex (no longer maintained), and fontinst, which is
rather outdated. Autoinst (from fontools) is the only tool that
handles both OpenType CFF and TrueType.
Most tutorials for using TrueType with pdftex recommend using ttf2tfm directly.
FYI: XeTeX uses dvipdfmx as backend, which supports all flavors of
OpenType, but this requires xdv input that is not the same as the
traditional dvi produced by TeX. pdftex does not produce any
For some simple usage examples see (note - first one is XeTeX):
A complex example using Gentium via ttf2tfm:
To be continued...
On Fri, Jul 25, 2008 at 2:33 PM, Nicolas Mailhot
> On Fri, 2008-07-25 at 13:03 +0200, Patrice Dumas wrote:
>> On Fri, Jul 25, 2008 at 12:36:40PM +0200, Nicolas Mailhot wrote:
>> > Frankly, the other font formats are so much less useful than modern font
>> > formats, the probability someone did creative legal restructuring is
>> > much lower.
> Anyway, I've amended the proposal in a less format-oriented version
>> > The big exception are Type1 fonts but I just hope they can
>> > die die die (and if the Tex-Gyre situation is fixed and we can use OTF
>> I don't think this may happen in a while because some very interesting
>> apps (though not mainstream desktop apps, fortunately) uses type1
>> fonts, mostly using t1lib, like xfig, xdvi, grace.
> Our TEX can use TTF (OpenType TT) and OTF (OpenType CFF) now. Given that
> OTF (OpenType CFF) embeds something very close to what PDF uses, I'd be
> surprised if Ghostscript could not use the OTF TEX-Gyre fonts directly.
> Do we really have so much interecting stuff that depends on Type1 once
> TEX and GS are out of the way?
>> > In the meanwhile, it may make sense to add Type1 to the list.
>> For tex I believe that it will be too complicated to use the system
> TEX now uses the same formats as everyone else (TTF and OTF). I frankly
> do not think we can afford (or have the resources) to duplicate megs of
> fonts in TEX-specific packages. If TEX can not use the fonts in
> fontconfig directories, it just has to symlink them somewhere it can.
> Nicolas Mailhot
> Fedora-packaging mailing list
The next Fedora Packaging Committee Meeting will be held on Tuesday,
July 22, 2008. (Note: Normally, the FPC meets every other week, but this
meeting was scheduled since we did not have quorum on July 15, 2008)
Meeting time is at 17:00 UTC. FPC members, please try to be on-time, as
the Fedora Board meets at 18:00 UTC.
Items scheduled to be discussed:
Python virtual Provides: PackagingDrafts/Python
Font bundles amendement to Fonts policy:
As a reminder, the process for getting items onto the FPC's agenda is
[Looks like this has been discussed previously, though perhaps not here.
Sorry if it's annoying to have it brought up again.]
I'd like to make "yum install" case-insensitive (for occasions where
there is only one useful interpretation of case), so that I can do
e.g. "yum install wxgtk" without first doing "yum search wxgtk" and
finding that the required case is "yum install wxGTK".
In the unlikely event of repositories containing two packages with the
same case-insensitive interpretation (would this meet packaging rules,
and is it used by anyone?) we can refuse to operate on anything but the
correct case. There is no potential for damage here -- we don't proceed
if you might have meant something else.
What do people here think? Is there anything I've missed?
Chris Ball <cjb(a)laptop.org>
I recently posted an email about Firefox/xulrunner extensions and dependencies
to fedora-devel, but I got no answers, so I'll try this list as well. Here's
what I wrote:
> As we just saw with nspluginwrapper, packaging things dependening on
> xulrunner/Firefox is a bit problematic. My Mozvoikko package was recently
> approved by Ville Skyttä
> (https://bugzilla.redhat.com/show_bug.cgi?id=448215) but he had a good
> question about the dependencies:
> "If I understand correctly, using xulrunner-unstable makes this prone to
> breakage on updates - is there some versioned dependency towards some
> package that could be used so that it would be easier to notice such
> I think the answer here is no. Or is there? We just saw what happens if you
> hardcode a xulrunner version as a dependency, there will be breakage as
> soon as xulrunner is updated. I had the Mozvoikko package from that review
> installed as well and it worked fine after the update of Firefox and
> xulrunner. So I think I should just leave the xulrunner dependency
> unversioned and rebuild the mozvoikko package if I notice the extension
> being broken after a xulrunner update.
> I also noticed something interesting about xulrunner-devel and
> xulrunner-devel-unstable. Mozvoikko can't be built just with the stable
> headers which apparently are in /usr/include/xulrunner-sdk-1.9/stable/. For
> example it needs mozISpellCheckingEngine.h. This file can be found from two
> locations, however. The xulrunner-devel package puts it
> in /usr/include/xulrunner-sdk-1.9/spellchecker/mozISpellCheckingEngine.h
> and the xulrunner-devel-unstable package puts it
> in /usr/include/xulrunner-sdk-1.9/unstable/mozISpellCheckingEngine.h. Why
> are there two copies and is it considered stable or unstable? I'm thinking
> it's "classified" as unstable, but why is it in the "stable devel package"
> then as well?
If anyone has any answers or ideas on packaging the extension, I would really
appreciate the feedback.
While I'm waiting for my Lisp packaging guidelines to be reviewed
again, I've taken the liberty of updating sbcl, cmucl and clisp to take
advantage of the new common-lisp-controller package (which, I believe is
approved, but the reviewer needs to flip the bit, or do I do that?
I've also uploaded a collection of popular Common Lisp library packages
for eventual submission here: http://people.redhat.com/green/Fedora.
If you, for instance, install this new sbcl as well as a library like
cl-clsql, you should be able to just run execute (require
'clsql-sqlite3) and the compiler will populate
/var/cache/common-lisp-controller/sbcl/$USER/clsql with .fasl files.
The sbcl package is working really well. I'm still having a little
trouble with cmucl and clisp, but I thought I'd let people know what I
was up to anyway.
So, bottom line... I need some forward motion on my Lisp packaging
Where should icons for desktop files be stored? Some packages use
/usr/share/pixmaps. Others use subdirectories under
/usr/share/pixmaps (some directories are unowned too). Some use a
private directory under /usr/share/<name>. Still others use
>rpm -ql gnome-utils | grep /usr/share/pixmaps
file /usr/share/pixmaps/gsearchtool is not owned by any package
How should the icon be referred to in a desktop file? Some use
absolute paths, others no path at all. desktop-file-install complains
if there is a relative or partial path.
Some desktop file icons don't use an extention, but some do:
It looks like the majority of the desktop files on my F9 system are
using the form without an extension.
All of this is confusing. For new applications, what should they use?
What are the semantics for the various syntaxes that are used? What
should be done for upstream packages that have icons? What if they
are in xpm format rather than png?