Re: Installing fonts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


On Sat, 07 Apr 2007 02:56:14 +0100, Keith Packard <keithp@xxxxxxxxxx> wrote:

On Sat, 2007-04-07 at 00:58 +0100, Thomas Worthington wrote:
   Simple question:

How do I install a font such as Frutiger so that styles like "black",
"ultra black", and "Extra Black Condensed" actually do something? Another
example would be installing Eurostile such that "Extended #2", "Extended
#2 Bold" etc. work.

An example of what fontconfig is generating and what you would like to
see would be helpful.

Eurostile appears to be the biggest problem. There is Eurostile and Eurostile Extended. From fc-list|sort I get:

Eurostile:style=Bold Condensed
Eurostile:style=Bold Extended #2
Eurostile:style=Bold Oblique
Eurostile:style=Demi Oblique
Eurostile:style=Extended #2

But from

fc-match "Eurostile"

I get

EUEX____.PFB: "Eurostile" "Extended #2"

when I expect

EU______.PFB: "Eurostile"


fc-match "Eurostile-12:Demi"

also gives the result:

EUEX____.PFB: "Eurostile" "Extended #2"

Note that "Demi" is listed on fc-list as one of the available styles.

I get similar results from Helvetica where fc-match "Helvetica" and fc-match "Helvetica:Bold" give the expected results:

hv______.pfb: "Helvetica" "Regular"


hvb_____.pfb: "Helvetica" "Bold"

but fc-match "Helvetica:Narrow" gives the Regular style and filename again:

hv______.pfb: "Helvetica" "Regular"

I find the Frutiger fonts, in particular, to be quite badly named as
they are delivered. Frutiger LT 65 Bold is marked as belonging to the
Frutiger LT 45 Light family (as a Bold weight). Frutiger LT 55 Roman is
marked as belonging to the Frutiger LT 55 Roman family (as a Book
weight). These are the only two weights I have at present; I'd like to
know what weights the other variants are marked with.

However, I understand their predicament -- much software provides access
to only two weights (Roman and Bold), so they've taken this very
sophisticated family and crammed it into this UI.

Although it is a simple question I would guess that I've put somewhere in the region of 60 hours of work into finding or working out an answer over
the space of several years. I did have a solution in the days before the
binary font cache: I put the font files into the normal place, ran
fc-cache and then ran a Perl script over the resulting font.cache-1 files
which systematically fixed all the errors in them which prevented the
example fonts above and several dozen others working properly. With the
advent of the binary cache - apparently with no documented format - this
is no longer possible, and was never desirable anyway.

You can edit the results automatically using match/edit rules that
operate while the fonts are being scanned. Take a look at the
80-delicious.conf file for an example of fixing up incorrectly reported
fonts. If you have a generally useful suggestion on fixing Frutiger, we
could include that with an upcoming fontconfig release.

Are you actually finding it difficult to access these fonts in
applications by name? Or are you just hoping to make the names more

The answer to that is quite complex but it might be easier to simply explain what I used to do with the human-readable cache files. For fonts where fontconfig was giving strange answers I replaced the cache data in such a way that "Helvetica Narrow" appeared as a totally separate font with only the one style ("regular), unrelated in anyway to any other font called "Helvetica"; I did the same for all fonts with styles not in the list


As it seemed to be styles not on this list which were most often troublesome.

The result was a long, somewhat unorganised list of fonts, to be sure, but far more importantly, I could access any font in any style I had installed in any program I had. The other good thing about this was that I did not have to do anything in particular for any style not on this list; they were all treated the same. If I had a font called "swinging60s" in styles "groovy", "cool," and "hip" it made no difference to me, they would just appear as three separate fonts which I could use without creating any special matching rules. This is an important point on a system with over 100 fonts on it.

The idea of using such rules seems far outside the desired functionality for a modern font system. I can cope with one or two special cases, but to ask a designer trying out Inkscape or any othe program to edit XML files, and then to *take those files with them* to every new machine ever afterwards is madness!

The installation of a font should ideally consist of putting the font file(s) into a directory called "Fonts" period. The real world and the many arbitary and strange names that exist and will continue to exist surely makes any attempt to use matching rules ultimately futile and unwieldy. Certainly, given the choice of accessing fonts in a crude way and not being able to access them at all without editing XML files, I think the vast majority of designers would take the former, as would I.

Thomas Worthington
Fontconfig mailing list

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux