[Fonts]Updated prerelease for Xft and fontconfig
I've updated the tarballs containing Xft and fontconfig bits and have included Xrender and Xft1 sources as well. Those haven't been 'autoconf'ized yet, so they only build with xmkmf. Several significant changes have happened in the sources due to input from Owen in his quest for Xft2 support in Pango: Xft: +) Unreferenced fonts are left around for a while in case they're reused +) Open fonts are placed in a hash table for quicker matches +) When using the core protocol for AA rendering, Xft was leaking the temporary image used to composite text. Fontconfig: +) CharSets have been reimplemented to save memory and improve performance. For a 4800 font test case, I reduce memory usage from 6MB to 100KB for the coverage information. +) Lots of profiling driven changes converting a bunch of linear searches into hash tables or binary searches. A quadratic loop over pattern pairs was also changed into a linear walk. +) FcFontSetSort performance was tuned; a list matching 'sans-serif' from my 383 font test set has improved from 10ms to 3.8ms. If further performance improvements seem warrented, it would be quite reasonable to cache the search results; they're quite compact, consisting of an array of pointers into the global font set. +) A FcFontSort API was added; it is to FcFontSetSort as FcFontMatch is to FcFontSetMatch. This should be the preferred API for font list generation. Other than that, I've done some pretty extensive cleanups in the build process, testing all of the libraries with xmkmf and Xft/fontconfig with autoconf on my Debian Woody box which is running XFree86 4.1. So, unless Owen thinks Fontconfig should be caching pattern->font list computations, I'm hoping Xft2 and fontconfig are nearing release. Thanks to everyone for sending in bug reports and suggestions; there's no way I could have made this much progress so quickly without them. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Updated prerelease for Xft and fontconfig
Around 0 o'clock on May 31, Keith Packard wrote: > I've updated the tarballs containing Xft and fontconfig bits and have > included Xrender and Xft1 sources as well. Those haven't been > 'autoconf'ized yet, so they only build with xmkmf. I forgot to include the path to the files; it's the same as before: http://keithp.com/fonts I repackaged stuff in a single tarball 'fcpackage..tar.gz' and will put new versions in the same directory (with a different timestamp). As usual, all of this stuff is also in XFree86 CVS, the only difference is that this tarball includes a couple of files from outside the library directories that have changed since XFree86 4.1 shipped -- notably the render extension header files, and a couple of files that don't get installed but which are necessary to build an extension library (extutil.h and region.h). Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]What's language tag??
>> I have seem many times in this mailing list, on the term 'language tag'. KP> This comes from the OS/2 tables [in TrueType and OpenType fonts]. KP> There are 64 bits in this table which were originally designed to KP> indicate which "CodePages" the font supported, The term ``language tag'' is also used in Unicode for a way of embedding language information into a Unicode stream. The use of language tags in Unicode text is frowned upon, as it destroys the stateless nature of Unicode text, leading to unpleasant consequences if Unicode strings are e.g. concatenated. The consensus seems to be that language tags should be avoided, and language information included in higher-level protocols (such as XML). Juliusz ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]Ciach bitscale! [2nd attempt]
I've sent this already, but it was upheld for moderation due to file size. Sorry for not thinking about this earlier. I've put a patch that removes the bitmap scaling code on http://www.pps.jussieu.fr/~jch/software/private/no-bitmap-scale.patch I've only tested it with KDrive, but there's no good reason why it should break the XFree86 server. It probably breaks Xprt, though. I'd be glad to get some feedback before submitting it. If people object, I can always make a patch that makes the bitmap scaling optional but doesn't actually remove any code. Here's my suggested release notes entry: The support for scaling bitmap fonts is removed. The server's ability to scale bitmap fonts confuses both users and application developers. Many X installations are configured incorrectly, leading to the familiar ``ugly fonts'' syndrome. Recently, high-quality free scalable vector fonts have become widely available; a number of such fonts are included with XFree86, others can be found bundled with other software packages, notably Aladdin Ghostscript version 6.0 and later. Because of that, the ability to scale bitmap fonts is no longer needed, and has been removed from XFree86, leading to much simpler server configuration. Because of this change, you will need to remove any ``:unscaled'' attributes from your font path. Please check your XF86Config (or XF86Config-4) file for any lines of the form FontPath"/usr/lib/X11/fonts/misc/:unscaled" and remove the ``:unscaled'' part, e.g. FontPath"/usr/lib/X11/fonts/misc/" ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Re: Font lookup ranges [was Re: Notes on Pango Xft backend]
Yao Zhang wrote: > ... > But in my opinion, combining different Chinese fonts together to get > a bigger coverage is generally not a good idea. I see this kind of thing > happens in Mozilla, GTK+ 2. When I see it, the only effect is that it tells > me I should change my font settings, the same as I see undisplayable, square > substitute showing on my screen. So why go through all the trouble to > implement something no one will like. Current fonts each tend to cover one language and *English*. One of the main intents of larger code coverage is to allow documents to have two or more languages where none of them is English. For example, what font setting could you pick if the document had: Traditional Chinese and Cyrillic Simplified Chinese and Thai Korean and Japanese Portuguese and Devanagari Brian Stell ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Ciach bitscale! [2nd attempt]
Around 18 o'clock on May 31, Juliusz Chroboczek wrote: > I'd be glad to get some feedback before submitting it. If people > object, I can always make a patch that makes the bitmap scaling > optional but doesn't actually remove any code. Mike Harris has built a similar patch and my comments to him were essentially that there are probably applications out there that depend on the existance of scalable names for all fonts, so I suspect we need to make the bitmap scaler optional; allow either :scaled or :unscaled options on the font path elements and make the default :unscaled. I'd like to have a build-time option to get rid of the code for kdrive servers, but the main XFree86 server should probably be built with the code in place, but disabled by default. An alternative that could work is to (optionally) advertise scalable names but do nearest-size matching instead of bitmap scaling; that keeps broken applications working while avoiding horrors on the screen, and eliminating the scaling code from the server. Perhaps ':nearest'? Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Ciach bitscale! [2nd attempt]
KP> I suspect we need to make the bitmap scaler optional; allow either
KP> :scaled or :unscaled options on the font path elements and make
KP> the default :unscaled.
Keith, I hate you. Okay, I'll do that.
KP> I'd like to have a build-time option to get rid of the code for kdrive
KP> servers,
Appended.
KP> but disabled by default.
How do I read an XF86Config flag from a font backend?
KP> An alternative that could work is to (optionally) advertise
KP> scalable names but do nearest-size matching instead of bitmap
KP> scaling;
Not difficult, the code is already there (when selecting a bitmap font
to scale); what bothers me is that we're adding code where should be
removing it.
Juliusz
Index: xc/lib/font/bitmap/bitscale.c
===
RCS file: /cvs/xc/lib/font/bitmap/bitscale.c,v
retrieving revision 3.22
diff -c -r3.22 bitscale.c
*** xc/lib/font/bitmap/bitscale.c 2001/12/14 19:56:46 3.22
--- xc/lib/font/bitmap/bitscale.c 2002/05/31 17:26:35
***
*** 49,54
--- 49,80
#define MAX(a,b)(((a)>(b)) ? a : b)
#endif
+ #ifdef NO_BITMAP_SCALER
+
+ /* ARGSUSED */
+ int
+ BitmapOpenScalable (FontPathElementPtr fpe,
+ FontPtr *pFont,
+ int flags,
+ FontEntryPtr entry,
+ char *fileName,
+ FontScalablePtr vals,
+ fsBitmapFormat format,
+ fsBitmapFormatMask fmask,
+ FontPtr non_cachable_font)
+ {
+ return BadFontName;
+ }
+
+ /* ARGSUSED */
+ static void
+ bitmapUnloadScalable (FontPtr pFont)
+ {
+ return BadFontName;
+ }
+
+ #else
+
/* Should get this from elsewhere */
extern int serverGeneration;
***
*** 1952,1954
--- 1978,1982
xfree (pFont->fontPrivate);
DestroyFontRec (pFont);
}
+
+ #endif
___
Fonts mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/fonts
Re: [Fonts]Ciach bitscale! [2nd attempt]
Around 18 o'clock on May 31, Juliusz Chroboczek wrote: > KP> but disabled by default. > > How do I read an XF86Config flag from a font backend? I just meant that a bare font path should disable the bitscaler and that the user should say :scaled to get scalable names. For compatibility, the code should continue to accept :unscaled and ignore it. > Not difficult, the code is already there (when selecting a bitmap font > to scale); what bothers me is that we're adding code where should be > removing it. You're right; just rip it out. With the default to have fonts unscalable, we should know within a year whether we can delete the code without consequence as well. Keith PackardXFree86 Core TeamHP Cambridge Research Lab ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
[Fonts]fontconfig: multiple fonts w/ same name ?
Given a setup with both truetype and type1 versions of a given set of fonts (as is seen w/ most installs w/ the Luxi fonts, and may show up with CM fonts), there should be a way via fonts.conf to prefer one or the other format. Not all such fonts have the same name. The ttf versions of lucida fonts shipped with sun's java runtimes/sdks show up with different names via fontconfig than the (mostly¹) equivalent type1 fonts. I understand adobe altered the names of the type1 libarary when they released them as otf. But I'm sure Luxi and CM are not the only 2 examples in the wild where the t1 /FullName and the ttf name table have identical strings. Another similar issue is different versions of the same font. It would be useful to order the fonts by version in the case of name collisions. As it is I don't see any way the users could determine which version -- ie which file on disk -- would be used for a given font specification w/o actually trying it out. -JimC ¹ The ttf version have a *much* larger glyph repertoire than the type 1 versions I purchased from yandy.com; the latter may have been expanded since, but I doubt it. ___ Fonts mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/fonts
