Hi,
I''ve added a major vendor name (in Japan possibly), Motoya
- http://www.motoyafont.jp/ in src/fcfreetype.c, modified source
code warning-clean. Although, I don''t know how to work this vendor
string in the mechanism.
...Now, the true story starts from here. I''ve been having trouble
on font recognition/selection mechanism, just after reading Keith''s
interesting post has subject ''Localizing font family and style
names'', I''d report it can be the matter that displaying local
family
name encoded local charset, in a little different aspect though. If
it was a known problem, sorry in advance.
In this case, I''d target local family name in the .ttc font. Ok,
I''ve
got the fonts of Windows version, there are three different weighted
fonts ntk2kp.ttc, ntk3kp.ttc, ntk4kp.ttc, have three style variants
W#, W# KP, W# mono in each itself, the crucial point is, those fonts
have just only *one* font family name in English-wise.
Further, those fonts have local family name (Japanese) in 1st, 2nd
name field, but name of 1st field never read in my environment
due to codeset, seems ShiftJIS while EUC-JP of mine. 2nd has UTF-8
encoded, can be displayed properly.
Thus, fc-list says (sorry long & hard to read lines)
NtMotoyaKyotai,NT(can''t read!)2,*NTMotoyaKyokasho2:style=W2,Regular
NtMotoyaKyotai,NT(ditto)2KP,*NTMotoyaKyokasho2KP:style=W2 KP,Regular
NtMotoyaKyotai,NT(ditto)2(ditto),*NTMotoyaKyokasho2Touhaba:style=W2
mono,Regular
NtMotoyaKyotai,NT(ditto)3,*NTMotoyaKyokasho3:style=W3,Regular
NtMotoyaKyotai,NT(ditto)3KP,*NTMotoyaKyokasho3KP:style=W3 KP,Regular
NtMotoyaKyotai,NT(ditto)3(ditto),*NTMotoyaKyokasho3Touhaba:style=W3
mono,Regular
NtMotoyaKyotai,NT(ditto)4,*NTMotoyaKyokasho4:style=W4,Regular
NtMotoyaKyotai,NT(ditto)4KP,*NTMotoyaKyokasho4KP:style=W4 KP,Regular
NtMotoyaKyotai,NT(ditto)4(ditto),*NTMotoyaKyokasho4Touhaba:style=W4
mono,Regular
* actually Japanese without NT, #(KP)
On the font selection, I can select family ''NtMotoyaKyotai''
certainly,
also style ''W2, W2 KP, W2 mono...'' *appear* in random order.
However
a style never affect! There must be selected one of those (of total
9 variants).
I called font vendor, an company employee says ''That''s because
certain application''d select font family at first, then user select
one of font families with style, at that time you can see localized
name. I''m afraid there is no specification concerned with naming rule,
we''ll just follow major application''s usage custom. We can
change
inner English family name itself for you, however it costs. Anyway,
it''s ok changing font recognition method on your side.''
...long post, thank you for your reading! well, is there any person
having similar trouble? Is that commonly on non-Latin fonts (including
CJKVT)? I''ll welcome your comment, any workaround wlii be appreciated.
PS. Those fonts need registration, I can''t give you an actual copy.
If you want to try that, please email me, I''ll explain how to register.
Regards,
--
Daichi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: addtional_vendor.patch.gz
Type: application/x-gzip
Size: 2814 bytes
Desc: not available
Url :
http://lists.freedesktop.org/archives/fontconfig/attachments/20050225/914ce6f2/addtional_vendor.patch.bin
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Kochi Mincho causes segfault (was Re: Multi lingual fontconfig names)
On Fri, 25 Feb 2005 21:03:15 -0800 Keith Packard wrote:> you can see that the name ''Kochi Mincho'' has no specific languageI remember now... it was happened when I had updated to this version 2.2.99. GNU libiconv 1.9.2 with --enable-extra-encodings, FreeType2 9.8.3 (CVS), here they are: # fc-cache -v fc-cache: "/usr/local/share/fonts/opentype": skipping, 4 fonts, 0 dirs fc-cache: "/usr/local/share/fonts/truetype": skipping, 3 fonts, 12 dirs fc-cache: "/usr/local/share/fonts/truetype/thai": skipping, 12 fonts, 0 dirs fc-cache: "/usr/local/share/fonts/truetype/japanese": Bus error $ gdb fc-cache core [...] #0 libiconv (icd=0xffffffff, inbuf=0x10018c68, inbytesleft=0x7ffd7a2c, outbuf=0x7ffd7a30, outbytesleft=0x7ffd7a34) at iconv.c:426 426 return cd->lfuncs.loop_convert(icd, (gdb) bt #0 libiconv (icd=0xffffffff, inbuf=0x10018c68, inbytesleft=0x7ffd7a2c, outbuf=0x7ffd7a30, outbytesleft=0x7ffd7a34) at iconv.c:426 #1 0x5ffc82f0 in FcFreeTypeQuery (file=0x10016f30 "/usr/local/share/fonts/truetype/japanese/kochi-mincho.ttf", id=0, blanks=0x1001d400, count=0x10075248) at fcfreetype.c:626 #2 0x5ffc574c in FcFileScanConfig (set=0x1001d418, dirs=0x10018cc0, cache=0x0, blanks=0x1001d400, file=0x10016f30 "/usr/local/share/fonts/truetype/japanese/kochi-mincho.ttf", force=0, config=0x0) at fcdir.c:117 #3 0x5ffc5ca0 in FcDirScanConfig (set=0x1001d418, dirs=0x10018cc0, cache=0x0, blanks=0x1001d400, dir=0x10019788 "/usr/local/share/fonts/truetype/japanese" , force=0, config=0x0) at fcdir.c:240 #4 0x10001d88 in scanDirs (list=0x10020dd8, config=0x10015008, program=0x7ffd8000 "fc-cache", force=0, verbose=1) at fc-cache.c:179 #5 0x10001df8 in scanDirs (list=0x10015278, config=0x10015008, program=0x7ffd8000 "fc-cache", force=0, verbose=1) at fc-cache.c:210 #6 0x10002254 in main (argc=268522104, argv=0x7ffd7e84) at fc-cache.c:291 (gdb) l 291 ret = scanDirs (list, config, argv[0], force, verbose); 292 /* 293 * Now we need to sleep a second (or two, to be extra sure), to make 294 * sure that timestamps for changes after this run of fc-cache are later 295 * then any timestamps we wrote. We don''t use gettimeofday() because 296 * sleep(3) can''t be interrupted by a signal here -- this isn''t in the 297 * library, and there aren''t any signals flying around here. 298 */ 299 sleep (2); 300 if (verbose) Regards, -- Daichi
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Multi lingual fontconfig names (was [PATCH] Additional vendor string)
On Fri, 25 Feb 2005 17:44:03 +0900 Daichi Kawahata wrote:> Further, those fonts have local family name (Japanese) in 1st, > 2nd name field, but name of 1st field never read in my environment > due to codeset, seems ShiftJIS while EUC-JP of mine. 2nd has UTF-8 > encoded, can be displayed properly.Ok, I''ve read ''Early results with multi lingual fontconfig names'' also. I''ve confirmed with ''$ fc-list : family familylang | grep ,'' that previous mentioned font tagged with ''familylang=en,ja,ja'' properly. As a first step, I''d know if fontconfig has option that I can specify codeset of each languages (even on same language code) other than assuming themselves to UTF-8!? in inner fontname-wise. There seems few documents about family/style/fullnamelang. Could you tell me the right direction? PS. I''ve forgoten, version of fontconfig is 2.2.99 on IRIX 6.5. Regards, -- Daichi
Keith Packard
2005-Nov-21 08:51 UTC
[Fontconfig] Multi lingual fontconfig names (was [PATCH] Additional vendor string)
Around 11 o''clock on Feb 26, Daichi Kawahata wrote:> As a first step, I''d know if fontconfig has option that I can specify > codeset of each languages (even on same language code) other than > assuming themselves to UTF-8!? in inner fontname-wise.Fontconfig transcodes names it finds in TrueType files into UTF-8, so everything should be Unicode from the applications perspective. If the font is lying about the encoding used in the TrueType file, there''s not a whole lot FontConfig can do about it.> There seems few documents about family/style/fullnamelang. Could > you tell me the right direction?Sorry, I haven''t added these to the documentation yet. These three properties indicate the language for the same index in the associated family/style/fullname property. So, for the font: family Kochi Mincho,???? familylang xx,ja you can see that the name ''Kochi Mincho'' has no specific language (indicated with the ''xx'' tag), and the name ''????'' is Japanese Similarly, the Verdana font has many style names: style Regular,Normal,oby?ejn?,Standard,????????,Normaali, Norm?l,Normale,Standaard,Normalny,???????,Norm?lne, Navadno,Arrunta stylelang en,ca,cs,de,el,fi, hu,it,nl,pl,ru,sk, sl,eu Regular is English, Normal is Catalan, oby?ejn? is Czech, etc. When there is only one family/style/fullname, fontconfig doesn''t bother to create the associated family/style/fullnamelang property. What we don''t have in fontconfig (yet) is any kind of helper function to select a name given a set of language tags. I''d love to see suggestions for how that should work posted here. -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/20050225/41cc8980/attachment.pgp
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Re: Multi lingual fontconfig names (was [PATCH] Additional vendor string)
On Fri, 25 Feb 2005 21:03:15 -0800 Keith Packard wrote:> Fontconfig transcodes names it finds in TrueType files into UTF-8, > so everything should be Unicode from the applications perspective. > If the font is lying about the encoding used in the TrueType file, > there''s not a whole lot FontConfig can do about it.Is there any possibility the following (Kanji reading: Kyo-ka-sho, meaning: textbook, font for textbook) NtMotoyaKyotai,NT???g????????2,NT??????2:familylang=en,ja,ja NtMotoyaKyotai,NT???g????????2KP,NT??????2KP:familylang=en,ja,ja NtMotoyaKyotai,NT???g????????2????,NT??????2??:familylang=en,ja,ja recognize correctly in 2nd name field (don''t worry, I can''t read either) with following API FontConfig GNOME/KDE etc. LOCAL FONT -> FcLocaleToUtf8() -> High Level API -> USER LOCAL FONT <- FcLocaleFromUtf8() <- High Level API <- USER (in this case, Locale doesn''t always make sense though) or using libiconv? I''d say on a side node, TrueType font (collection) for Windows would support 95, 98, NT, ME, 2000, XP, and as you know, Unicode support had started from 98 (not OS level). That means vendor have reason to use local codeset in family name for 95 support even if it''s a legacy. In my opinion, there seem certain font vendors (Korean, Taiwan, Mid. East!? etc.) have own way to name font useful for their customer.> These three properties indicate the language for the same index in > the associated family/style/fullname property.Great, thanks! but well, I''d let you know a exception (Kanji reading: Ka-kou, meaning: ? Chinese person might know) DFGothicP\-W3,?????????W3:familylang=en,ja ?c?e?o???N?S?V?b?N??W3,??????????W3,DFPGothicP\-W3:familylang=en,ja,en ?c?e?f???N?S?V?b?N??W3,??????????W3,DFGGothicP\-W3:familylang=en,ja,en obviously 1st family name (can''t read either) of latter 2 variants have Japanese name (SJIS) while they are tagged with ''en''.> What we don''t have in fontconfig (yet) is any kind of helper > function to select a name given a set of language tags. I''d love > to see suggestions for how that should work posted here.>From what above cases, as far as familyname is concerned, I must toget capability to select localized name. What I''d suggest is, * Preparing env. variables FC_LANG, FC_CTYPE FC_LANG will be affected wherever end-user''ll have to see it, e.g. terminal, graphical interface (font chooser). It can be specified as comma separated list (FC_LANG=ja,zh_tw,ru). While FC_CTYPE will be used inter-API, embedded name in the document, of course should be ''en''. Multi-lingual conversation between low-level function would have bring nightmare *shrug* However in the past log, I''ve read there are fonts have no English family name... Regards, -- Daichi
Keith Packard
2005-Nov-21 08:51 UTC
[Fontconfig] Kochi Mincho causes segfault (was Re: Multi lingual fontconfig names)
Around 15 o''clock on Feb 26, Daichi Kawahata wrote:> I remember now... it was happened when I had updated to this version > 2.2.99. GNU libiconv 1.9.2 with --enable-extra-encodings, FreeType2 > 9.8.3 (CVS), here they are:So, either Fontconfig is using iconv incorrectly or libiconv has a bug.>From the backtrace, there''s no way to tell. I can load Kochi Mincho hereand get both an ascii and kanji name, so I''m afraid we''ll need you to find out why it doesn''t work in your environment. -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/20050226/ea0c49ce/attachment.pgp
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Re: Multi lingual fontconfig names (was [PATCH] Additional vendor string)
On Sat, 26 Feb 2005 22:42:59 -0800 Keith Packard wrote:> I don''t see how these are better than LANG and LC_CTYPE, aside from > accepting a list of allowed languages. We could permit that as an > extension for unusual cases, but then we''d want to also use those in > the font preference mechanism which does currently use LANG, LC_CTYPE > and LC_ALL.I''d prefer those familiar variables of course, I''m thinking unusual cases also.> In any case, I want to do this in a new API which would accept an > optional application-provided language tag and return the ''best'' > name from the available list (or perhaps sort the available names > according to some metric). Attempting to overload the existing API > with this new semantic seems like a bad idea.''sort'' sounds fine for me ;-) I''m looking forward to see those implementation. Regards, -- Daichi
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Re: Kochi Mincho causes segfault (was Re: Multi lingual fontconfig names)
On Sat, 26 Feb 2005 22:26:33 -0800 Keith Packard wrote:> So, either Fontconfig is using iconv incorrectly or libiconv has a > bug. From the backtrace, there''s no way to tell. I can load Kochi > Mincho here and get both an ascii and kanji name, so I''m afraid we''ll > need you to find out why it doesn''t work in your environment.If following log is useless either, I have no way at present. (Env. variable of 5th step will be changed, if I had export -n xxx.) Anyway, thanks. $ dbx /usr/local/bin/fc-cache dbx version 7.3.1 68542_Oct26 MR Oct 26 2000 17:50:34 Core from signal SIGBUS: Bus error (dbx) where> 0 libiconv(icd = 0xffffffff, inbuf = 0x10018c68, inbytesleft = 0x7ffd7a2c, outbuf = 0x7ffd7a30, outbytesleft = 0x7ffd7a34)["libiconv-1.9.2/lib/iconv.c":426, 0x5fda81ac] 1 FcFreeTypeQuery(file = 0x10016f30 = "[...]/kochi-mincho.ttf", id = 0, blanks = 0x1001d400, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 2 FcFreeTypeQuery(file = 0x66, id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 3 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 4 FcFreeTypeQuery(file = 0x7ffd88c7 = "XML_CATALOG_FILES=/usr/local/etc/xml/catalog", id = 2147322100, blanks = 0x7ffd892c, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 5 FcFreeTypeQuery(file = 0x2f757372, id = 795243109, blanks = 0x65776172, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 6 FcFreeTypeQuery(file = 0x52415259, id = 1311978079, blanks = 0x50415448, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 7 FcFreeTypeQuery(file = 0x3b33313a, id = 707680829, blanks = 0x30313b33, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 8 FcFreeTypeQuery(file = 0x616d3d30, id = 825963317, blanks = 0x3a2a2e71, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 9 FcFreeTypeQuery(file = 0x6e2f696e, id = 1718580069, blanks = 0x61726368, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 10 FcFreeTypeQuery(file = 0x62696e3a, id = 796226418, blanks = 0x2f667265, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 11 FcFreeTypeQuery(file = 0x65742061, id = 1763734643, blanks = 0x3d342073, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 12 FcFreeTypeQuery(file = 0x722f6c6f, id = 1667329071, blanks = 0x6c69622f, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 13 FcFreeTypeQuery(file = 0x3d2d524d, id = 4677446, blanks = 0x494c454e, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 14 FcFreeTypeQuery(file = 0x65657761, id = 1919233907, blanks = 0x68617265, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 15 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 16 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 17 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] [...] 97 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 98 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] 99 FcFreeTypeQuery(file = (nil), id = 0, blanks = (nil), count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82e8] (dbx) dump libiconv(icd = 0xffffffff, inbuf = 0x10018c68, inbytesleft = 0x7ffd7a2c, outbuf = 0x7ffd7a30, outbytesleft = 0x7ffd7a34) ["libiconv-1.9.2/lib/iconv.c":426, 0x5fda81ac] cd = <expression or syntax error> (dbx) up FcFreeTypeQuery: 626 size_t did = iconv (cd, (dbx) dump FcFreeTypeQuery(file = 0x10016f30 = "[...]/kochi-mincho.ttf", id = 0, blanks = 0x1001d400, count = 0x10075248) ["fontconfig/src/fcfreetype.c":626, 0x5ffc82d8] face = 0x100159c8 pat = 0x1001d748 slant = -1 weight = -1 width = -1 i = -1 cs = 0x7ffd79d0 ls = 0x10075248 ftLibrary = 0x10020b68 complex = <expression or syntax error> foundry = (nil) spacing = 140 os2 = 0x10015b38 psfontinfo = struct PS_FontInfoRec { version = (nil) notice = 0xfbe2050 = "\377\377\377\377" full_name = (nil) family_name = 0xfbe0418 = "\377\377\377\377" weight = (nil) italic_angle = 2147318272 is_fixed_pitch = '''' underline_position = 0 underline_thickness = 0 } prop = struct BDF_PropertyRec_ { type = 1076887552 u = union { atom = (nil) integer = 0 cardinal = 0 } } head = 0x10018c68 exclusiveLang = (nil) sname = struct FT_SfntName_ { platform_id = 1 encoding_id = 0 language_id = 1041 name_id = 0 string = 0x10018c68 = "Public Domain(except NAGA10)" string_len = 28 } snamei = 0 snamec = 24 nfamily = 0 nfamily_lang = 0 nstyle = 0 nstyle_lang = 0 nfullname = 0 nfullname_lang = 0 style = (nil) st = -1 (dbx) Regards, -- Daichi
mpsuzuki@hiroshima-u.ac.jp
2005-Nov-21 08:51 UTC
[Fontconfig] Kochi Mincho causes segfault (was Re: Multi lingual fontconfig names)
Dear Mr. Kawahata, Excuse me, I read this subject from now and and not checked previous discussions. Could you tell me which version /or where you''ve got from Kochi-Mincho you''ve tested? I remember Kochi-Mincho is now obsolete and the font file won''t be updated in. Regards, mpsuzuki On Sat, 26 Feb 2005 15:56:51 +0900 Daichi Kawahata <daichi.k@aioros.ocn.ne.jp> wrote:> On Fri, 25 Feb 2005 21:03:15 -0800 > Keith Packard wrote: > > > you can see that the name ''Kochi Mincho'' has no specific language > > I remember now... it was happened when I had updated to this version > 2.2.99. GNU libiconv 1.9.2 with --enable-extra-encodings, FreeType2 > 9.8.3 (CVS), here they are: > > # fc-cache -v > fc-cache: "/usr/local/share/fonts/opentype": skipping, 4 fonts, 0 dirs > fc-cache: "/usr/local/share/fonts/truetype": skipping, 3 fonts, 12 dirs > fc-cache: "/usr/local/share/fonts/truetype/thai": skipping, 12 fonts, 0 dirs > fc-cache: "/usr/local/share/fonts/truetype/japanese": Bus error > > $ gdb fc-cache core > [...] > #0 libiconv (icd=0xffffffff, inbuf=0x10018c68, inbytesleft=0x7ffd7a2c, outbuf=0x7ffd7a30, outbytesleft=0x7ffd7a34) at iconv.c:426 > 426 return cd->lfuncs.loop_convert(icd, > (gdb) bt > #0 libiconv (icd=0xffffffff, inbuf=0x10018c68, inbytesleft=0x7ffd7a2c, outbuf=0x7ffd7a30, outbytesleft=0x7ffd7a34) at iconv.c:426 > #1 0x5ffc82f0 in FcFreeTypeQuery (file=0x10016f30 "/usr/local/share/fonts/truetype/japanese/kochi-mincho.ttf", id=0, blanks=0x1001d400, count=0x10075248) > at fcfreetype.c:626 > #2 0x5ffc574c in FcFileScanConfig (set=0x1001d418, dirs=0x10018cc0, cache=0x0, blanks=0x1001d400, > file=0x10016f30 "/usr/local/share/fonts/truetype/japanese/kochi-mincho.ttf", force=0, config=0x0) at fcdir.c:117 > #3 0x5ffc5ca0 in FcDirScanConfig (set=0x1001d418, dirs=0x10018cc0, cache=0x0, blanks=0x1001d400, dir=0x10019788 "/usr/local/share/fonts/truetype/japanese" > , > force=0, config=0x0) at fcdir.c:240 > #4 0x10001d88 in scanDirs (list=0x10020dd8, config=0x10015008, program=0x7ffd8000 "fc-cache", force=0, verbose=1) at fc-cache.c:179 > #5 0x10001df8 in scanDirs (list=0x10015278, config=0x10015008, program=0x7ffd8000 "fc-cache", force=0, verbose=1) at fc-cache.c:210 > #6 0x10002254 in main (argc=268522104, argv=0x7ffd7e84) at fc-cache.c:291 > (gdb) l > 291 ret = scanDirs (list, config, argv[0], force, verbose); > 292 /* > 293 * Now we need to sleep a second (or two, to be extra sure), to make > 294 * sure that timestamps for changes after this run of fc-cache are later > 295 * then any timestamps we wrote. We don''t use gettimeofday() because > 296 * sleep(3) can''t be interrupted by a signal here -- this isn''t in the > 297 * library, and there aren''t any signals flying around here. > 298 */ > 299 sleep (2); > 300 if (verbose) > > Regards, > -- > Daichi > _______________________________________________ > fontconfig mailing list > fontconfig@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/fontconfig
Daichi Kawahata
2005-Nov-21 08:51 UTC
[Fontconfig] Re: Kochi Mincho causes segfault (was Re: Multi lingual fontconfig names)
On Mon, 28 Feb 2005 09:41:09 +0900 mpsuzuki@hiroshima-u.ac.jp wrote:> Could you tell me which version /or where you''ve got from > Kochi-Mincho you''ve tested? I remember Kochi-Mincho is now > obsolete and the font file won''t be updated in.I''ve been owning it (version 0.2, 2002-01-17) since before stopped distributing. I''m afraid you can''t get from anywhere nor can I give my copy to you. Or rather, if you''d mention somewhat of a license issue, I''ll have to make it clear by myself in this time. Might you know, you can get alternative font, Sazanami-Mincho, from http://sourceforge.jp/projects/efont/files/ Regards, -- Daichi
Keith Packard
2005-Nov-21 08:51 UTC
[Fontconfig] Re: Multi lingual fontconfig names (was [PATCH] Additional vendor string)
Around 15 o''clock on Feb 27, Daichi Kawahata wrote:> Is there any possibility the following (Kanji reading: Kyo-ka-sho, > meaning: textbook, font for textbook) > > NtMotoyaKyotai,NT???g????????2,NT??????2:familylang=en,ja,ja > NtMotoyaKyotai,NT???g????????2KP,NT??????2KP:familylang=en,ja,ja > NtMotoyaKyotai,NT???g????????2????,NT??????2??:familylang=en,ja,jaThose almost look like SJIS encoded names, but they don''t make sense when interpreted in that way. I think we can assume that whatever encoding was marked in the file was incorrect.> >From what above cases, as far as familyname is concerned, I must to > get capability to select localized name. What I''d suggest is, > > * Preparing env. variables FC_LANG, FC_CTYPEI don''t see how these are better than LANG and LC_CTYPE, aside from accepting a list of allowed languages. We could permit that as an extension for unusual cases, but then we''d want to also use those in the font preference mechanism which does currently use LANG, LC_CTYPE and LC_ALL. In any case, I want to do this in a new API which would accept an optional application-provided language tag and return the ''best'' name from the available list (or perhaps sort the available names according to some metric). Attempting to overload the existing API with this new semantic seems like a bad idea. -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/20050226/67b6e517/attachment.pgp