Slashdot Mirror
Fontconfig 2.0 Released
david_g writes "Keith Packard released version 2.0 of Fontconfig. Fontconfig is "a library for configuring and customizing font access". It can "discover new fonts when installed automatically, removing a common source of configuration problems", among other nifty functionalities. It comes with Xft2, and there are patches for GTK, Mozilla, and QT3 being readied. Another small step towards world domination..."
As the download page said: "Did you read the license?"
1. (item 2) Reproduction and Distribution. You may reproduce and distribute an unlimited number of copies of the SOFTWARE PRODUCT; provided that each copy shall be a true and complete copy, including all copyright and trademark notices, and shall be accompanied by a copy of this EULA. Copies of the SOFTWARE PRODUCT may not be distributed for profit either on a standalone basis or included as part of your own product.
Internet Explorer was unable to link to the Web page you requested. The page might use standard HTML or CSS.
No need for Keith Packard to distribute them? Or no need for Microsoft to pull them?
The move on Microsoft's part was good strategy -- they've effectively broken all those font installers that previously used www.microsoft.com as their download site. Of course, it won't be long before they're updated, but they've made installers released before that date break.
Keith Packard's distribution of them is also a good thing. The EULA permits it, so why not mirror it all over the place?
I guess I don't understand what you're getting at.
My guess is that you are not a native english speaker?
[I] The Fontconfig page has the withdrawn Microsoft web fonts
is very different to what was NOT said
[II] The Fontconfig page has withdrawn the Microsoft web fonts
[I] is talking about "withdrawn web fonts", with withdrawn as an adjective describing a vague status of the web fonts - and yes, they were withdrawn by Microsoft. Just because they're still available and licensed for redistribution does not mean MS did not withdraw them from their original well-known URL location.
[II] if it had been said (which it wasn't), would have meant that the fontconfig page had withdrawn the fonts - withdrawn being used as a verb.
English is complicated. It is the antithesis of Latin, in that in English word order is extremely important, but words change little, if at all, for different verb tenses, cases, etc.
Dreamweaver 4 is working or very nearly in Crossover Office, it's not yet officially supported though, perhaps the next release.
Qt and GTK will have support in a future release (Probably the next point release wouldn't surprise me), but Mozilla's a bit undecided at this time. Red Hat have been pussing to get Chris Blizzard's work into the main tree, but there has been resistance to Blizzard's methods from a few Unix heads.
What? How can it get any harder than the KDE printer configurator? It is butt-simple. Just choose your model, a driver, and that's it. You can even print over an NT netowork to a shared SMB printer without any problems.
The documentation included in this release is aimed at helping get applications ported to the library, not at helping get systems configured to use the library. That kind of documentation is needed, but it just hasn't been written yet.
Fontconfig has been released, but that's only relevant to application development right now.
The original X graphics infrastructure was pretty badly broken, worse in some ways than the Windows API. X doesn't provide any color information about pixels, so it's actually not possible to know what colors different pixel values mean in different contexts. The only place you can be sure is when drawing to windows, and you can only generate intermediate color values for TrueColor windows.
The Windows API provides color information everywhere instead of pixel information; applications select the color for text, not the pixel values. Each pixmap contains information about what colors are represented by pixel values. This makes anti-aliasing quite possible and ensures that drawing in different contexts will generate consistent results.
If you're interested in bit-level pixel manipulation and complete control over the hardware colormap, then the core X rendering system is just the ticket. All of the limitations we're running into now were caused by compromises necessary to support commercially important applications in the era X was developed; now that hardware is 1000 times faster, we can emulate those tricks and still provide new capabilities.
However, it's even more important to realize that anti-aliased text is only a side-effect of the real benefits that Fontconfig and Xft bring to X. The core protocol font handling has never been sufficient to support sophisticated text display. Every sufficiently powerful text rendering engine based on X has had to give up on the core fonts and implement text entirely in software. From TeX previewers to commercial publication systems, none of them gain any benefit from the hardware acceleration and network bandwidth optimizations of the core text primitives.
Furthermore, the core protocol font support cannot handle Unicode encoded fonts -- character codes are limited to 16 bits and Unicode requires 24. Even if you limit applications to the Unicode basic multilingual plane, the metrics information cannot be compressed as it is delivered over the wire or stored in Xlib making applications consume huge amounts of memory storing arrays full of zeros.
It is possible to kludge in AA text support for applications using the core protocol, but the results would be inconsistent on the screen and such support would not do anything to fix the worst limitations of core fonts.
As Xft2 now supports legacy X servers (without Render support), it is now reasonable to consider jettisoning any support for the core protocol fonts and switch to only supporting client-side fonts. Servers with Render will get good performance while servers not yet fixed will still work reasonably well.
The last step to take is to make all of the core bitmap fonts available as Unicode bitmap fonts through Fontconfig. The original plan was to make FreeType able to read the existing compressed bitmap font file formats that XFree86 uses. Those formats still suffer from the encoding assumptions that drove the massive space consumption in the core protocol metrics data, plus such fonts are consistently encoded in Unicode.
The new plan is to reencode the existing core fonts as TrueType fonts with only bitmaps for each glyph. The TrueType spec has explicit support for such fonts. Reencoding the fonts will significantly reduce the amount of disk space consumed by the fonts, eliminate all of the existing bitmap readers from the X server (and font server) and simultaneously make the fonts available to fontconfig/xft2-based applications.