Around 21 o'clock on Sep 3, Juliusz Chroboczek wrote:
> 1.1 People have been making comments to the effect that the config
> file language is too expressive[1], and therefore difficult or
> impossible to process automatically.
I don't think anyone has complained about it's expressive power, only
about the complexity of specifying simple things and the fact that it's
broken. The config file has two separate roles which should occur on
opposite sides of the face selection mechanism. The first is to tune the
font selection by making substitutions in the face name/style names as
appropriate. The second is to adjust the rendering of the selected font.
Adjusting the font rasterization should be able to take the selected font
into account; right now it only has access to the pattern:
times,serif-12 serif-12
match any family == "times" edit antialias = false;
If you don't happen to have a 'times' font installed, the edit will change
the rendering of the first face even when it matches 'charter'. That's
wrong.
In addition, specifying font preferences is too hard:
match any family == "times" edit family += "times new roman";
match any family == "times new roman" edit family =+ "times";
What this says is the "times" and "times new roman" are essentially
equivalent, but that the system should prefer 'times new roman' if both
are available. As this is probably the most common thing to do before
matching, it seems like there should be a more convenient and fool-proof
mechanism.
> (i) the fonts catalogue. This should contain a boring list of font
> name/font file pairs, and be a true cache of information contained in
> font files. It should be possible to add a font file in the relevant
> place, and regenerate this file from scratch.
Xft reads this from XftCache in each font directory and also reads/writes
this from ~/.xftcache. Fonts not found in any XftCache are stored in
~/.xftcache automatically. Given the troubles we've had in the past with
font directories out of sync, I decided that the library should get the
right answer even if the files were broken; the cost is minimal.
The entire XftPattern structure associated with the font is stored in the
cache; this includes styles, encodings and (shortly) the set of available
glyphs.
> We should arguably support two fonts catalogues, the system-wide one
> and the per-user one.
As you can see, there already are a plentitude of font information caches.
> (ii) the standard font substitution file. This file should be
> provided with XFree86, and contain a list of font substitutions that
> do not depend on which fonts are installed. For example,
Yes, what I need is a simple syntax that captures the extent of what we
need without the verbosity of the current grammar.
> - if none of the above can be found, but only then, substitute
> Lucidux Serif.
>
> I am quite positive that the current format can handle the former three;
> I'm not sure about the latter.
The resulting XftPattern can contain a *list* of face names in preference
order. To prefer Times Roman over Lucidux Serif, do:
match any face == "Times Roman" edit face =+ "Lucidux Serif";
However, it doesn't currently have any way to make sure Lucidux Serif
also comes after Times New Roman and Nimbus Roman. I think what we want
is something like:
prefer face "Times New Roman", "Times Roman", "Nimbus Roman", "Lucidux Serif";
I think this also provides for default faces:
prefer face "Times New Roman", "serif";
The semantics of this seem clear to me; the library could generate a
partial order when multiple preferences overlap. We'd have to figure out
what to do with conflicting preferences.
> (iii) the user preferences file, which should be able to override any
> system-wide information. This could contain
>
> - anti-alias all fonts below 12 pt but above 5 pt;
Such specifications are specific to the use of the fonts; we need to
characterize how the glyphs are going to be used to make this workable.
In addition, these need to be selected based on the face actually in use,
not the pattern specified.
> - I'm a deviant; systematically substitute Helvetica with Zapf Chancery.
That's just another preference, all such should be available in both the
system-wide config file and the per-user file.
> Only the fonts catalogue should ever be touched automatically (from a
> cron job?). All the others should be hand-editable by the user, and
> never touched by software.
The fonts catalogue is generated automatically already, either by xftcache
or the library itself when it discovers fonts not specified by the cache
files. All of the other files should be amenable to programmatic editing
so that people can build fancy gui-based configuration tools. There may
well need to be more sophisticated selection mechanisms, those should be
explicitly separated so that the automatic tools can avoid mangling them.
> 1.2 I still don't understand the matching semantics. It looks like
> there's both a matching (projection) component, and one related to
> optimisation (minimisation of errors). Keith, I'll be glad to write
> up some documentation, but you need to give me some hints.
It's a simple search to optimize the distance between the pattern and the
available fonts. Once the pattern has been edited by the config file
rules, it is measured against the available fonts and the closest one is
selected. This (obviously) ensures that some font will always be chosen.
The measurement is pretty simple, there is a list of attributes which are
sorted in priority order; those nearer the start of this list sway the
selection more than those below. Missing attributes are ignored.
> XftFont implements a disjoint union of core fonts and FreeType fonts
> as a ``C'' union and a Boolean for discrimination. This means that it
> is impossible to extend Xft without breaking binary compatibility.
You're probably right that Xft should provide at least some abstraction
here. What I'd like to keep is the exposed fundemental font properties
and then provide boolean functions XftCoreP, XftFreeTypeP that test
which rasterizer "owns" the underlying data. A new XftFT_Font function
would return the associated FT object; this would allow us to cache this
object at the same time.
> 2.3 I've got a few nits with naming of encodings in xftfreetype.c. It
> looks like Xft uses ``adobe-fontspecific'' where the core backends use
> one of ``adobe-fontspecific'', ``microsoft-symbol'' or
> ``adobe-symbol''; I think Xft should accept all three names.
The encodings are about to disappear -- Xft will expose both Unicode and
the raw font indices, probably through separate API calls instead of the
current strange "encoding" value.
> [1] It's not Turing-complete, though. It looks like all config files
> terminate.
I avoided adding a looping construct to keep people from writing complete
applications in the config file syntax. One must always be careful to
avoid giving people too much rope.
[EMAIL PROTECTED] XFree86 Core Team SuSE, Inc.
_______________________________________________
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
