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..."
Hmm, the fontconfig page has the withdrawn Microsoft web fonts.
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.
World Domination?! Is that was this is all about? I thought it was the ticket line for LotR: Two Towers... damn, now I have to find the real line and start all over again!
Nosce te Ipsum
every font problem stems from one simple problem... People and programs throw fonts anywhere and everywhere...
/usr/lib/X11/fonts/ or wherever the Xfree86 people say then the problem is solved.. the font server can easily look for new fonts.
if you forced everyone to put fonts in
Linux and X suffer from the fact that too many people are allowed to do it their way... it's time to start forcing things to make simple things like fonts easier.
Do not look at laser with remaining good eye.
Hardly... You forgot a strong equivalent to DirectX to give games a place to migrate to (sorry, a mix of OpenGL + some sound library doesn't equate to DirectX).
Then there's _one_ unified sound standard (I think Linux has four or five now), because a sound card cannot serve two masters. Single standards for the clipboard, adding/removing menu items from the desktop "Start" menu, mime type associations, adding of control panels, event sounds, display of notification icons in the desktop toolbar, registration of keyboard shortcuts that cut across all applications (e.g. Ctrl+Shift+I means "get the next instant message" and it will get back to the right program no matter if I'm in OpenOffice right now or Mozilla). And all of those standards have to be agreed upon and fully supported by both KDE and Gnome so I can know that all my applications will cooperate nicely with one another and my choice of desktop doesn't equal choice of application interoperability.
Desktop success for Linux is not impossible, far from it, but few people are paying attention to the mounds of things that are _really_ important to giving a typical end user a choice other than Windows vs. Mac OS X (a battle that we already know who wins 95% of the time).
Sigs are for people who started using the net _after_ '86.
No, the reason fonts are so messed up right now is that there has never been a good standard way of rendering fonts, forcing people to come up with their own solutions. So now, we've got tons of old programs using GTK This is all being solved now, but unfortuneately it is being solved woefully late in the game! This should have been addressed at least 5 years ago, and then now we would have this mess and every program/gui toolkit would render fonts in the same, sane manner.
Hopefully Fontconfig will help with straightening this mess out.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Simple Direct media Layer (SDL) and OpenGL not good enough for you? Why not?
/dev/dsp at once."
There are a handful, yes, but ALSA is going to be the new kernel standard in 2.6 and will allieviate the need for oss (current kernel code), esd, artsd, etc - at least as far as "many people writing to
Your choice of desktop never determines your application compatibility - I'm running Galeon right now under KDE3. What's the problem?
Now, that said, I hope KDE and GNOME both drop their VFS layers and encourage the use of something like LUFS that's much more general and will result in less code duplication. We've already seen GNOME and KDE work out a lot, together - like say the XDnD system. These days it seems like the only "war" between the two is in the minds of the non-developers.
--Knots;
Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
Plus, by using SDL your app is portable to Windows, BeOS, MacOS, etc. (in theory)
I've done some DirectX programming a while ago and a good bit of SDL programming recently. The SDL and OpenGL APIs are much cleaner and easier to use than DirectX.
-- 2 + 2 = 5, for very large values of 2
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.
Sorry, there aren't thousands of free "quality fonts" on the web:
1) Most of them are decorative or banner fonts which are not suitable for longer documents or any kind of high end postscript.
Try it - take a doc with some of these fonts and then try to output either clean postscript or send it to a RIP. Do not be surprised when it pukes..
2) Many of them are made by well meaning designers, who sometimes lack important technical skills in font making. They rely on the abilities of fontographer to compile everything correctly. So, quality is a mixed bag.
3) Many of these fonts have incomplete glyph sets and can be difficult to use in non iso-88591-1 encodings.
Making good fonts is really really hard and time consuming. (The guy who created Verdana for Microsoft spent more than a year just on that one font.) The new Luxi TTfonts which come with the more recent XFree86 packages is the right direction - well constructed, professionsally designed fonts. Luxi Sans is a good screen font if freetype is setup correctly.
The "problem" with the latest ghostscript fonts is they are not really great screen fonts, but most of them are excellent printer fonts.
Anti-aliasing is not the long term solution either. It just covers for the lack of hinting in a font. Freetype is getting much better though..
A font is in a sense a mini program and they have bugs. Just like other code - debugging them is not for kids.
"Hardly... You forgot a strong equivalent to DirectX to give games a place to migrate to (sorry, a mix of OpenGL + some sound library doesn't equate to DirectX)."
x t
How about OpenGL + SDL? Easier and just as powerful as DirectX. SDL handles everything from video to threads to sound to CD-ROMs.
"Then there's _one_ unified sound standard (I think Linux has four or five now),"
Check reality! There are TWO standards: OSS and ALSA.
If you want compatibility with other Unix platforms, use OSS and forget about it. ALSA has OSS emulation. If you want power, use ALSA, which is only available on Linux.
Again: if you want compatibility, use OSS. Or if you're creating a game, use the sound API in SDL! Then you doesn't have to worry about the underlying sound system at all.
"Single standards for the clipboard,"
Has been there for ages. http://www.freedesktop.org/standards/clipboards.t
Why do people keep mentioning this? Clipboard support has been fixed since KDE 3.0!!!
"no instructions for install/configuration..."
./configure --prefix=/usr/X11R6 && make install.
:("
Read the website! It tells you to
"That, and I don't see any difference in applications... "
Of crouse not.
1. Fontconfig is a font configuration system. It provides information of installed fonts to applications. It's not a user-visible thing.
2. The rendering is done by Xft/FreeType/Whatever, not by fontconfig.
Perhaps you would know that if you read the website.
"If the latter, isn't this kinda useless as a "real" solution, as then it's just another way of configuring/rendering fonts that is mentioned above
This is by no means useless. Fontconfig isn't "another" configuration system. And it sure is *not* a rendering system. Fontconfig is a step towards a *good* configuration system, not "another" one.
Apps don't support it now, but that's not a big deal. The most important thing is that developers have a sane font configuration system now to develop for.
"That, and I don't see any difference in applications..."
Like I've said before (and like the website says): fontconfig does *not* do rendering! Rendering is done by Xft/FreeType/Whatever.
Fontconfig and Xft2 don't make your fonts suddenly look better, font quality depends on the font itself.
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.
Though there are lots of reasons to add new interfaces, I find it inexcusable that XFree86 has not been fixed so that the old font interface draws the text anti-aliased.
Lot's of people then say "You don't understand X, it is impossible". But I do understand X. Yes, it will only work on trueColor. Yes, it probably needs to clip the antialiasing off at the edges of the glyph bounding box (I would enlarge the bounding box so this is not a problem). Yes, antialiasing will need to be turned off if they set Xor bitblt mode (I would ignore this problem, actually, nobody xor's fonts). Yes, it won't work with existing font servers. None of these are real problems.
The truth is that the innards of XFree86 are such a mess that nobody could figure out how to remove the 1-bit/pixel limitation from the pipeline between the font renderer and the screen. This is very sad and also indicates that X is very slow and bloated and that nobody will ever be able to fix it. It is also true that there is an incredible paranoia about back-compatability that must be overcome, in fact Linux's ability to ignore back-compatability somewhat is a big advantage over Windows.
I also want to point out that MicroSoft successfully updated their interface to use antialiasing, and they had all the same issues as X did. In case you forgot, originally Windows did not do antialiasing. They changed it and all the old programs started using it *without* being rewritten! The fact that X could not do this same sort of fix is far worse than the delay it has taken to get antialiasing.
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.
I guess I phrased it wrong. I don't have any problem with CUPS. I should have said that CUPS alone is not enough. It solves one problem, but not the deeper problems caused by having two completely different systems for video and printing. It may be possible to modify Ghostscript to fix these problems, but I think that the possibility of creating a new printing architecture from scratch needs to be considered.
My only political goal is to see to it that no political party achieves its goals.
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.