Re: [Fonts]Font family name problem
Pablo Saratxaga wrote: ... On Thu, Jul 18, 2002 at 10:12:05AM -0700, Keith Packard wrote: Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? Not necessarly ASCII names, but unique and locale independent ones. So if a document which embedds fotn names is open under a different locale nothing strange happens. Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Will there be a way to get the localized name using the ascii only name? Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 8 o'clock on Jul 22, Brian Stell wrote: Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Hmm. I think I see the way through here. See below. Will there be a way to get the localized name using the ascii only name? Yes. The representation of the names internally includes all of the localized names along with the postscript name (which is always ASCII), any match or list result will include all of these names. I would sort the names so that any English or Latin names would come first in the list. Ok, so applications want a notion of 'canonical' family names which can be mapped to localized names for display to the user at runtime. I plan on storing all of these names together in the same FC_FAMILY entry for each known font, tagged (somehow) with the associated language. The entries would be sorted with English names first, followed by names containing only Latin characters and then the remaining names following sorted by language tag. A naïve application using the existing FcPatternGetString API will get an English name for each font. A separate API (FcPatternGetLangString?) would walk the list of names and select the one best matching the specified language (or current locale). An application wishing to store font preferences in a locale-insensitive fashion can either: a) Store just the English name. Converting to a local name would require a call to FcFontList and then a call to FcPatternGetLangString. b) Store all of the names along with their languages. This can be done with FcNameUnparse/FcNameParse which generate UTF-8 encoded strings for the font name. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard wrote: ... A naïve application using the existing FcPatternGetString API will get an English name for each font. Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. a) Store just the English name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 9 o'clock on Jul 22, Brian Stell wrote: Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. Yes, I agree that would be nicer, except that truely naïve applications are likely to incorrectly display UTF-8 strings. The FcPatternGetLangString API would return the appropriate UTF-8 string so that slightly-less naïve applications could trivially extract the localized name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. In the suggested API I presented, that's quite possible. The only cost is in converting the ascii name into a local name which requires searching through the set of available fonts to match the ascii name. This would have the (questionable) property where the application would find out that configured fonts were missing. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
On Mon, 22 Jul 2002, Keith Packard wrote: Around 8 o'clock on Jul 22, Brian Stell wrote: Will there be a way to get the localized name using the ascii only name? How about the other way around? Given a localized name+lang, would it be possible to get the ascii name? Put differently, would there be a way to access the mapping from a localized name+lang to a font(or ascii name/canonical name)? Yes. The representation of the names internally includes all of the localized names along with the postscript name (which is always ASCII), any match or list result will include all of these names. I would sort the names so that any English or Latin names would come first in the list. Reading this, I think it should be possible, but is there an API for that? A number of web pages have embedded or separate CSS with only 'localized font (family) names'. Web browsers or any other applications accessing those CSS' need to map localized names+lang (assuming that lang info. is available in one way or another) to fonts. Although it appears that they can roll out their own for this purpose, wouldn't it be nice to have this in fontconfig? Thanks, Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Kaixo! On Wed, Jul 17, 2002 at 06:26:47PM -0700, Keith Packard wrote: Ok, I'm adding localized names to fontconfig. To allow applications to continue working with a single name, I'm actually listing the localized names in the FC_FAMILY value using a new datatype (FcTypeLangString). Ask for a string, and you'll get back just the family name, but ask for a LangString and you'll get both. What you mlean by both ? Users should see only one name for each font; but that name should be, if exists, the localized one. Then, for programs internally, a unique name (the ascii-only one) be used. In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. The localized lists shoumld be a list of 2-tuples: (ascii-name, localized-name) one used for display, and the other used for the return value in case it is chosen. A couple of questions: 2) Should I use the current locale to select a family from those listed when an application requests a string for FC_FAMILY? yes. (well, it may be interesting to have a possibility to explicitelly tell a given language; but in the general case the current locale should be used, it should follow the same rules as for translations of programs interfaces and menus imho). That would mean returning different values depending on the locale. Of course, that is the purpose. And that is why a unique ascii-only value should always be associated with them, so programs can use that unique and locale-independent value; and users see the locale dependent value. It should be seen and handled in a way similar to the localization of programs interfaces; with the difference that translations are not handled trought gettext bu embedded in the fonts and should be handled by a specific api. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.stben.be/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] msg00980/pgp0.pgp Description: PGP signature
Re: [Fonts]Font family name problem
Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? The underlying infrastructure supports fonts with multiple names, it seems obvious to me that it will be easier to get application support if they need deal with only one name, and that name should be the localized name. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Kaixo! On Thu, Jul 18, 2002 at 10:12:05AM -0700, Keith Packard wrote: Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? Not necessarly ASCII names, but unique and locale independent ones. So if a document which embedds fotn names is open under a different locale nothing strange happens. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Ok then, so it's ok. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.stben.be/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] msg00984/pgp0.pgp Description: PGP signature
Re: [Fonts]Font family name problem
Around 2 o'clock on Jul 14, Pablo Saratxaga wrote: Yes, both localized names and ascii-only names are usefull. Maybe the same api could be used for both cases, trough a paremeter telling which localized language is requested (if C, then ascii-only names are given). Ok, I'm adding localized names to fontconfig. To allow applications to continue working with a single name, I'm actually listing the localized names in the FC_FAMILY value using a new datatype (FcTypeLangString). Ask for a string, and you'll get back just the family name, but ask for a LangString and you'll get both. A couple of questions: 1) Macintosh names are encoded in weird Macintosh text encodings, is it OK to ignore the non-Apple Roman names here? I can't see embedding conversion tables for all of the weird encodings. 2) Should I use the current locale to select a family from those listed when an application requests a string for FC_FAMILY? That would mean returning different values depending on the locale. All of the return values would map to the same font. The reason for this is so that simple apps continue to work in a simple fashion. The alternative is to force apps to use a new API which includes an explicit lang; when that is NULL, I could use the current locale. You'll get localized names for family and style; there aren't any other obviously useful string values in the current set of font name elements. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Pablo Saratxaga wrote: ... On Sat, Jul 13, 2002 at 10:40:51AM -0700, Keith Packard wrote: I'd be interested to hear whether other people will find this scheme usable, and whether people would also like to see the other localized names made available for presentation to the user. Yes, both localized names and ascii-only names are usefull. Maybe the same api could be used for both cases, trough a paremeter telling which localized language is requested (if C, then ascii-only names are given). The availability of localized names will make users feel more comfortable, as other systems will display those names to them. Yes, being able to read localized font names greatly improves the ability of non-English readers to select fonts. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard [EMAIL PROTECTED] writes: Around 18 o'clock on Jul 12, Keith Packard wrote: I'll add transcoding for apple-roman names. My intent is to prefer english names, and failing that, to choose the first entry in a known encoding. Well, *that* was entertaining. It almost works. Except for MS Mincho. For both FONT_FAMILY and FONT_PS_NAME, it advertises a Macintosh platform name, Apple Roman encoding and language id 0x411, which is Microsoft's language tag for Japanese(!). At least Microsoft didn't re-use Apples language tags... The msmincho.ttc (the version shipped with Windows XP) has the PlatformID/LangID pairs: Macintosh/English (1/0x0) Windows/English (3/0x409) Windows/Japanese (3/0x411) Odd. Maybe there was a bug in older versions that they fixed. Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Kaixo! On Sat, Jul 13, 2002 at 10:40:51AM -0700, Keith Packard wrote: I'd be interested to hear whether other people will find this scheme usable, and whether people would also like to see the other localized names made available for presentation to the user. Yes, both localized names and ascii-only names are usefull. Maybe the same api could be used for both cases, trough a paremeter telling which localized language is requested (if C, then ascii-only names are given). The availability of localized names will make users feel more comfortable, as other systems will display those names to them. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.stben.be/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] msg00975/pgp0.pgp Description: PGP signature
Re: [Fonts]Font family name problem
Around 16 o'clock on Jul 12, Yao Zhang wrote: These may not be fontconfig's problem but since FreeType 2 has APIs to access any naming table in the font, it is not FreeType 2's problem either. The way I solve this problem is to change FreeType 2's convertion: Instead convert non-ASCII Unicode name to '?', convert it to UTF-8. At least it works for me. I'd like to use UTF-8 if possible; is there a way to get the UTF-8 value from FreeType without changing that library? I'm sure they have a good reason for hiding the non-ASCII characters. 2. I cann't find a way to list aliases. FcFontList() lists physical font only. That is by design. The essential problem is that many family names are registered trademarks, presenting these to the user when they are used only as alias names would be a trademark violation -- essentially we'd be advertising the presense of a trademarked font name which would then go and match some other font. We were allowed to make fontconfig aliases between the Lucidux and Luxi families because of this. If you can think of a way to reconcile these two requirements, please suggest it. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard [EMAIL PROTECTED] writes: Around 16 o'clock on Jul 12, Yao Zhang wrote: These may not be fontconfig's problem but since FreeType 2 has APIs to access any naming table in the font, it is not FreeType 2's problem either. The way I solve this problem is to change FreeType 2's convertion: Instead convert non-ASCII Unicode name to '?', convert it to UTF-8. At least it works for me. I'd like to use UTF-8 if possible; is there a way to get the UTF-8 value from FreeType without changing that library? I'm sure they have a good reason for hiding the non-ASCII characters. See the thread starting from: http://www.freetype.org/pipermail/devel/2002-March/003101.html (And the continuation later under Re: Request about font name problem) You need to distinguish: A) The programatic name suitable for storing in config files, coding into a web page, etc. This is what face-family_name is meant to be and face-family_name is defined to be ASCII traditionally so it can't really be changed. (Plus, things are just going to work better generally if this is Roman/ASCII) A font that has ?'s in the output with the current FreeType most likely has a TrueType name table with invalid contents ... e.g. Chinese in the English name field. B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: [ I think fontconfig should have some way of getting the name for a font localized into a particular language... my best idea as to an API would be to have a call like: char *FcConfigGetLocalizedName (FcConfig *config, FcPattern *p, const char *langid); the FC_LANG_* constants are not appropriate for the langid here, so you'd need something different. ] 2. I cann't find a way to list aliases. FcFontList() lists physical font only. That is by design. The essential problem is that many family names are registered trademarks, presenting these to the user when they are used only as alias names would be a trademark violation -- essentially we'd be advertising the presense of a trademarked font name which would then go and match some other font. We were allowed to make fontconfig aliases between the Lucidux and Luxi families because of this. If you can think of a way to reconcile these two requirements, please suggest it. Well, if aliases were first-class objects in FreeType, there would be an obvious solution ... tag the alias as to whether it should be displayed or not. But that doesn't work with aliases just being pattern matching expressions. So I don't have any ideas here. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 17 o'clock on Jul 12, Owen Taylor wrote: This is what face-family_name is meant to be and face-family_name is defined to be ASCII traditionally so it can't really be changed. (Plus, things are just going to work better generally if this is Roman/ASCII) I can accept that face-family_name is supposed to be ASCII, but fontconfig is entirely tolerant of UTF-8 and I'd really rather use those names; I can't see how things are just going to work better in this case; we're ending up presenting '?' instead of valid characters, that doesn't seem useful. B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: FT_Get_Sfnt_Name works only with TrueType and OpenType fonts. Do all other formats support only ASCII names? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
From: Keith Packard [EMAIL PROTECTED] I'd like to use UTF-8 if possible; is there a way to get the UTF-8 value from FreeType without changing that library? I'm sure they have a good reason for hiding the non-ASCII characters. From FT2's documentation, it seems that you need to know that the font is a TTF first (FT_FACE_FLAG_SFNT?). Then use FreeType 2's Format-Specific API to access any SFNT names. The question is which name you will use? There could be serveral names encoded in Unicode, not to mention names in other encodings. Regards, Yao Zhang ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard [EMAIL PROTECTED] writes: Around 17 o'clock on Jul 12, Owen Taylor wrote: This is what face-family_name is meant to be and face-family_name is defined to be ASCII traditionally so it can't really be changed. (Plus, things are just going to work better generally if this is Roman/ASCII) I can accept that face-family_name is supposed to be ASCII, but fontconfig is entirely tolerant of UTF-8 and I'd really rather use those names; I can't see how things are just going to work better in this case; we're ending up presenting '?' instead of valid characters, that doesn't seem useful. I think it's important that it's clear that FT_FAMILY is not localized and is always the English name if there is one; you don't want changing the order of names in the font to change the name fontconfig reports. I think it's useful if it corresponds to face-family_name as frequently as possible. I don't think it would hurt if, when FreeType ends up doing ? substitution, fontconfig converted to UTF-8 instead. (Hopefully these cases are really rare - I don't think I've seen an example of a font yet that has NO English name.) B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: FT_Get_Sfnt_Name works only with TrueType and OpenType fonts. Do all other formats support only ASCII names? I'm not aware of any other font formats with localized names; probably most font formats that aren't just ASCII have horrors like the following from the PFR spec: character[]: An unsigned integer representing each character in the name of the physical font. Although the preferred coding system is ASCII, any 8-bit coding system can be used as long as it is consistent with the manner in which the font is referred to. Regards, Owne ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 18 o'clock on Jul 12, Keith Packard wrote: I'll add transcoding for apple-roman names. My intent is to prefer english names, and failing that, to choose the first entry in a known encoding. Well, *that* was entertaining. It almost works. Except for MS Mincho. For both FONT_FAMILY and FONT_PS_NAME, it advertises a Macintosh platform name, Apple Roman encoding and language id 0x411, which is Microsoft's language tag for Japanese(!). At least Microsoft didn't re-use Apples language tags... In the FONT_FAMILY string, I find a combined full-width latin and Han string while in the FONT_PS_NAME string, I find an ASCII string. I think I'll add a check on the non-English names to see if they're at least Latin and prefer those over the non-Latin names. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 17 o'clock on Jul 12, Owen Taylor wrote: B) The localized name for a particular locale that should be shown to the user; FT_Get_Sfnt_Name() can be used to get this from a font, but it isn't exposed in fontconfig currently. In the mail above, I said: fontconfig only needs to expose an API if you need to extract the information before opening the font, in which case fontconfig would actually need to store this information in the font information files (*/fonts.cache). Carrying this architecture to it's logical conclusion, we could tag FC_FAMILY and FC_STYLE components with their language; matching could be done using the language provided in the pattern (or extracted from the locale). Match/edit patterns in the config file could be tagged with a language to restrict them to a single language, or left untagged in which case they'd apply to any language. Matching value and language would be better than matching just value for purposes of font selection. I would like to point out that the font file tables are rather restricted in their choice of language. The Microsoft format tables support only 67 languages. Apple (oddly) does a bit better with a list of 150 languages. This leaves us wondering how to display localized names for users of other languages. I guess we'll assume they speak the modern lingua franca. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
