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> > >
