Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
X GUI

Fontconfig 2.0 Released 163

Posted by michael from the you'll-get-helvetica-and-like-it dept.
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..."
This discussion has been archived. No new comments can be posted.

Fontconfig 2.0 Released More

Fontconfig 2.0 Released

Comments Filter:
  • An easier way to configure printers, complete M$ Office interoperability, and a stronger add hardware system, and we're desktop ready!
    • Easier Printers ? www.cups.org
      Complete M$ Office ? Nearly there www.openoffice.org

      Better Add Hardware System ? Any ideas? :-)
      • I have used cups, as well as various lp programs, and it always seems to be more of a "server" app rather than a client configuration. I understand that M$'s print spooler is technically a "server" app, but it really doesn't have that feel. You don't need to know anything to set up a winblows printer, and albeit windows printers are a bit more limited for cross-network printing (not much, but a little), they are easier to set up (mostly due to HW manufacturers actually supporting drivers for them).

        And OpenOffice.org is almost there, but there is no Exchange client, and the imports are just a little bit off. No biggie on the imports, but I am a very big proponent of Exchange in the enterprise, and I am not alone (althouh for the internet, Exchange is a whore!).
        My vision of Linux is a drop in replacement for many NT services, both server and desktop, as well as have the ability to interoperate with existing infrastructure. Microsoft is attempting to pull users to their servers with their Unix services for Windows package, Let's keep them here by giving administrators the flexibility that they need to provide a complete solution for business needs. This means opportunity to choose the OS that they feel is best for the job, without having to change over the whole camp!
      • CUPS isn't enough. Last night I suffered the fury of a thousand hells when I tried to get a document document from Perseus [tufts.edu] to print properly. Postscript fonts can't handle unicode and Ghostscript doesn't handle TrueType fonts well. The best I was able to do was to get it to print the unaccented characters, but that was only a third or so of the characters in the document. It displayed perfectly using a unicode TrueType font, but Ghostscript couldn't do it right even when I set it up to print with the same font it was displayed with.

        Ghostscript is also very slow loading TrueType fonts. Since it looks like TrueType fonts are going to continue to dominate desktop computing, Ghostscript needs to handle them better. Your printouts will never look the same as what's on your screen if Ghostscript can't render all of the fonts that X can.

        • Then your beef isn't with CUPS, it's with Ghostscript. CUPS is great. It also works great on my Mac running OSX Jaguar. And I have _no_ problems rendering TrueType fonts, but that's apple's fault :)

          • 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.
      • Easiest printers: pdq

        I was a die hard lpd user for many years, but last week I tried out pdq and had my printer working perfectly (both text and Postscript) in less than 5 minutes. Use xpdq to do the configuration.
    • An easier way to configure printers, complete M$ Office interoperability

      You mean aside from CUPS and Crossover Office?

      CUPS [freshmeat.net]has a number of front-ends to it that are *very* easy to use, and provides an easy, GUI-oriented way to deal with printers - as its freshmeat writeup says, "it has been developed to promote a standard printing solution for all UNIX vendors and users."

      Crossover Office [codeweavers.com] isn't Free (and I don't run it for precisely that reason), but if the only thing tieing you or your company to Windows is the need for complete Office support, it's the most promising option out there. General word processing is better served by AbiWord [abisource.com], in my opinion, but this is not a sticking point of any note anymore.
      • I've always found that the best configuration tool for cups is cups itself...

        http://localhost:631

        This works by default on Gentoo, I would hope that this is the same for any distro using cups.

      • I'm considering trying to switch to Linux and CUPS [cups.org] sounds interesting. I also happen to be in need of a new printer (I currently have an HP 5L [buyldw.com], but it jams if I insert more than one sheet at a time).

        So, can anyone recommend a laser printer with high (or perfect) compatibility with Linux? I'm looking for one that can do at least 10 ppm and 600 dpi (though 1200 dpi would be preferable). Price is not so much a concern, though I would prefer one < $400.

        • I have the Samsung ML-1210, which has been discontinued, but you can probably find it in stores. There is the ML-1250 (I think) which is probably the same and hasn't been discontinued. I paid $150 for mine. Samsung even wrote a gui printer dialog for the latest version of cups. very, very nice. In the gui dialog there is even an option to print 1-4 pages on a single page. This is probably the chepest laser printer you can get with excellent linux support.
        • Any Postscript printer, basically...
        • The HP family of printers are actually great printers. I am not farmiliar with the 5L, but the 6L and 1100 were gravity-fed styles. Avoid these like the plague. We use old 4L's (they're tanks) and 1200's (new, about $650 cdn) and they are great under Linux using 4L drivers. These also speak native postscript, pcl5, and pcl6 for the 1200. Very compatible with almost everything.

          • Yes, gravity-fed do usually suck. However, the one I bought real cheap ("broken") was fixed with a cheap separator pad. Shortly after I bought the pad, HP offered me one for free. Shortly after that I got notice of a class action lawsuit against HP regarding the problem the original owner had experienced. :-) That was an 1100.

            • Could a broken separator pad be the problem I'm having in my HP 5L? Would that be something that could cause it to jam if more than one sheet is inserted at a time?
            • Damn, why wasn't I let in on that suit? We bought half a dozen of them at our office when they first came out! We went through the pad thing, then replaced them with the 1200's when they were available. I still have 2 working 1100's here somewhere....
        • Lexmark's low end Postscript printers are advertized as Linux compatible. check out www.lexmark.com for latest models. I love my 320.
        • Samsung has great Linux compatability and they have some good USB laser printers for under $200.
    • My wife won't run Linux until there's a WYSIWYG HTML editor to replace DreamWeaver.

    • Re:Now all we need is.... (Score:5, Interesting)

      by JohnMunsch ( 137751 ) on Friday September 06, 2002 @08:48AM (#4206071) Homepage
      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).

      • Re:Now all we need is.... (Score:4, Interesting)

        by _Knots ( 165356 ) on Friday September 06, 2002 @09:15AM (#4206218)
        Simple Direct media Layer (SDL) and OpenGL not good enough for you? Why not?

        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 /dev/dsp at once."

        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;
        • 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 /dev/dsp at once."

          Not true... Alsa only supports multiple access to /dev/dsp* if the hardware supports it. If the hardware doesn't support it, you still need a software mixer.

          Dinivin
          • However (and correct me if I'm wrong here), ALSA can do that transparently, removing the need for pretty much forcing esd or similar on users.
            • However (and correct me if I'm wrong here), ALSA can do that transparently, removing the need for pretty much forcing esd or similar on users.

              ALSA itself does not do software mixing in the drivers.. A 3rd party app (such as esd, arts, or even an alsa specific one) would be needed to do this and audio applications would have to be written to support it.

              Only hardware mixing would be truly transparent (or, possibly, software mixing in the drivers).

              Dinivin
              • That's quite poor, if it decides the card can't handle multiple sources (which I guess would be fairly easy at the driver level), it should really start some kind of software mixer automatically.
                As it happens I'm using commercial OSS anyway, but that's not the point ;)
          • If ALSA also doesn't do what you want, www.opensound.com has AWESOME commercial drivers that can mix over 50 PCM streams at one time, real time, with low CPU utilization. It works just like directsound.

            Plus, SDL is cross-platform and does most of what DirectX does, using open standards and OpenGL for 3D accelleration.

      • Re:Now all we need is.... (Score:4, Interesting)

        by micahjd ( 54824 ) <micahjd@users.sourceforge.net> on Friday September 06, 2002 @09:42AM (#4206344) Homepage
        You're forgetting SDL... SDL along with OpenGL (which it interates with very nicely) provide pretty much the same scope of functionality as DirectX.

        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.

        • SDL is just a wrapper over underlying sound mechanisms. Plus, while SDL and OpenGL may be cleaner (okay, the are definately cleaner) they are far less powerful than DirectX. Now, with OpenGL 2.0 coming out and if OpenAL and OpenML get integrated into SDL, things might change, but as yet, there is still not real competition to DirectX.
          • Erm, and what is DirectX other than a wrapper over underlying systems?

            Damn, you kids gotta learn how to troll. Come up with something harder to refute, man!

            • Umm, DirectX isn't a wrapper. DirectX is an independent system that bypasses a lot of antiquated Windows functionality. DirectX is usually supported at the driver level, existing alongside Windows APIs like GDI and Win32 audio. SDL is a wrapper over whatever services are native to the platform. On Windows, SDL is a wrapper over DirectX. On Linux, its a wrapper over OSS and the XInput APIs.
      • "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)."

        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.tx t
        Why do people keep mentioning this? Clipboard support has been fixed since KDE 3.0!!!
      • I think you have a pretty good list. Almost all of them fall into the area of needing a standard location for configuring the X window manager. My comments on these:

        I don't know anything about it, but it sure sounds like SDL and ADSL is the agreed on thing for games and sound. I would dearly love to see Linux do better than Windows and actually make an interface that is usable for *both* games and regular programs, but it looks like that ain't going to happen.

        Single standard for the clipboard: it exists now. The problem is older programs that don't know about CLIPBOARD. There is no way to fix this. Windows would have the exact same problem if somebody decided to make drag-less drag & drop, which is really what the middle-mouse cut & paste is.

        Adding/removing menu items from the Start menu. I believe there is a standard that KDE and Gnome follow. But good luck trying to find it described anywhere. There is a serious need for this to be documented in a simple and obvious way with explicit "it is in this file and here is an example", without the need for Qt or any library to read it (the library is also a fatal problem on Windows). Without this other window managers and other programs will not use it.

        Mime type associations. This could also be done with more config files, but I would really like to see a more Unix solution, which is the addition of a simple "open" command-line program. Any GUI that wants to "open" a file just runs this program. It can do anything it wants. There should also be simple "mail" and "print" programs that take the data in stdin and do the right thing, it is quite annoying that Mozilla knows how to mail on my machine but the "mail" program does not. In a similar vein, I would like to see the prefixes like smb: and html: on files be handled by the glibc library level so that *ALL* programs can read/write these without linking in Qt libraries.

        By "adding control panels" I think you mean adding stuff to the "configuration" application. One idea is to make a tiny extension to the Start menu, so that if you have a program lying around that "configures" something, it can appear where the user will look for it, in the list of stuff in the configuration program. It does not really matter if this opens another window. I would avoid any complexity about describing the questions or imbedding panels and other than this "run some other program" leave the design and implementation of configuration up to the programmers. Windows and Mac have fallen into the trap of making a seperate app for each part of configuration, this artificially seperates concepts into program packages, which does not necessarily agree with how users catagorize concepts.

        I don't think event sounds are a big deal. Looking at Windows you can see that virtually all event sounds are specific to each application. I would consider this part of the application's configuration and as a beginning user would expect to find it there.

        Display of notification icons in the desktop toolbar: here I would disagree. One thing I would like to see is the ability to change GUI ideas. If applications can assumme a toolbar it is bad news, we will never be rid of it. I think the ultimate interface will someday get rid of all things on the screen other than the data being worked on, but stupid stuff like this is what is keeping us frozen with ideas from 1985...

        Registration of keyboard shortcuts is exactly the same as the "Start" menu stuff, and should be stored in the same place. One big help is that there be no difference between "applications" and "actions" so that either can be on a start menu or on a shortcut. Windows also blows in this area. "Getting back to the right program" is a window manager issue and is true whether a shortcut of a menu item or typing a command brought up the new program. Windows also screws up here, worse than most X window managers, if you have ever closed two nested modal control panels you know what I mean.

        So we need a "start menu configuration" which in my opinion should be the union of a directory in your home and a system-wide directory. Each file and subdirectory describes a single "item" or a submenu. There are special names to make menu items appear in different places such as the configuration application or in the popup, or as a shortcut key. The files should be trivial to parse without using a library. It should be trivial to locate documentation describing every detail of these files without going off into unrelated areas of the desktops.

        We also need command-line tools that appliations can use in place of libraries. We need "open", "mail", "print", etc. We also need a unified file interface where "http:" and other prefixes work for every program like cat and the shells.

      • I don't know if you're trolling or just dumb, but the last time I checked there was one true standard for Linux audio right now. I don't know where you're getting your four or five. Okay, so there's commercial OSS, there's OSS/free, there's, um, whatever the kernel uses (thought it was still OSS, but they've got a separate config in the kernel now) which is OSS-compliant and there's ALSA, which is OSS compatible.



        Okay, so if you want to write audio apps, there's OSS. Okay, if you want to get down to it, GNOME and KDE have their own sound *servers* which communicate with OSS/ALSA/whatever. Doing it that way just makes *sense* because KDE and GNOME run on more than one platform, not just Linux. Linux ain't the only game in town, and neither is Windows. MS forgets that and foists Windows-only, x86-only crapola like DirectX on us.



        And if you want to target Windows, MacOS, Linux, etc. DirectX is a poor choice. Heck, if you want to target something other than Windows DirectX is a stupid choice. SDL targets a number of platforms and will even work with OpenGL (which is an open standard, and even has MS as part of its steering committee.)

    • 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.
  • For a second, I thought I had clicked on my shortcut to freshmeat.net

    D
  • As a junior CSE major, I dearly dread the day that this sort of information becomes important to me... May that day never come. :P

  • With Debian... (Score:2, Interesting)

    by IkeTo ( 27776 )
    I use dfontmgr and defoma. Anyone knows how the two systems differs structurally and in practice?

  • Microsoft web fonts (Score:3, Interesting)

    by Zigg ( 64962 ) on Friday September 06, 2002 @07:56AM (#4205830)
    Hmm, the fontconfig page [fontconfig.org] has the withdrawn Microsoft web fonts [slashdot.org].
    • If so, there was *no* need for them to do so. The EULA that comes with the fonts specifically states,
      "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."

      • Re:Microsoft web fonts (Score:4, Informative)

        by Zigg ( 64962 ) on Friday September 06, 2002 @08:15AM (#4205907)

        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.

        • I was responding to the original poster's claim that the fontconfig site had removed access to the MS Web Fonts on their server. The specific line was :

          Hmm, the fontconfig page [fontconfig.org] has the withdrawn Microsoft web fonts [slashdot.org].

          Obviously, this is an untrue statement.

          The EULA permits it, so why not mirror it all over the place?

          This is the point I was making - that according to the EULA, this is legal.
          • Obviously you don't know English very well ;)

            "X has the withdrawn Y" means that entity Y, which was withdrawn, is available from X.

            You are thinking that he wrote "X has withdrawn the Y" - moving 'the' makes it completely different.
            • My, my.

              English is not a problem - I speak it quite fluently, along with German and Spanish. Friday mornings, on the other hand, aren't quite so easy to cope with.

              Smack me with the cluestick. I deserve it. :)
          • I was responding to the original poster's claim that the fontconfig site had removed access to the MS Web Fonts on their server. The specific line was
            Hmm, the fontconfig page has the withdrawn Microsoft web fonts

            Note the word order: that does not say "the fontconfig page has withdrawn the Microsoft web fonts".

          • Re:Microsoft web fonts (Score:1, Informative)

            by Anonymous Coward
            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.

  • World Domination?! (Score:5, Funny)

    by gergi ( 220700 ) on Friday September 06, 2002 @08:18AM (#4205923)
    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!

  • X font problems... (Score:5, Insightful)

    by Lumpy ( 12016 ) on Friday September 06, 2002 @08:19AM (#4205927) Homepage
    every font problem stems from one simple problem... People and programs throw fonts anywhere and everywhere...

    if you forced everyone to put fonts in /usr/lib/X11/fonts/ or wherever the Xfree86 people say then the problem is solved.. the font server can easily look for new fonts.

    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.
    • I prefer to install my fonts into /usr/local, like any other stuff that's not part of my distribution.

    • completely wrong (Score:4, Interesting)

      by Ender Ryan ( 79406 ) on Friday September 06, 2002 @08:52AM (#4206093) Journal
      I agree with you that fonts in Linux are really messed up at this point, but your completely wrong about why. It has nothing to do with WHERE they are kept on a system.

      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.

  • Seriously, all distros I've tried (RedHat, Mandrake, Debian, Slackware, SuSe) ship with a woefully inadequate supply of fonts. There are thousands of quality free (roughly speech) fonts out there, and I at one time simply ran through free font sites downloading them. While I'm not 100% clear on copyrightability of fonts, there are plenty distributed un-encumbered by their authors. Why doesn't RedHat or somebody pick them up?
    • Finding fonts that are Free enough to allow commercial redistribution (ie put in a distro that will be sold in a box on a shelf in a store, etc.) is actually quite hard.
      Making a font is extremely hard work, especially if it's a good one, which is why fonts are such well guarded property.
      However, that doesn't mean they can't make it easy for users to find and include decent fonts. If all distros can agree on a single directory within which they will keep all fonts then it becomes the job of the various font servers and fontconfig to track and maintain the font lists.
      Actually, I think the time has come for font servers to die - they make the job a million times more complicated than just using the font support already in XFree (which of course now includes TTF support). Even if you go by the argument that a font server is useful for serving the same fonts to lots of client machines over a network, the same would be true of a public ro nfs share of the fonts directory.
      It would then be really easy to have a button somewhere that says "Get me more fonts" and takes the user to, say, fonts.themes.org and offers them a bunch of fonts to download in a consistent archive format which can be automagically whisked away into the font directory and fontconfig called to automatically update it all.
    • In addition to what the other chap said, the fonts that you find for free are more "Banner" fonts - the kinds of things that you would use for a title, but you wouldn't format a paragraph, let alone a whole document with them.

      In answer to your point, someone from Debian is trying to get permission [debian.org] to use some of these fonts.

    • 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.

    • If you switch distros every time you can't find a font you like I would hate to hear what you do when you run into a REAL issue.

      • Well, from an end user perspective, this is a real issue. If you load up your new linux peecee and start up a browser, and all your favorite sites look like shit because there are only 5 fonts installed on the system, suddenly, this new "better" OS has a degraded user experience, and therefor the the 90% market currently under Bill's control, worse. The underlying technology may be better, but as we've learned time and time again, they aren't the one that wins...
    • There is one good use for that old Windows 98 CD. Download CabExtract [uklinux.net] and rip those beautiful Windows TTFs right off of your disk.

      Then, your fonts can look like this [rr.com].

      KDE's standard fonts look good with MS's Arial. Times New Roman is good for web browsing. Opera works well with the same fonts as used in the Windows version, but you need to tweak the font sizes a bit.

      It's a bit of trouble, but works nicely on the Linux desktop. Until we can come up with some great GPLed TTFs, then this is the best that we've got.

      Make sure it is Windows 98 though. I think that new EULA tells you that you can't do this stuff with newer Windows releases. :) J/K
    • There are thousands of quality free (roughly speech) fonts out there,

      Nope. There are thousands of fonts out there, given away for free, but most of them don't allow distribution (at least not commerical, and many not at all), most of them aren't quality (tiny character sets, low quality glyphs, no hinting or kerning at all) or are very decritive and limited use. I can count the number of open source font makers on one hand.
  • If there's one thing that desktop Linux needs, it's straightening out the whole font/X mess. Nice to see some serious stuff getting done abouting. Propz, gratz, and thankz to the whole team.
  • ... that a project like this, which claims to "implement high quality, anti-aliased and subpixel rendered text on a display" can have such an ugly website without any screenshots.

    --Jon (watches karma burn)
    • ... that a project like this, which claims to "implement high quality, anti-aliased and subpixel rendered text on a display" can have such an ugly website without any screenshots.

      Since fontconfig itself doesn't deal with font rendering / displaying it doesn't make much sense to have screenshots there. You should check out the Pango / Qt / GTK+ / etc. websites for screenshots. Or do you also expect screenshots of linux on kernel.org? :-)

      -adnans
  • Fontconfig did compile fine, but the CVS pango version seems borked ... too bad ... no nice fonts ;)
  • To use it you have to patch your QT, GTK and Mozilla. I'm not a very good programmer but why couldn't the API be the same so these apps would 'just work'? Maybe I just don't understand how it works.

    All I know is that two big barriers to the desktop are fonts and printing. So I'm glad that things are being developed to make it easier.

    • Re:One problem. (Score:3, Informative)

      by Darren Winsper ( 136155 )
      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.

    • Re:One problem. (Score:4, Insightful)

      by spitzak ( 4019 ) on Friday September 06, 2002 @12:44PM (#4207635) Homepage
      I know some people are going to apologize, but I agree with this poster.

      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.

      • Re:One problem. (Score:3, Informative)

        by keithp ( 139560 )
        "You don't understand X, it is impossible".

        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.

        • Thanks for the reply.

          I was hoping for the "kludge in AA text support for apps using the core X protocol". I expected that all the old fonts would disappear at that point and only the TrueType fonts would be accessable, and they would all advertise as scalable fonts in ISO-8859-1 encoding. I don't really see much need to make the bitmap fonts accessible.

          But you are right that the Xft extension is being written (by you, I think) to emulate itself on older X servers, which is excellent (I have used this plenty in fltk btw). All new programs should use this. Is this going to be true of the other XRender extensions as well, such as the shape drawing? It would seem that it can draw an aliased and non-transparent simulation pretty well. This would be very exciting because we could ditch all the X drawing code completely.

  • This really great news. Linux and X have badly needed a unfied way to handle fonts for a long time.

    fontconfig adds:

    1) Excellent Unicode handling for developers.

    2) This resolves the need for developer hacks and workarounds for accessing and displaying available fonts. For programs like Scribus - a Linux Desktop Publisher [altmuehlnet.de] this will make life much easier in the future.

    3) Makes adding and fonts much easier. Now we need a good GUI front end so installing fonts is as easy as Win/Mac.

    For desktop linux this is as important as having TCP/IP for networking. (You need good plumbing underneath.)

    • 3) Makes adding and fonts much easier. Now we need a good GUI front end so installing fonts is as easy as Win/Mac.

      What i'd really like to see is being able to just copy off a whole ream of fonts in the $X11BASE/lib/x11/fonts dir and have them Just Work (tm).

      Sure, a nice GUI type app to tweak stuff like antialiasing and the XftConfig would be nice, but that's not enough.

      • They have that. Its the fonts module in the KDE Configuration program.

        You have to copy them to that directory then use this wizard-like tool to install them, but its easy enough for a windows user to do without having to RTFM.

        siri
  • I'm not should what the poster meant by an "add hardware" but I've long thought that the kernel distribution could and should help get the ball rolling by referencing a stand alone file containing hardware config information about the target machine that persists across different kernel builds/versions, with some easy format that trusted applications could modify.
  • One of the highlights of the current Limbo/Null beta (shaping up to be the upcoming 8.0 release) is that it includes Xft2/fontconfig.

    AFAIK the Mozilla shipped is bog-standard, however, if you want to try fontconfig without too much hassle, I really recommend (null).

    Get it from your favourite Red Hat mirror [redhat.com] - I personally use rpmfind.net

    Cheers,

    Michel

  • I thought that this is great, finally all my fonts will work. Well, download, and here is what I see...
    • no documentation... there is a tiny .tex file in the fontconfig directory telling you what it does, but no main README, no instructions for install/configuration...
    • of the 4 directories that are created from the tarball, only two compile. fontconfig and Xft compile and install just fine, Xft1 and Xrender fail, and use the very old Imakefile (xmkmf) setup. As there is no readme, I have no idea if these are needed or not.
    • No change for the installed system. There were no instructions on how to run the program, if there is any thing to run. I downloaded and ran the mozilla version which looked great, but didn't use any of the many hundred extra fonts I have installed (though it did render the default fonts nicely).


    That, and I don't see any difference in applications... is this suppose to be transparent (I assume so), or do apps have to be written specifically to use Xft2.so? 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 :(
    • "no instructions for install/configuration..."

      Read the website! It tells you to ./configure --prefix=/usr/X11R6 && make install.

      "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.

    • Re:Anyone got this working yet? (Score:4, Informative)

      by keithp ( 139560 ) on Friday September 06, 2002 @01:52PM (#4208208) Homepage
      Fontconfig is just a standalone library. The benefits of the system will only be realized as applications and other libraries take advantage of the capabilities.

      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.

  • Network transparency (Score:2, Interesting)

    by tempfile ( 528337 )
    Something I couldn't find on the website - is fontconfig network transparent? I.e., is there a way for a remote application to render fonts stored on the local system, or would it have to resort to core X routines?

Slashdot Top Deals

"The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of doubts." -- Bertrand Russell

Close