The TrueType font format (and probably others) permits family and style names to be provided in multiple languages (using several national encodings). I''ve wanted to include a mechanism for making these available to applications for a long time, in fact this remains the only release blocking feature for fontconfig 2.3. I''ve got a couple of mediocre ideas and am searching for more; if we can''t manage to figure out something sensible, I suggest that we just ship fontconfig 2.3 without this feature soon. I''ve had this idea that we must always provide a Latin encoded name for every font, which immediately requires support for multiple names for the same font. Today, I''m wondering if it wouldn''t just be easier to provide a single name for each font and select that name in some straightforward fashion from the list of available names. I see the identification of the ''native'' name for the font as a requirement in any case, perhaps we should simply make ''native'' == ''sole'' and be done with it. In any case, the questions here are whether we require Latin names and whether we support multiple names for each font. 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. 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. A third possibility is to present each font multiple times, once for each supported language. A tag in the pattern would mark the languages for each entry so that listing would be able to filter out names appropriately. The biggest issue here is the elimination of duplicate names by somehow identifying the entries cooresponding to the same font. I think the combination of file name and font index should suffice, but it would place a significant burden on applications to perform this elision manually. If anyone else has another alternative, I''d love to hear it. At present, I''m leaning towards either the ''only one name'' solution or the ''all names in one font''. The ''only one name'' solution would be significantly easier to implement and deploy, but seems less friendly to the user. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/8c3fe871/attachment.pgp
Around 12 o''clock on Nov 29, Phil Race wrote:> If the names are used to populate a font menu for example, then > its important that there''s some way to select the name that''s > most appropriate for the user''s locale.(the following is intentionally contentiously dialectic to try and find the best solution) This is surely the case for fonts used to display text in that locale, but I''m not sure as convincing a case can be made for fonts used to display text for other locales. In fact, I would be unsurprised if multi-lingual users would prefer to see each font name presented in the appropriate language; that would certainly make it easier to select useful fonts. Relevant here is the fact that the bulk of the fonts I''ve seen with multiple language names is that they simply add an English name alongside the existing "real" name, presumably so that English-only UIs (like Fontconfig today) can present something to the user. It could be argued that supporting multiple names is unnecessary in this environment; English users are unlikely to want to use these fonts for presenting English text, steering them away by presenting the names so that they can''t read them might actually be considered a feature. Is it not useful to discourage non-Chinese speakers from using the Arphic fonts?> I have come across fonts that have ONLY a Chinese name, > so its impossible to insist on the Latin name being the name. > If the font doesn''t have a Latin name, I don''t know a good solution. > I suppose you could use the postscript name but that''s not really > the right thing from the perspective of the Chinese user.If the postscript name is the only one available in the font, then that''s what fontconfig will use today. I agree that we should figure out how to identify the ''native'' name of the font and try and present that most of the time. This, however, contradicts your suggestion above that we try to present names in the current locale...> We''d end up having to resolve these to file names to see that they were the > same font, and even then I''m not at all sure what we''d do when its a TTC > file.Fontconfig includes both a file name and an ''index'' into the font to identify elements of TTC files, so at least it would be possible (if painful) to identify shared fonts.> So I think providing ''all the names in one font'' is the most useful. > Without that I know we''d not be able to use fontconfig for font > enumeration. We''d have to continue to parse the fonts ourselves > to extract that information.Ok, so the question remains as to whether we should continue to also present the non-native names for the font (assuming we can correctly identify the native names for all fonts).> [[Although so long as only family names are listed, then we need > to do that to extract the full face names too, ie add FC_FACENAME > or similar.]]I''d like to know why the full face names are interesting given the availability of the family and style names. Is there additional information missing here from (some, many, all) fonts? This does point out that we really need to convert the cache file format to something mmap''able so that all applications can share the same pages for this data. That''s a post-2.3 activity though; I''d really like to finish up this release if we can find a good solution to the localized name issue... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/0a7c2512/attachment.pgp
Around 14 o''clock on Nov 29, Phil Race wrote:> But also what I was getting at here was to say "please don''t make > the English name the only name, and probably not even the preferred name". > It sounds like you concur that users probably want font names they > can read.Right. The question is whether we should guide the name presentation by locale or by the "native" language for the font itself. I submit that if we can reasonably reliably determine the native language of the font that we should always present names in this format; multi-lingual users will appreciate the ability to select fonts in the target language and mono-lingual users may well appreciate the identification of fonts not targeted at their language.> But even that although useful is not always what you need. > A font can be commonly specified some times with its English name > and sometimes with its localized name. Imagine a document that has > font names embedded. If it was embedded by someone running in Locale A > and read by someone in Locale B, I wouldn''t want to be unable to find > the font just because the document creator used his preferred name.Again, I agree. Font names must be locale insensitive. That can be effected by either matching against all names or by choosing the ''true'' name in a locale independent fashion. Fontconfig currently selects the latter course; the easiest thing to do would be to simply change how the ''true'' name is selected to identify the native names.> The bulk perhaps but I''ve seen fonts with many localised names. > Perhaps I''ve spent too long looking at windows fonts where they > have names in Spanish, French, etc, etc, for Pan-European fonts > like Arial.Well, there''s our answer then -- pan-european fonts provide an example of fonts which really do have multiple localized names and for which one single name cannot suffice.> I don''t think not having a localized name is a safe way to decide if > a font supports a language. I expect there are perfectly decent Latin > fonts that don''t have an Italian name.(Fontconfig compares a faces Unicode coverage against orthographies for over a hundred languages to determine language coverage)> Having said that, in practice what I do to select as the "preferred name" > is use the first one of : > - Name for user''s language > - English name > - First name in the font (I assume there''s at least one name!)For you, the first two are equivalent. And, for many, the first is not a singleton, but locales provide no way to express a list of languages. I would almost buy using English for the default presentation, but I see no reason not to let the font itself guide the process. Surely it is reasonable, and possibly even preferred, to present a Chinese face as the Chinese name for a user in a Japanese locale (although, perhaps using a Japanese font).> I do the above because at some point you have to have a name .. > the obvious difference from fontconfig is that I ignore the postscript name.Fontconfig is currently desparate for an English (or at least ASCII or Latin-1) name, and for some fonts this was the only such name. I think it''s preferrable to using the file name...> I am curious about the term ''native'' name I''m not sure that there is really > a "distinguished" name. ie in the TrueType font file they are all just > names and its the context in which you use them.I was suggesting (and you provided the Arial counter example) that fonts would have a name in the language for which the font was designed and which would be easily identified. This could be the ''native'' name of the font.> Yes. Full Face names are sometimes not the same string as > Family Name + SPACE + Style NameOk, if this happens some times, then we can add code to store the correct full name when it is not in this form. For cases when the full name *is* in this form, I suggest that we not store the full name separately and expect that applications can construct it themselves.> I can''t remember offhand how frequently this occurs but its something > that can and does happen and we have to deal with it.We can easily compute this once the above code is written. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/4f6a5931/attachment.pgp
Phil Race wrote:>> Relevant here is the fact that the bulk of the fonts I''ve seen with >> multiple language names is that they simply add an English name >> alongside the existing "real" name, presumably so that English-only >> UIs (like Fontconfig today) can present something to the user. > > > The bulk perhaps but I''ve seen fonts with many localised names. > Perhaps I''ve spent too long looking at windows fonts where they > have names in Spanish, French, etc, etc, for Pan-European fonts > like Arial.A quick follow up on my specific comment about Arial in this context where "name" is open to interpretation. "Arial" doesn''t happen to have localised family names (truetype name id 1) - although it could. But it does have localised style names (name id 2) and it does have localised full face names (name id 4). Having more than 2 localised family names is probably "rare". So architecturally its important to support this but it also means that its going to mean that guesswork won''t often be needed to decide which family name is preferred. -phil.
On Mon, 2004-11-29 at 11:29 -0800, Keith Packard wrote:> I''ve had this idea that we must always provide a Latin encoded name for > every font, which immediately requires support for multiple names for the > same font. Today, I''m wondering if it wouldn''t just be easier to provide > a single name for each font and select that name in some straightforward > fashion from the list of available names. I see the identification of the > ''native'' name for the font as a requirement in any case, perhaps we should > simply make ''native'' == ''sole'' and be done with it. In any case, the > questions here are whether we require Latin names and whether we support > multiple names for each font.I select a font in the font dialog, it''s saved in my preferences, I change locale and it stops working? A web page developer lists a font in a stylesheet, and it is only selected for user''s in some locales? An application uses a font name, the next release of the font adds a new translation of the font name into a local language, and the font is no longer found? 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.> 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. 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.> A third possibility is to present each font multiple times, once for each > supported language. A tag in the pattern would mark the languages for > each entry so that listing would be able to filter out names > appropriately. The biggest issue here is the elimination of duplicate > names by somehow identifying the entries cooresponding to the same > font. I think the combination of file name and font index should suffice, > but it would place a significant burden on applications to perform this > elision manually.I''d dislike this one quite a bit. Applications that want to do simple things should be able to do them simply. Plus it sounds hard to do this without causing further memory-footprint and time overhead. Regards Oen -------------- 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://lists.freedesktop.org/archives/fontconfig/attachments/20041129/56f0044f/attachment.pgp
Keith, If the names are used to populate a font menu for example, then its important that there''s some way to select the name that''s most appropriate for the user''s locale. But also we allow an app to say what is the most appropriate name for Locale "X". So we need that tag which says what language a particular name is appropriate for. I have come across fonts that have ONLY a Chinese name, so its impossible to insist on the Latin name being the name. If the font doesn''t have a Latin name, I don''t know a good solution. I suppose you could use the postscript name but that''s not really the right thing from the perspective of the Chinese user. I agree enumerating the fonts multiple times, once for each name would create a burden on apps. We''d end up having to resolve these to file names to see that they were the same font, and even then I''m not at all sure what we''d do when its a TTC file. So I think providing ''all the names in one font'' is the most useful. Without that I know we''d not be able to use fontconfig for font enumeration. We''d have to continue to parse the fonts ourselves to extract that information. [[Although so long as only family names are listed, then we need to do that to extract the full face names too, ie add FC_FACENAME or similar.]] I agree it would probably be helpful to apps if the preferred name were listed first, but identifying it could be tricky If the cache was built as root in the "C" locale as part of some install its possibly not going to give you the right answer. I''m not sure if that''s a real problem but it seems worth mentioning. -phil. Keith Packard wrote:> The TrueType font format (and probably others) permits family and style > names to be provided in multiple languages (using several national > encodings). I''ve wanted to include a mechanism for making these available > to applications for a long time, in fact this remains the only release > blocking feature for fontconfig 2.3. > > I''ve got a couple of mediocre ideas and am searching for more; if we can''t > manage to figure out something sensible, I suggest that we just ship > fontconfig 2.3 without this feature soon. > > I''ve had this idea that we must always provide a Latin encoded name for > every font, which immediately requires support for multiple names for the > same font. Today, I''m wondering if it wouldn''t just be easier to provide > a single name for each font and select that name in some straightforward > fashion from the list of available names. I see the identification of the > ''native'' name for the font as a requirement in any case, perhaps we should > simply make ''native'' == ''sole'' and be done with it. In any case, the > questions here are whether we require Latin names and whether we support > multiple names for each font. > > 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. > > 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. > > A third possibility is to present each font multiple times, once for each > supported language. A tag in the pattern would mark the languages for > each entry so that listing would be able to filter out names > appropriately. The biggest issue here is the elimination of duplicate > names by somehow identifying the entries cooresponding to the same > font. I think the combination of file name and font index should suffice, > but it would place a significant burden on applications to perform this > elision manually. > > If anyone else has another alternative, I''d love to hear it. At present, > I''m leaning towards either the ''only one name'' solution or the ''all names > in one font''. The ''only one name'' solution would be significantly easier > to implement and deploy, but seems less friendly to the user. > > -keith > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fontconfig mailing list > fontconfig@freedesktop.org > http://freedesktop.org/mailman/listinfo/fontconfig
Around 15 o''clock on Nov 29, Owen Taylor wrote:> I select a font in the font dialog, it''s saved in my preferences, > I change locale and it stops working?No, the idea was to identify the ''native'' name for each font and use that everywhere.> An application uses a font name, the next release of the font adds > a new translation of the font name into a local language, and > the font is no longer found?That would be possible, but it seems unlikely that a font would suddenly sprout a ''native'' name when previously it had none. I suppose this could happen is if the font was originally distributed in Type1 format and provided only a Postscript name and then was converted to TrueType and had the native name added. However, this is just as likely to result in a change in the English family name; Type1 fonts often provide only a full face name from which the family must be extracted.> 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.Yes, locale independence is an absolute requirement. But, that doesn''t demand that we use the same language for every font. Identifying the ''native'' name for the font would permit us to have both a canonical name and a suitable presentation for the expected target audience.> But using the ASCII/Latin name as is done currently by FreeType for > the primary name of the font comes close.FreeType doesn''t really identify the ASCII/Latin names correctly. Fontconfig has to grub around in the font to try and identify a suitable candidate. And, Fontconfig currently lacks the ability to transcode names from non-Unicode encodings; dealing with localized names will require the use of iconv.> 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.Yes, I''ve seen this as well. A canvas of font names used on web pages might be useful here to see how prevalent the English names of these fonts are.> > Another possibility is to provide all of the names in the FC_FAMILY pattern > > element. > > Can you do this in a way that isn''t going to break existing applications > that use the listing APIs?I think it''s a requirement that we make it work with existing applications (unless that proves impossible). Pattern elements can contain multiple values; applications (presumably) examine only the first value in each element, so placing the ''right'' name in this location should make things just work. The selection of ''right'' is problematic. While it would be nice to sort these based upon current locale (or lang tag specification), I''d really like to leave things in fixed order and provide a convenience function to extract the ''appropriate'' presentation name in each environment.> > A third possibility is to present each font multiple times > > I''d dislike this one quite a bit. Applications that want to do simple > things should be able to do them simply. Plus it sounds hard to do > this without causing further memory-footprint and time overhead.The appeal here is precisely to avoid the above issue of potential incompatibility. Presenting these fonts multiple times ensures compatibility with existing applications while also permitting changes in applications that would produce better results. But, if the effort for making this acceptable to users is greater than the effort for using a less compatible mechanism, then I suspect we should look elsewhere for a solution. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/70d1fbfc/attachment.pgp
Around 16 o''clock on Nov 29, Owen Taylor wrote:> There are plenty of scripts used by many different languages. What''s > the native name for a Arabic font with Persian, Urdu, and Arabic > names? It probably depends on who created the font...I guess I''m wondering if there really are fonts with multiple localized names, or if fonts appear as I''ve found them with one real name and an English transliteration as used for the the Postscript name. In other words, is this an actual problem? Or just a theoretical limitation. I have no fonts which run counter to my model at present.> What about a font that spans multiple scripts?Right now, I''ve got several such fonts and all provide only an English name.> Doesn''t strike me as unlikely that someone creating a font would start > off with a Latin name and only later figure out how to add additional > names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora > don''t have localized names at all.This does seem more likely; as systems begin to support localized names, I agree that font designers are encouraged to provide them. I think this point, and the related issue of changes in Fontconfig breaking configurations are pretty compelling.> Hmm, I thought I remembered David Turner doing work to give FreeType > reasonable ASCII font name selection.Perhaps this was after Fontconfig had already adopted its current mechanism for locating ASCII names. I do know I found many fonts presented through FreeType without suitable names a few years ago.> My plan for Pango is to only reveal localized names with a specialized > function like pango_font_face_get_display_name(). And maybe magically > make them work if used in font descriptions.I don''t know what ''localized names'' means in this context any longer. If we agree that font matching must use all of the names, and font listing must provide all of the names, then we really just have a list of names (and a cooresponding list of languages). The only priviledged name in this list is the first value in the pattern element; existing applications will end up preferring that in presentations to the user. I suggest that we place the name we want users to see here, we just need to decide whether that''s English or the "preferred" name found in the font itself. I submit that always using English would be a poor choice, and that we instead let font files direct which presentation to use. Systems like Pango could then walk the list of available names and select based on locale or whatever (a simple convenience function that matched a locale/lang could be included in fontconfig).> That''s a very slim idea of "compatibility". A user is going to be > considerably more confused by seeing a font twice, as compared to > seeing it once with a Latin name, I expect. The former is introducing > new weirdness. The former is just leaving current limited functionality > in place.Well, I guess the best plan is then to try the one-font/multiple-names approach and see what breaks. Transcoding the font names from the weird set of encodings used in TrueType files appears likely to be the largest part of the code; I think the remaining bits are relatively simple. There is the issue of where to store the associated language information. I think I can just stick it in a separate element that parallels the family and style names. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/93264cf7/attachment.pgp
Keith, Keith Packard wrote:> Around 12 o''clock on Nov 29, Phil Race wrote: > > >>If the names are used to populate a font menu for example, then >>its important that there''s some way to select the name that''s >>most appropriate for the user''s locale. > > > (the following is intentionally contentiously dialectic to try and find > the best solution) > > This is surely the case for fonts used to display text in that locale, but > I''m not sure as convincing a case can be made for fonts used to display > text for other locales. In fact, I would be unsurprised if multi-lingual > users would prefer to see each font name presented in the appropriate > language; that would certainly make it easier to select useful fonts.Yes, users would want that. But also what I was getting at here was to say "please don''t make the English name the only name, and probably not even the preferred name". It sounds like you concur that users probably want font names they can read. But even that although useful is not always what you need. A font can be commonly specified some times with its English name and sometimes with its localized name. Imagine a document that has font names embedded. If it was embedded by someone running in Locale A and read by someone in Locale B, I wouldn''t want to be unable to find the font just because the document creator used his preferred name.> > Relevant here is the fact that the bulk of the fonts I''ve seen with > multiple language names is that they simply add an English name alongside > the existing "real" name, presumably so that English-only UIs (like > Fontconfig today) can present something to the user.The bulk perhaps but I''ve seen fonts with many localised names. Perhaps I''ve spent too long looking at windows fonts where they have names in Spanish, French, etc, etc, for Pan-European fonts like Arial. English names are a fairly pragmatic fall back as an alternative to (say) a Chinese name for a Chinese font. I can''t think of all the reasons but they probably include that the font developers themselves often read English, so prefer that over (say) a German name, and expect being able to recognize latin characters is fairly widespread and they very probably also included Latin glyphs in the font, so they know its displayable by their own font - I suspect most fonts like to have the right code points to display all their own names .. of course barcode fonts don''t etc .> > It could be argued that supporting multiple names is unnecessary in this > environment; English users are unlikely to want to use these fonts for > presenting English text, steering them away by presenting the names so that > they can''t read them might actually be considered a feature. Is it not useful > to discourage non-Chinese speakers from using the Arphic fonts?As I noted above, presentation of the name in the language a user will recognize is important, but also important is being able to quickly match a name obtained from some archived source against all known localised names. That''s not really for subsequent user presentation of the font name, its for selecting the intended font for some other usage such as displaying text using that font. I don''t think not having a localized name is a safe way to decide if a font supports a language. I expect there are perfectly decent Latin fonts that don''t have an Italian name.> > >>I have come across fonts that have ONLY a Chinese name, >>so its impossible to insist on the Latin name being the name. >>If the font doesn''t have a Latin name, I don''t know a good solution. >>I suppose you could use the postscript name but that''s not really >>the right thing from the perspective of the Chinese user. > > > If the postscript name is the only one available in the font, then that''s > what fontconfig will use today. I agree that we should figure out how to > identify the ''native'' name of the font and try and present that most of > the time. This, however, contradicts your suggestion above that we try to > present names in the current locale...I didn''t intend it to contradict this. Its a different case. If there is no name for this locale then should you synthesise one? If a font has only a Chinese name than a Postscript name may be a reasonable fall back for languages using Latin, but a postscript name in Latin is not always interesting to an Arabic reader. Having said that, in practice what I do to select as the "preferred name" is use the first one of : - Name for user''s language - English name - First name in the font (I assume there''s at least one name!) I do the above because at some point you have to have a name .. the obvious difference from fontconfig is that I ignore the postscript name.> > >>We''d end up having to resolve these to file names to see that they were the >>same font, and even then I''m not at all sure what we''d do when its a TTC >>file. > > > Fontconfig includes both a file name and an ''index'' into the font to > identify elements of TTC files, so at least it would be possible (if > painful) to identify shared fonts. > > >>So I think providing ''all the names in one font'' is the most useful. >>Without that I know we''d not be able to use fontconfig for font >>enumeration. We''d have to continue to parse the fonts ourselves >>to extract that information. > > > Ok, so the question remains as to whether we should continue to also > present the non-native names for the font (assuming we can correctly > identify the native names for all fonts).I am curious about the term ''native'' name I''m not sure that there is really a "distinguished" name. ie in the TrueType font file they are all just names and its the context in which you use them.> > >>[[Although so long as only family names are listed, then we need >>to do that to extract the full face names too, ie add FC_FACENAME >>or similar.]] > > > I''d like to know why the full face names are interesting given the > availability of the family and style names. Is there additional > information missing here from (some, many, all) fonts?Yes. Full Face names are sometimes not the same string as Family Name + SPACE + Style Name and : - We need to support API which lists all the face names - We need to support cases where a full face name has been specified and we need to locate the corresponding font. I can''t remember offhand how frequently this occurs but its something that can and does happen and we have to deal with it. -phil.> > This does point out that we really need to convert the cache file format > to something mmap''able so that all applications can share the same pages > for this data. That''s a post-2.3 activity though; I''d really like to > finish up this release if we can find a good solution to the localized > name issue... > > -keith > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > fontconfig mailing list > fontconfig@freedesktop.org > http://freedesktop.org/mailman/listinfo/fontconfig
On Mon, 2004-11-29 at 12:52 -0800, Keith Packard wrote:> Around 15 o''clock on Nov 29, Owen Taylor wrote: > > > I select a font in the font dialog, it''s saved in my preferences, > > I change locale and it stops working? > > No, the idea was to identify the ''native'' name for each font and use that > everywhere.There are plenty of scripts used by many different languages. What''s the native name for a Arabic font with Persian, Urdu, and Arabic names? It probably depends on who created the font... What about a font that spans multiple scripts?> > An application uses a font name, the next release of the font adds > > a new translation of the font name into a local language, and > > the font is no longer found? > > That would be possible, but it seems unlikely that a font would suddenly > sprout a ''native'' name when previously it had none. I suppose this could > happen is if the font was originally distributed in Type1 format and > provided only a Postscript name and then was converted to TrueType and had > the native name added. However, this is just as likely to result in a > change in the English family name; Type1 fonts often provide only a full > face name from which the family must be extracted.Doesn''t strike me as unlikely that someone creating a font would start off with a Latin name and only later figure out how to add additional names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora don''t have localized names at all. If people start adding them, should things break?> > 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. > > Yes, locale independence is an absolute requirement. But, that doesn''t > demand that we use the same language for every font. Identifying the > ''native'' name for the font would permit us to have both a canonical name > and a suitable presentation for the expected target audience.I think that''s an elusive concept.> > But using the ASCII/Latin name as is done currently by FreeType for > > the primary name of the font comes close. > > FreeType doesn''t really identify the ASCII/Latin names correctly. > Fontconfig has to grub around in the font to try and identify a suitable > candidate. And, Fontconfig currently lacks the ability to transcode names > from non-Unicode encodings; dealing with localized names will require > the use of iconv.Hmm, I thought I remembered David Turner doing work to give FreeType reasonable ASCII font name selection.> > 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. > > Yes, I''ve seen this as well. A canvas of font names used on web pages > might be useful here to see how prevalent the English names of these fonts > are. > > > > Another possibility is to provide all of the names in the FC_FAMILY pattern > > > element. > > > > Can you do this in a way that isn''t going to break existing applications > > that use the listing APIs? > > I think it''s a requirement that we make it work with existing applications > (unless that proves impossible). Pattern elements can contain multiple > values; applications (presumably) examine only the first value in each > element, so placing the ''right'' name in this location should make things > just work. > > The selection of ''right'' is problematic. While it would be nice to sort > these based upon current locale (or lang tag specification), I''d really > like to leave things in fixed order and provide a convenience function to > extract the ''appropriate'' presentation name in each environment.My plan for Pango is to only reveal localized names with a specialized function like pango_font_face_get_display_name(). And maybe magically make them work if used in font descriptions. Reordering based on locale seems like making things hard for everybody.> > > A third possibility is to present each font multiple times > > > > I''d dislike this one quite a bit. Applications that want to do simple > > things should be able to do them simply. Plus it sounds hard to do > > this without causing further memory-footprint and time overhead. > > The appeal here is precisely to avoid the above issue of potential > incompatibility. Presenting these fonts multiple times ensures > compatibility with existing applications while also permitting changes in > applications that would produce better results.That''s a very slim idea of "compatibility". A user is going to be considerably more confused by seeing a font twice, as compared to seeing it once with a Latin name, I expect. The former is introducing new weirdness. The former is just leaving current limited functionality in place. Regards, Owen -------------- 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://lists.freedesktop.org/archives/fontconfig/attachments/20041129/ee14e44e/attachment.pgp
Around 21 o''clock on Nov 30, Ambrose Li wrote:> This is not necessarily desirable. Sometimes I want to see the > English names of Chinese fonts in a Chinese locale, if not > just for the sake of consistency (of moving documents between > locales).Right, so letting the application choose which names to present seems like the only workable solution. I will provide a convenience API for applications to locate a "reasonable" name to present, given a specific lang value (or NULL, indicating current locale), but applications will be free to walk the list of available names and choose their own if they like. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/b97f284d/attachment.pgp
>I''m not planning on reordering the list returned to applications; is there >some reason it should?By reordering the list and adding a global flag in configure file, legacy applications can use localised family name. (if using of localised name is proved to be feasible.) Xie Qian Open System and Chinese Information Processing Center, Institute of Software, Chinese Academy of Sciences, P.O. Box 8718, Beijing 100080, CHINA ----- Original Message ----- From: "Keith Packard" <keithp@keithp.com> To: "Xie Qian" <xieqian02@iscas.cn> Cc: <fontconfig@freedesktop.org>; "Keith Packard" <keithp@keithp.com> Sent: Wednesday, December 01, 2004 1:39 PM Subject: Re: [Fontconfig] Localizing font family and style names
Keith Packard wrote:> Around 15 o''clock on Nov 29, Phil Race wrote: > > >>"Arial" doesn''t happen to have localised family names >>(truetype name id 1) - although it could. >>But it does have localised style names (name id 2) and it does have >>localised full face names (name id 4). > > > I was trying to be careful to use ''name'' to cover all instances of textual > data provided by the font and expected to be presented to the user, but I > admit to constant conflation between family name and ''name''. > > I think the only difference may be that documents will more often encode > family names than style names, but otherwise they''re pretty much > equivalent. > > Oh, in the world of full face names, do you need to be able to match (not > list, but match) fonts based on full name? It seems likely, but I wanted > to check as that may take some thought...I have to say yes, since we have succumbed to the same blurring of what a name is and are stuck with it. So we have to assume that what ever char*/string is given as the name maybe legitimate as one or the other and do our best to find it as both before trying anything else. -Phil.> > -keith > >
Around 15 o''clock on Nov 29, Phil Race wrote:> "Arial" doesn''t happen to have localised family names > (truetype name id 1) - although it could. > But it does have localised style names (name id 2) and it does have > localised full face names (name id 4).I was trying to be careful to use ''name'' to cover all instances of textual data provided by the font and expected to be presented to the user, but I admit to constant conflation between family name and ''name''. I think the only difference may be that documents will more often encode family names than style names, but otherwise they''re pretty much equivalent. Oh, in the world of full face names, do you need to be able to match (not list, but match) fonts based on full name? It seems likely, but I wanted to check as that may take some thought... -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041129/bfa4d0fc/attachment.pgp
Around 22 o''clock on Nov 29, Phil Race wrote:> I have to say yes, since we have succumbed to the same blurring of what > a name is and are stuck with it. So we have to assume that what ever > char*/string is given as the name maybe legitimate as one or the other > and do our best to find it as both before trying anything else.You want me to take a "family" name as provided by the user and attempt to match it against a full name? I''m not sure that''s necessary; these names come from applications, not users (in general), and I think we need to expect that application developers can distinguish between the two. Conflating these in our API seems only to compound an existing problem. What I was actually asking was whether you wanted me to permit applications to supply full names (as an FC_FULLNAME pattern element) and match them against the full names in the fonts as a separate match from family and style names. This would allow applications to use full names in place of family and style names. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/a0fd6354/attachment.pgp
On Tue, Nov 30, 2004 at 09:43:10AM -0800, Keith Packard wrote:> So what happens when you move a document from a zh_CN locale > to en_US? Does the system still manage to locate the right > fonts?IIRC, in Windows, the system does somehow manage to locate the right fonts.> I suggest that for our purposes, we must be able to store > either family name in the file and match that correctly in any > locale. > > > They want to see the localized font name (preferably in > > the language of the font, ie. a chinese font should have a > > chinese name). > > To me, ''Localized'' is a technical term which means ''present > according to $LANG'', which isn''t always the same as ''Chinese > font given Chinese name''; I''d like to see the Chinese family > names even in the en_US locale.This is not necessarily desirable. Sometimes I want to see the English names of Chinese fonts in a Chinese locale, if not just for the sake of consistency (of moving documents between locales). I know at least 1 (at least 2 if I remember correctly) professional layout programs that allows this on MacOS, so I am certainly not strange in wanting this option.
Around 11 o''clock on Dec 1, "Xie Qian" wrote:> IMO, using the order in the font may not produce a desirable result. As the > order of different name will affect application''s font listing manner > rather than actual font matching, why don''t let applications decide which > order is appropriate?The application will get an element containing all of the names and can pick among them at will. The ordering only affects na?ve clients which will use the first in the list. I''m not planning on reordering the list returned to applications; is there some reason it should? -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/8dc72981/attachment.pgp
Around 14 o''clock on Dec 1, "Xie Qian" wrote:> By reordering the list and adding a global flag in configure file, legacy > applications can use localised family name. (if using of localised name > is proved to be feasible.)I think there are few enough ''legacy'' fontconfig applications that we might wait and see if this is really necessary. I dislike weird global functions which change behaviour in non-transparent ways like this. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/886142fa/attachment.pgp
?2004?11?30??06:12?Keith Packard???> Around 16 o''clock on Nov 29, Owen Taylor wrote: > > > There are plenty of scripts used by many different languages. What''s > > the native name for a Arabic font with Persian, Urdu, and Arabic > > names? It probably depends on who created the font... > > I guess I''m wondering if there really are fonts with multiple localized > names, or if fonts appear as I''ve found them with one real name and an > English transliteration as used for the the Postscript name. In other > words, is this an actual problem? Or just a theoretical limitation. I > have no fonts which run counter to my model at present. > > > What about a font that spans multiple scripts? > > Right now, I''ve got several such fonts and all provide only an English > name. > > > Doesn''t strike me as unlikely that someone creating a font would start > > off with a Latin name and only later figure out how to add additional > > names. Other than CJK fonts, most of the fonts we ship with RHEL/Fedora > > don''t have localized names at all. > > This does seem more likely; as systems begin to support localized names, I > agree that font designers are encouraged to provide them. I think this > point, and the related issue of changes in Fontconfig breaking > configurations are pretty compelling. > > > Hmm, I thought I remembered David Turner doing work to give FreeType > > reasonable ASCII font name selection. > > Perhaps this was after Fontconfig had already adopted its current mechanism > for locating ASCII names. I do know I found many fonts presented through > FreeType without suitable names a few years ago. > > > My plan for Pango is to only reveal localized names with a specialized > > function like pango_font_face_get_display_name(). And maybe magically > > make them work if used in font descriptions. > > I don''t know what ''localized names'' means in this context any longer. If > we agree that font matching must use all of the names, and font listing > must provide all of the names, then we really just have a list of names > (and a cooresponding list of languages). > > The only priviledged name in this list is the first value in the pattern > element; existing applications will end up preferring that in presentations > to the user. I suggest that we place the name we want users to see here, > we just need to decide whether that''s English or the "preferred" name found > in the font itself. I submit that always using English would be a poor > choice, and that we instead let font files direct which presentation to > use. Systems like Pango could then walk the list of available names and > select based on locale or whatever (a simple convenience function that > matched a locale/lang could be included in fontconfig).With the simple convenience function, it would be pretty convenient for high-level application to present ''preferred'' name/list to end user. but i am curious how we can implement it in fontconfig. In my understanding, Given one locale/lang, besides the lang set, the other information that fontconfig can rely on to decide the ''preferred'' name/list is the CodePageRange data in OS/2 table. it would works well for CJK font as the bit 18-20 will be always set in CJK TT font to address UniHan issue, but not sure for other fonts. Maybe you can use the platform id/encoding id if the font isn''t Unicode based, but you still have to use iconv API to convert their ''preferred'' name to UTF8. Just for reference. Currently the workaround that can be made in Pango is: check the value beyond 0 in the FC_FAMILY element if fontconfig can put those native name into the element by fixing in fcfreetype.c, if it exists, with the current lang tag, check whether the font contains the tag in its lang set with FcLangSetHasLang, if yes, present its native name to gtk font selection dialog. but its limitation is: it doesn''t work for some font that contains so much scripts, as a result, family name in korean would be presented in either ''de'' or ''fr'' locale because the korean font contains all ''de'' and ''fr'' characters. The desired sceranis is that we present APPROPRIATE and MEANINGFUL name to *END USER*, i.e chinese name in chinese locale. if my understanding is correct, we wouldn''t expect germeny user will like korean name, right? As for matching function, given either lation or native name, fontconfig already matchs well with current implementation, i mean ''provide all of names in the FC_FAMILY pattern element, don''t understand why there exists any back-compatibility issue. Anyway, thanks a lot for your effort, Lars said ''it seems to be pretty important feature for them'', actually IT IS. -federic> > That''s a very slim idea of "compatibility". A user is going to be > > considerably more confused by seeing a font twice, as compared to > > seeing it once with a Latin name, I expect. The former is introducing > > new weirdness. The former is just leaving current limited functionality > > in place. > > Well, I guess the best plan is then to try the one-font/multiple-names > approach and see what breaks. Transcoding the font names from the weird > set of encodings used in TrueType files appears likely to be the largest > part of the code; I think the remaining bits are relatively simple. > > There is the issue of where to store the associated language information. > I think I can just stick it in a separate element that parallels the > family and style names. > > -keith > > > > ______________________________________________________________________ > _______________________________________________ > fontconfig mailing list > fontconfig@freedesktop.org > http://freedesktop.org/mailman/listinfo/fontconfig
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://lists.freedesktop.org/archives/fontconfig/attachments/20041130/8af2f331/attachment.pgp
IMO, using the order in the font may not produce a desirable result. As the
order of different name will affect application''s font listing manner
rather than
actual font matching, why don''t let applications decide which order is
appropriate?
I mean add a function to set preferred listing order, with following options:
FC_LIST_LATIN_FISRT(list Latin name first)
FC_LIST_NATIVE_FISRT(list native name first)
FC_LIST_LOCALE_FISRT(as user''s locale setting)
FC_LIST_ORIGINAL(as in the font file)
To achieve backward compatibility, just set FC_LIST_LATIN_FISRT as default.
Xie Qian
Open System and Chinese Information Processing Center,
Institute of Software, Chinese Academy of Sciences,
P.O. Box 8718, Beijing 100080, CHINA
----- Original Message -----
From: "Keith Packard"
<keithp@keithp.com>>Around 11 o''clock on Nov 30, Owen Taylor wrote:
>
>> 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.
>
>I think just stuffing them as additional values in the same element should
>work just fine; I don''t expect existing applications ever look
beyond
>value 0. We can give this a try in the development branch of fontconfig
>and see if any serious issues crop up. If so, we''ll have to go
back and
>rethink the whole issue. Placing the names in another element will
>greatly complicated the already arcane matching algorithm.
>
>The question then becomes what value gets to live in position 0. I suggest
>that we accept the font designers whim and just order the names in the same
>way they appear in the font. This would assume the font designer had some
>intent as to the ''preferred'' name for the font and placed
it first.
>
>> (*) 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().
>
>I think it''s all the same problem, except that applications will
generally
>want to provide the localized name for styles while I think they should
>provide the ''natural'' name of the font.
>
>-keith
>
Keith, > You want me to take a "family" name as provided by the user and attempt to > match it against a full name? I''m not sure that''s necessary; these names No. I didn''t mean that. I was trying to describe that because in our code we accept both we need to be able to enumerate both so that we can try to match first as a face name and if that fails as a family name. That''s application level behaviour (my code). I don''t expect, or think it right that fontconfig get into the same predicament of doing this automatically and as you say conflating the two. A clear separation of the two is better. > What I was actually asking was whether you wanted me to permit applications > to supply full names (as an FC_FULLNAME pattern element) and match them > against the full names in the fonts as a separate match from family and > style names. Yes, that''s it. FC_FULLNAME is a distinct pattern element -phil. Keith Packard wrote:> Around 22 o''clock on Nov 29, Phil Race wrote: > > >>I have to say yes, since we have succumbed to the same blurring of what >>a name is and are stuck with it. So we have to assume that what ever >>char*/string is given as the name maybe legitimate as one or the other >>and do our best to find it as both before trying anything else. > > > You want me to take a "family" name as provided by the user and attempt to > match it against a full name? I''m not sure that''s necessary; these names > come from applications, not users (in general), and I think we need to > expect that application developers can distinguish between the two. > Conflating these in our API seems only to compound an existing problem. > > What I was actually asking was whether you wanted me to permit applications > to supply full names (as an FC_FULLNAME pattern element) and match them > against the full names in the fonts as a separate match from family and > style names. This would allow applications to use full names in place of > family and style names. > > -keith > >
On Monday 29 November 2004 21:31, Owen Taylor wrote:> On Mon, 2004-11-29 at 11:29 -0800, Keith Packard wrote: > > I''ve had this idea that we must always provide a Latin encoded name for > > every font, which immediately requires support for multiple names for the > > same font. Today, I''m wondering if it wouldn''t just be easier to provide > > a single name for each font and select that name in some straightforward > > fashion from the list of available names. I see the identification of > > the ''native'' name for the font as a requirement in any case, perhaps we > > should simply make ''native'' == ''sole'' and be done with it. In any case, > > the questions here are whether we require Latin names and whether we > > support multiple names for each font. > > I select a font in the font dialog, it''s saved in my preferences, > I change locale and it stops working? > > A web page developer lists a font in a stylesheet, and it is only > selected for user''s in some locales? > > An application uses a font name, the next release of the font adds > a new translation of the font name into a local language, and > the font is no longer found? > > 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). 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.> > 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. English names for asian fonts are often pretty bad and from what I know it''s very hard to pick the correct one based on the latin name. We had lots of requests for localized font names in asian locales in the past and it seems to be a pretty important feature for them.> > A third possibility is to present each font multiple times, once for each > > supported language. A tag in the pattern would mark the languages for > > each entry so that listing would be able to filter out names > > appropriately. The biggest issue here is the elimination of duplicate > > names by somehow identifying the entries cooresponding to the same > > font. I think the combination of file name and font index should > > suffice, but it would place a significant burden on applications to > > perform this elision manually. > > I''d dislike this one quite a bit. Applications that want to do simple > things should be able to do them simply. Plus it sounds hard to do > this without causing further memory-footprint and time overhead.I agree. The best solution IMO is the following: Listing fonts should probably give either the localized or the latin name with the possibilty of retrieving the other one as well. Font matching should try both (or all if the font has several) names, as you otherwise will run in some trouble with documents created on Windows. Cheers, Lars
Around 13 o''clock on Dec 1, Federic Zhang wrote:> In my understanding, Given one locale/lang, besides the lang set, the other > information that fontconfig can rely on to decide the ''preferred'' name/list > is the CodePageRange data in OS/2 table.The other two pieces of potentially relevant information is the language coverage that fontconfig computes and the order in which the names appear in the font file. I need to do some investigation, but I''d sure like to be able to reasonably expect that font designers place the ''preferred'' names first in the file, leaving the transformed Postscript names for later entries. Fontconfig already uses the code page range bits to disambiguate among Han fonts for preferred languages, unfortunately, the code page range data is rather limited, and also somewhat ambiguous, in the list of marked languages, so we can''t really use that as the sole source of language information.> The desired sceranis is that we present APPROPRIATE and MEANINGFUL name to > *END USER*, i.e chinese name in chinese locale. if my understanding is > correct, we wouldn''t expect germeny user will like korean name, right?We want to provide the name which helps the user best select fonts. For monolingual users in Germany, we may well want to display names of Korean fonts in Korean -- that will rather strongly discourage the user from selecting these inappropriately. For a multi-lingual user in France, again, we may well want to present these names in Korean as they might be easier to discern among multiple Korean fonts than when using the French translated name. Or, as Ambrose Li suggests, we may want to present the names in English to both of these users as those names are what the user is attempting to locate. As I don''t think we can answer this question here, I submit that Fontconfig better just provide all of the names back to the application and let someone else sort it all out.> Anyway, thanks a lot for your effort, Lars said ''it seems to be pretty important > feature for them'', actually IT IS.Right, I''ve been delaying release 2.3 until I could resolve this issue. It''s now getting a bit ridiculous that I haven''t managed to do a release in so long, so I''m trying to spend a few days to finish this up. Thanks to everyone for participating; I''m hoping to have a sample implementation done in a short while. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/ede36547/attachment.pgp
Around 10 o''clock on Nov 30, Lars Knoll wrote:> 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.So what happens when you move a document from a zh_CN locale to en_US? Does the system still manage to locate the right fonts? I suggest that for our purposes, we must be able to store either family name in the file and match that correctly in any locale.> They want to see the localized font name (preferably in the language of the > font, ie. a chinese font should have a chinese name).To me, ''Localized'' is a technical term which means ''present according to $LANG'', which isn''t always the same as ''Chinese font given Chinese name''; I''d like to see the Chinese family names even in the en_US locale. In contrast, Phil Race pointed out that the Arial fonts provide multi lingual style names. I think applications should present style names in localized form if possible, so in a vi_VN locale, I would expect to see Arial as the family name and th???ng as the style name for the Arial roman face. However, I think fontconfig should present information in a locale-neutral fashion and let the UI designers decide how to present the data. Any attempts to do otherwise will probably only end up annoying application developers.> Listing fonts should probably give either the localized or the latin name > with the possibilty of retrieving the other one as well. Font matching > should try both (or all if the font has several) names, as you otherwise > will run in some trouble with documents created on Windows.Ok, I think we can do that. Listing will provide all of the family names and let you pick the one you want to present. Each name may have an associated set of locales. Matching will treat each family name identically; a name in the pattern will be tested against all of the family names found in the font. Lemme code some stuff up and see what it looks like. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/76236aef/attachment.pgp
Around 11 o''clock on Nov 30, Owen Taylor wrote:> 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.I think just stuffing them as additional values in the same element should work just fine; I don''t expect existing applications ever look beyond value 0. We can give this a try in the development branch of fontconfig and see if any serious issues crop up. If so, we''ll have to go back and rethink the whole issue. Placing the names in another element will greatly complicated the already arcane matching algorithm. The question then becomes what value gets to live in position 0. I suggest that we accept the font designers whim and just order the names in the same way they appear in the font. This would assume the font designer had some intent as to the ''preferred'' name for the font and placed it first.> (*) 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().I think it''s all the same problem, except that applications will generally want to provide the localized name for styles while I think they should provide the ''natural'' name of the font. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/fdae49d0/attachment.pgp
Around 9 o''clock on Nov 30, Phil Race wrote:> Yes, that''s it. FC_FULLNAME is a distinct pattern elementPhew. That will be easy then. It seems like you have a particular interest in this aspect of the system; would it be possible for you to look into doing the implementation of this change? I''d like to concentrate on the multi-lingual FC_FAMILY/FC_STYLE changes. -keith -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available Url : http://lists.freedesktop.org/archives/fontconfig/attachments/20041130/c49ed3f8/attachment.pgp