[Fontconfig] Aliases

[John A. Boyd Jr.]

Hello Ambrose,

Ambrose Li wrote:
> <rant>
> 
Dare I suggest, Ambrose, that you are experiencing a "failure
of imagination?"  Please forgive me for the suggestion; I
offer it only to hypothesize that more may be possible, indeed,
easily possible, than you might have imagined.

> How do you convey semantic information for fonts? For Times,
> for example, it is not correct to say an "upright serifed Latin
> font" for many reasons. First, Times is not just an ordinary
> upright serifed font, it, among other things, has a particular
> "business feel" and is very space economical, and in some
> applications it would be very wrong to substitute a different-
> looking serifed font.  Secondly, it is not just a Latin font;
> e.g., Microsoft's "Times New Romans" covers WGL4 with non-Latin
> characters; and there are non-Latin Type 1 versions of Times,
> e.g., for Cyrillic.
> 
I'm not proposing selecting fonts only by description.  I'm
proposing separating the two kinds of selection: by name and
by (semantic) description, at two levels: user and "system".

Fontconfig supports system-level description comprehensively.
It's problem is at the user level.

I'm not a font expert (and don't want to be), but I would
suggest to you that there are lots of good "semantic descriptions"
of font attributes in use.  But let me try to stick to and
elucidate the basic point I'm trying to make.

- "Times", "Timmons" - symbolic, not semantic/descriptive
- "Serif", "Sans", "Monospace" - semantic/descriptive

Then, let me use your own words:

- "Times" => "business-feel", "economical"

Your terms are semantic descriptions.  Now, wasn't that easy?

Semantic descriptions of this sort are the way the intelligent
human mind works (more about that below).  It's like the nose
on your face: that important, that useful, and that easy to
look past and never see, never imagining it even exists.

> And how practical is it so catalogue the semantic descriptions
> of fonts? Just the Adobe Type Library has > 1000 type families,
> most of them having more than 1 font.
> 
Again, it's already being done.  My concern with fontconfig
is that it is avoiding an opportunity, by using what it calls
"aliases", as if names instead of as if semantics descriptions
at the user level, without paying enough attention either to
the need or to the opportunity to use semantic descriptions
at the user level.

> What about non-Latin fonts? It seems that non-Latin fonts (at
> least CJK fonts) are usually put into incorrect categories.
> 
How about "non-Latin" for starters?  Then, say, "Hebrew",
"Greek", ... (These are character set descriptions, I'm
imagining, from my limited knowledge of fonts.)

Let's try another example.  Let's say we want to describe
font width - I like that example...  How about "condensed,
expanded," and the like.  I'll bet you can find these in
existing fonts as well.

> We cannot even start to populate our catalogue with the existing
> panose information in TrueType fonts; a lot of fonts, including
> (or perhaps especially) commercial ones, often have incorrect or
> outright junk panose data. We'll have to recatalogue everything
> from scratch or at least manually verify all the panose data.
> And should we trust our own expertise, if even (supposed)
> professionals do it wrong for panose?
> 
Is "PANOSE" a trademark?  No matter, it's not the point.

I would suggest, Ambrose, that you're thinking less like a
user than like a system developer.

In that regsrd, let me just ask: how does (or might) a _user_
discriminate fonts at the level of panose information?

> Even if we can come up with a 100% semantic cataloguing scheme
> (which is hopefully better than any existence system), we will
> have to catalogue trademarked fonts in any case; if simply
> referring to the names would be infringement, how can any scheme
> work at all? And wouldn't the average person commit trademark
> infringement even during normal use?
> 
The proposal I'm making doesn't have to be "100%".  I've started
it already, just for font width (e.g., condensed .. expanded).
Doesn't break anything.  If you want to support panose information,
try "panose=".  In fact, in general, use something like

	"<attribute class> <relop> <attribute value(s)>"

In fact, fontconfig already does this - for _names_.  And that's
my point.  This isn't about _naming_, it's about _describing_. The
mechanisms for selection and matching are not about naming
fonts, but about describing them for purposes of selection.  And
the observation I'm passing along is that selection doesn't
require names, and when used, names are just symbolic representations
of one or more descriptive attributes, i.e., a special case.

So, do this matching on a more robust style element, not just on
the family name element and a few hardcoded style keywords.

I'm not saying don't use names.  I'm saying don't confuse descriptions
with names, as if names are the more general case.

> Graphic designers (or even knowledgeable amateurs) know that
> certain type families are interchangeable. If just saying
> "I have a font that looks just like Times available" could
> be infringement, then college professors will be infringing
> trademarks just for teaching typography during class.
> 
To your first point - yes; they know they are interchangable
because they have observed that the attributes that are
relevant are identical.  But the name associations must be
_learned_, and I can tell you that this is cognitively
burdensome.

What's the difference between an "alias" and what I call an
"abstraction", in this regard?  Plenty, it turns out.  Aliases,
as a kind of symbolic representation, must be memorized,
and used via cognitive recall and not much else.  Abstractions,
or more descriptively, concise semantic representations which
are neither ambiguous nor redundant at the level of relevant
cognitive use, are the stuff of cognition, in my view, being a
foundation (if not the foundation) for understanding, analysis,
and other essential cognitive capabilities.

Aliases have the properties of abstractions if they are also
abstractions, but again, they are then only a special case.
But in general, aliases are not also abstractions.  In general,
an abstraction can be used wherever an alias can, but the
opposite is not true at all.

"Sans," "Serif," and "Monospace," for example, are abstractions,
albeit being used in this context as aliases.

People will not find aliases to be as usable, nor as useful,
as are abstractions.  Indeed, human short-term memory has been
studied and can be characterized, in my view, as "7+/-2
abstractions," using the term "abstraction" as I usually do.

Now, if you could "prompt" a user to describe those attributes
that make fonts "interchangeable", then I would submit to you
that the names become entirely superfluous.  And indeed,
if the user learns a "working vocabulary" for such descriptions,
the need for prompting is mitigated as well.  Moreover, the
utility of that working vocabulary will far exceed the utility
of a likely smaller vocabulary of learned names and aliases
which are largely only symbolic.

To your second point - no; there's a legal principle called the
doctrine of fair use that applies to certain classes of use of
intellectual property.  Teaching, journalism, and research are among
those uses exempted under the fair use doctrine, as I understand it.

> Why is allowing the user (who could just know what he/she
> is doing) to make the mapping so bad?  If a new font comes
> out before it is catalogued --- or if a user uses an older
> fontconfig package, which is not a wrong thing in any sense of
> wrong --- why is it so bad that the user is not allowed to tell
> the system what to do?
> 
It's not bad at all - I never suggested it was.  Indeed, I want
to make it all the more possible, all the more useful, and easier
to do.  And all that takes it applying it to descriptions (which
in this context means the style element) instead of just to the
special case of the font family name, (here's the important point)
at the user level in all usage contexts, not just in the fonts.conf
file.

>>From the discussion, I'd have to say that the true goal of
> trademark lawyers is just to make it hard to make things
> interoperable, or perhaps they just want needless enmity between
> people. If what you say is right, I find trademark lawyers
> despicable.
> 
You're on the right track, in my opinion. Again, I'm not a lawyer,
but the historical purpose of trademarks had to do with competitiveness
in trade (e.g., anti-trust law and such) from what I've read, and like
patent law, I think history has turned the original purpose on its head.

So I'm not advocating any legal position here; I haven't revealed
my personal legal positions before the above paragraph.  I'm trying
to advocate a position that more concerns software usability and
utility, and thus software design from a user-oriented perspective.

I am not trying to foment needless enmity either.  But I would not
even have joined this mailing list if I did not consider this an
important issue, beyond just me and beyond just fontconfig.  This
particular package has become situated in a position where its use
is all but mandated for the typical user not just of fontconfig,
but of XFree86 and much of the environment and application
software that builds on it (e.g., GNOME).  I didn't ask for it to
be there.  And if I could just as easily get rid of it as patch it,
believe me, I would do just that, in a heartbeat.

> </rant>
> 
>