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:
Hi,
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
Eurostile:style=Bold Condensed
Eurostile:style=Bold Extended #2
Eurostile:style=Bold Oblique
Eurostile:style=Condensed
Eurostile:style=Demi
Eurostile:style=Demi Oblique
Eurostile:style=Extended #2
Eurostile:style=Medium
Eurostile:style=Oblique
But from
fc-match "Eurostile"
I get
EUEX____.PFB: "Eurostile" "Extended #2"
when I expect
EU______.PFB: "Eurostile"
likewise,
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"
and
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
natural?
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
italic
bold
oblique
roman
regular
medium
normal
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
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig