Re: [Fonts]fontconfig, Xft2, pango-head, gtk2 - play together?
On Thursday 18 July 2002 1:39 pm, Richard Chan wrote: | Just a question about the fc stuff: | | I found (to my surprise) that fontconfig, Xft2, pango-head and gtk2 seem | to compile and work together. I needed to change one point of the | gdk/x11 compile where it doesn't look for the Xft2 headers (not | unexpected of course). | | (At least gtk-demo runs). Is this supposed to work :-?? | Owen Taylor [EMAIL PROTECTED] is developer of Pango, Pango is in foundation for GNOME2, so I see no reason why it shouldn't work! | Anyone tried using Gnome2 on this foundation (b4 I grab all the tarballs | and try compiling). | You may want to ask Owen Taylor. | Cheers | Richard | ___ | Fonts mailing list | [EMAIL PROTECTED] | http://XFree86.Org/mailman/listinfo/fonts -- Vadim Plessky http://kde2.newmail.ru (English) 33 Window Decorations and 6 Widget Styles for KDE http://kde2.newmail.ru/kde_themes.html KDE mini-Themes http://kde2.newmail.ru/themes/ ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Pablo Saratxaga wrote: ... On Thu, Jul 18, 2002 at 10:12:05AM -0700, Keith Packard wrote: Around 13 o'clock on Jul 18, Pablo Saratxaga wrote: In other terms, the localized names are used to display in the lists shown to the user, when when one of those is choosen, what is returned is not the localized name but the ascii-only one. And inversly, when an ascii-only name is gotten, it should be possible to retrieve its associated localized name if needed. Why do you believe the internal interface should only use ASCII names? Not necessarly ASCII names, but unique and locale independent ones. So if a document which embedds fotn names is open under a different locale nothing strange happens. Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Note that *all* of these names are locale independent; applications can use any of the names to access the font, the only question is what name should be returned when the application requests it, the mapping from the set of names to a name appropriate for the user is the only locale -dependent step. Will there be a way to get the localized name using the ascii only name? Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 8 o'clock on Jul 22, Brian Stell wrote: Yes, this is important. I can well imagine an app that that saves a user's preference. If the user changes locale then the saved preferences should still find the user's previously set prefered fonts. I expect this to mean that the app will save the preferences in ascii and then get the localized list for display. Hmm. I think I see the way through here. See below. Will there be a way to get the localized name using the ascii only name? Yes. The representation of the names internally includes all of the localized names along with the postscript name (which is always ASCII), any match or list result will include all of these names. I would sort the names so that any English or Latin names would come first in the list. Ok, so applications want a notion of 'canonical' family names which can be mapped to localized names for display to the user at runtime. I plan on storing all of these names together in the same FC_FAMILY entry for each known font, tagged (somehow) with the associated language. The entries would be sorted with English names first, followed by names containing only Latin characters and then the remaining names following sorted by language tag. A naïve application using the existing FcPatternGetString API will get an English name for each font. A separate API (FcPatternGetLangString?) would walk the list of names and select the one best matching the specified language (or current locale). An application wishing to store font preferences in a locale-insensitive fashion can either: a) Store just the English name. Converting to a local name would require a call to FcFontList and then a call to FcPatternGetLangString. b) Store all of the names along with their languages. This can be done with FcNameUnparse/FcNameParse which generate UTF-8 encoded strings for the font name. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Keith Packard wrote: ... A naïve application using the existing FcPatternGetString API will get an English name for each font. Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. a) Store just the English name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
Around 9 o'clock on Jul 22, Brian Stell wrote: Wouldn't it make more sense for a naive app to get the localized name? Thus apps users of simple apps would get names they could read; eg: Japanese users by default get Japanese names, Greek users would get Greek names, and so forth. Yes, I agree that would be nicer, except that truely naïve applications are likely to incorrectly display UTF-8 strings. The FcPatternGetLangString API would return the appropriate UTF-8 string so that slightly-less naïve applications could trivially extract the localized name. To make the code regular for all languages I would really prefer to store the ascii only name and then always get the localized names for display. In the suggested API I presented, that's quite possible. The only cost is in converting the ascii name into a local name which requires searching through the set of available fonts to match the ascii name. This would have the (questionable) property where the application would find out that configured fonts were missing. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Font family name problem
On Mon, 22 Jul 2002, Keith Packard wrote: Around 8 o'clock on Jul 22, Brian Stell wrote: Will there be a way to get the localized name using the ascii only name? How about the other way around? Given a localized name+lang, would it be possible to get the ascii name? Put differently, would there be a way to access the mapping from a localized name+lang to a font(or ascii name/canonical name)? Yes. The representation of the names internally includes all of the localized names along with the postscript name (which is always ASCII), any match or list result will include all of these names. I would sort the names so that any English or Latin names would come first in the list. Reading this, I think it should be possible, but is there an API for that? A number of web pages have embedded or separate CSS with only 'localized font (family) names'. Web browsers or any other applications accessing those CSS' need to map localized names+lang (assuming that lang info. is available in one way or another) to fonts. Although it appears that they can roll out their own for this purpose, wouldn't it be nice to have this in fontconfig? Thanks, Jungshik ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Can't input Lao
Kaixo! On Mon, Jul 22, 2002 at 06:41:42PM -0400, Anthony Souphavanh wrote: Pablo, I searched on the net and found this article which this person mentioned you. I was wondering whether I need to set or use UTF-locale. Yes, you need a locale using an encoding that incldes lao. That means utf-8. If this true, why it works for Thai and Hebrew, Greek, etc. It's the same for those. However, they have a second choice in addition to utf-8; respectively tis-620, iso-8859-8, iso-8859-7,... But it doesn't make sense to add other non utf-8 encodings nowadays. When I issued the command 'locale charmap' the locale is ISO-8859-1. it won't work then (unless your program uses the locale independent functions to get input keyboard, but they are relativley new and I suppose not much programs use them currently). change to an UTF-8 locale. By the way, did you get a chance to test lo keysyms I sent? It works perfectly for me (well, as far as I can tell, I don't know Lao); I tested it with yudit, using xkb input with en_US.UTF-8 locale create directory /usr/X11R6/lib/X11/locale/en_GB.UTF-8 copy XLC_LOCALE from /usr/X11R6/lib/X11/locale/en_US.UTF-8 into this directory. If you will to use the same file it is not needed to copy it under another name. If you want to input non-ascii characters, you may need a compose map. that is for composing latin letters with accents and things like that, it is not needed at all for Thai or Lao (unless for things like (c), tm, and such signs, and the myriad of exisitng quotation marks etc) Unfortunately, compose maps provided with xfree86 are somewhat insufficient. See http://www.xfree86.org/pipermail/i18n/2001-August/002278.html Download the Compose.gz file (by Pablo Saratxaga), gunzip and place it in /usr/X11R6/lib/X11/locale/en_GB.UTF-8 That file (with my errors corrected) is now shipped in standard with XFree86; so if your version of XFree86 is not too old you don't need to do anything (and anyway, it is not needed for Lao; it is needed for French, German etc that requrie composing for typing their accents, but Lao just encodes the diacritics separately) Edit file /usr/X11R6/lib/X11/locale/compose.dir and add there these lines: (is this really necessary?) en_GB.UTF-8/Compose:en_GB.UTF-8 en_GB.UTF-8/Compose en_GB.UTF-8 No; XFree86 already comes with a good Compose file (in en_US.UTF-8 directory) and has en_GB.UTF-8 locale point to it (in fact all UTF-8 locales minus the CJK ones) Also download us_intl.gz file, gunzip it and put it into /etc/X11/xkb/symbols (this will give you much better keyboard for writing various accented latin letters). Notice that version by Pablo has some minor typos in it, these are corrected in my file. That file is only useful for typing latin letters like ubreve, eogonek or kcedilla etc. you don't need it for Lao. you only need an UTF-8 locale actually installed i nyour system (it doesn't matter which locale you choose as long as it uses UTF-8. For Lao it should be lo_LA.UTF-8; it is known by XFree86, but probably it isn't by your libc, so you may need to choose another. -- Ki ça vos våye bén, Pablo Saratxaga http://chanae.stben.be/pablo/ PGP Key available, key ID: 0xD9B85466 [you can write me in Walloon, Spanish, French, English, Italian or Portuguese] msg00997/pgp0.pgp Description: PGP signature
Re: [Fonts]fclang.o missing from fontconfig/src/Makefile
Richard Chan [EMAIL PROTECTED] writes: Wondering if fclang.o is missing from fontconfig/src/Makefile. It doesn't seem to get compiled otherwise. Yes, it's missing from there - I suspect that Keith only tested with Imake. Attached is the patch to fix I had sitting around. You'll need to rerun automake after applying the patch. Regards, Owen --- fontconfig/src/Makefile.in.langfix Fri May 24 02:25:52 2002 +++ fontconfig/src/Makefile.in Mon Jul 15 21:08:31 2002 @@ -40,6 +40,7 @@ fcfs.c \ fcinit.c \ fclist.c \ + fclang.c \ fcmatch.c \ fcmatrix.c \ fcname.c \ @@ -58,6 +59,7 @@ fcfreetype.@OBJEXT@ \ fcfs.@OBJEXT@ \ fcinit.@OBJEXT@ \ + fclang.@OBJEXT@ \ fclist.@OBJEXT@ \ fcmatch.@OBJEXT@ \ fcmatrix.@OBJEXT@ \ @@ -68,7 +70,7 @@ .c.@OBJEXT@: $(CC) $(CFLAGS) $(DSO_PIC_CFLAGS) -c $ -o $@ - + all:: $(LIBFILE) $(LIBMAJOR) $(LIBBASE) #
Re: [Fonts]fclang.o missing from fontconfig/src/Makefile
Owen Taylor [EMAIL PROTECTED] writes: Richard Chan [EMAIL PROTECTED] writes: Wondering if fclang.o is missing from fontconfig/src/Makefile. It doesn't seem to get compiled otherwise. Yes, it's missing from there - I suspect that Keith only tested with Imake. Attached is the patch to fix I had sitting around. You'll need to rerun automake after applying the patch. Err, well, of course, automake isn't involved, and I see it has been fixed in XFree86 CVS already. Regards, Owen ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
