On Tue, 2004-11-30 at 10:51 +0100, Lars Knoll wrote:
> > I strongly believe that fonts should have a canonical "programmatic"
> > name that is basically independent of locale. Since this isn't a
> > feature of font formats (well, other than postscript names), we can't
> > truly provide this.
> >
> > But using the ASCII/Latin name as is done currently by FreeType for
> > the primary name of the font comes close.
>
> But the font might also be specified in the localized name. Windows commonly
> displays fonts localized to the locale of the user. These font names will
> most certainly also get used in documents, as there is no easy way to get the
> latin name of the font in the API.
>
> In my experience users have two requirements:
> They want to see the localized font name (preferably in the language of the
> font, ie. a chinese font should have a chinese name).
> On the other hand they want fonts that are used in a document to simply
> resolve correctly. This implies that while you might only show one font name,
> matching has to work against all of them (localized and english).
Well, what name is displayed to the user is essentially independent
of what is in the document. Only in a few cases do users actually hand-
create documents and deal with font names.
> We actually had lots of problems with Qt on Windows because application
> developers were specifying a font to use somewhere in the application and
> Windows couldn't find it anymore after deploying the application in a
> different environment. The solution for us was to show the localized name,
> but make sure we also parsed the latin name out of the font and match against
> both. That solved all of the bug reports we had in this respect.
That's the type of bug I'd like us to avoid with fontconfig. The "name"
of a font should never depend on locale.
> > > If we do permit multiple names for fonts, we need to identify how those
> > > names are reflected through the Fontconfig API.
> > >
> > > One possibility is to identify one name as the 'canonical' name which
> > > represents the sole element of the FC_FAMILY/FC_STYLE pattern element and
> > > to place the additional names in another pattern element. This would
> > > permit 'smart' applications to discover these additional names for
> > > presentation purposes while not bothering 'dumb' applications. However,
> > > this would also make font matching problematic -- it would be tricky for
> > > applications to figure out how to match fonts against non-canonical
> > > names, and that seems wrong.
> >
> > I see non-canonical names as being primarily a user interface element.
> >
> > Though I guess the question is "how do Chinese-language web pages
> > specify fonts"; if using Chinese language family names in chinese web
> > pages is common, then that probably argues that matching against
> > non-canonical names is important.
>
> Judging from what Windows offers as font name in their API, a person working
> on a chinese locale will specify the font using the chinese name.
>
> > Dan Williams (cc'ed) mentioned something to me about Word documents
> > specifying names in non-ascii encoding. Though OpenOffice isn't
> > currently using fontconfig properly, that might be more evidence.
> >
> > > Another possibility is to provide all of the names in the FC_FAMILY
> > > pattern element. Order the list so that the 'preferred' name occurs
> > > first and even na?ve applications will end up presenting fonts in the
> > > right language. Listing would return all names and it would be up to the
> > > application to sort through them to find the desired presentation. This
> > > would require some parallel property marking the language(s) for each
> > > name. Fonts with a single name would not need this additional property.
> >
> > Can you do this in a way that isn't going to break existing applications
> > that use the listing APIs?
> >
> > While invisibly matching against non-canonical names as a fallback might
> > be neat, backwards compatibility is vastly more important.
>
> How much do you think would really break if you match against both canonical
> and localized names? One can specify the mechanism in a way that for the
> second name only exact matches count. That should bring you on the safe side.
> At the same time fontconfig currently doesn't handle localized names at all,
> and this will IMO cause bugs for a lot of asian documents.
My concern here was not in matching, but in listing. fontconfig is a
fairly rigid abstraction, so the two aren't independent.
I agree that matching against localized font names is important, but
what I'm saying here is that if it's going to confuse legacy apps
to have them in FC_FAMILY, then it needs to be done as a separate
element. (*)
But if Keith can figure out how to provide multiple font names in
FC_FAMILY in a way that legacy apps won't get confused, that's even
better.
Regards,
Owen
(*) Side issue is that TrueType fonts allow the localization of style
names, don't know how that fits into the picture. It doesn't
really matter for Pango, since Pango canonicalizes to a fixed
set of style names that can be translated with gettext().
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://freedesktop.org/pipermail/fontconfig/attachments/20041130/8af2f331/attachment.pgp
