Xr, the 2D Postscript-like graphics library for X is near completion. Xr is a device independent API, and can theoretically be layered upon an API like OpenGL. The Xr Library provides a stateful user-level API with support for the PDF 1.4 imaging model. Xr provides operations including stroking and filling Bézier cubic splines, transforming and compositing translucent images, and antialiased text rendering. The PostScript drawing model has been adapted for use within C applications. Extensions needed to support much of the PDF 1.4 imaging operations have been included. Web site, discussion and the real meat.
Xr: X11 Cross-device Rendering for Vector Graphics
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
Linux has done well keeping feature parity with Windows (if not polish and ease of use parity), but Longhorn presents a problem. It is a big jump in features. It is nice to see that free software isn’t taking it lying down. The problem will be making it as mature and robust as Longhorn’s new display engine and either maintaining compatbility or getting everyone to update their programs. Either way, I’ll be happy when Linux can render fonts well.
Oh I say, that does look promising.
Does this remind anybody else of NeXT’s/Apple’s display postscript window manager?
I presume this is just an API for drawing graphics – not for drawing the windowing subsystem? How will this help actual desktop use of the machine?
Well said, Sean but I feel X11 has taken a thrasing so far, from Windows, with no one too keen to oust the ageing window manager, for legacy and more because of orthodoxy reasons.
This should ease UNIX loving, X11 orthodoxy into the 21st bloody century.
For a community that prides itself on tweakability and “doing things properly”, this is about bloody time.
X11 is quite an excellent system for what it provides. In our network, I have it running on the application server, which provides our users with access to Linux applications that, while available on Windows, would cost thousands upon thousands to license.
However, X11 with Cygwin and the resulting Linux apps are free. The network transparency provides us with far more then adequette performance. The only issue we experience is sometimes, not very often, but sometimes the application could take slightly longer then normal (roughly 20 seconds longer) to start up.
Oh and one last thing… “Kids, don’t try this at home; this kind of configuration was setup by professionals, using higher-end commodity hardware with plenty of RAM. Using less, will provide you with much less.”
It’s essentially something a bit like Display PDF on MacOS X, but without it all being server side for efficiency reasons. It’ll make use of the RENDER extension to accelerate the drawing of basic geometric primitives (trapezoids basically). This won’t give you translucent windows, nor animated throbbing buttons. It will give a strong foundation for accelerated rendering, and device independance.
It isn’t Display PDF, nor Display PostScript. It’s inspired by them however.
What a cool feature! and if it fallow the speed’s evolution of the linux kernel we will have a nice rendering environment and some cool fetatures like network transparency! And all that before windows! (don’t forget that longhorn will release just in 2005! hehe)
It’s essentially something a bit like Display PDF on MacOS X, but without it all being server side for efficiency reasons.
Actually, you have it completely backwards.
Display PDF in OS X is handled completely through the Quartz 2D libraries (on the client side) which render to a raster CGContext, which is read (via shared memory) by the CoreServices WindowServer, combined with other CGContexts through the Quartz compositer, and displayed. Mach message ports are used, but only for synchronization and event handling.
Xr is an extension, and thus all vector commands are passed over a socket, where they are then processed by the X server (using either Xrender or possibly OpenGL as a backend). So, Xr’s vector handling is server side, whereas with Quartz it is not.
The main drawbacks I see with Xr have to do with its handling of text, which seems to be nonexistant. It says that eventually bindings for fontconfig will be added, so we’re continuing to see fragmentation between fontconfig and STSF.
For now, writing a PDF/PostScript display utility using Xr would be virtually impossible.
The plans for text handling are a bit more definate than that. If you take a look at Keith P’s comment on xwin.org:
>>>>>>>>>>>>>>>>>&g t;>>>
Authored by: keithp on Sunday, May 18 2003 @ 08:29 AM PDT
The paper glosses over text and color handling not because there isn’t an intention to include support for them, but because that support hasn’t been designed yet.
Text output will certainly leverage the FreeType and fontconfig APIs, but will be integrated into the Xr API in much the same way as text output is done in PostScript. Details about how fonts are selected and how OpenType tables are passed up to the application will probably involve direct application interaction with these additional libraries, but the actual inclusion of glyphs into the image will be done with Xr APIs.
This looks a lot like the EVAS library in Elightment 17. I have installed the libs and demos and it blows everything else out of the water! EVAS is a very object (that is on screen entities like bitmaps, line segments, polygons and text) oriented and handels smooth screen updateing, transformations and composting invisabily using OpenGL as the back end. Already EVAS does most of what will be in Longhorn’s GDI.
I do think that the Postscript based nature of Xr may be more applicatable to some types of applications.
This looks a lot like the EVAS library in Elightment 17. I have installed the libs and demos and it blows everything else out of the water! EVAS is a very object (that is on screen entities like bitmaps, line segments, polygons and text) oriented and handels smooth screen updateing, transformations and composting invisabily using OpenGL as the back end. Already EVAS does most of what will be in Longhorn’s GDI.
I do think that the Postscript based nature of Xr may be more applicatable to some types of applications.
Actually, you have it completely backwards. Display PDF in OS X is handled completely through the Quartz 2D libraries (on the client side)
Oh, quite possibly yes. I was thinking of Display PostScript, I read somewhere that Display PDF was basically a renaming of it to something people were more familiar with. Perhaps whatever I read was wrong.
I’d note that this is how Xr would work for non-RENDER aware servers, libIc or libimagepix or whatever it’s called now would render it to a pixmap which would then be shared via XSHM and then rendered/composited by the X server. When RENDER is available, the 2D (or i suppose 3d) acceleration features of the card are used.
Xr is an extension, and thus all vector commands are passed over a socket, where they are then processed by the X server (using either Xrender or possibly OpenGL as a backend). So, Xr’s vector handling is server side, whereas with Quartz it is not.
By “not server side” I was referring to the rendering logic, as opposed to geometry data but yeah, I wasn’t very clear. It’s not really vector handling, the X server simply acts as a conduit for trapezoid data -> graphics card on most machines. The processing is basically all done client side, the “vector commands” are little more than arrays of numbers.
The main drawbacks I see with Xr have to do with its handling of text, which seems to be nonexistant. It says that eventually bindings for fontconfig will be added, so we’re continuing to see fragmentation between fontconfig and STSF.
As far as I know only Sun use STSF, outside of them it has had no impact whatsoever. For free systems (ie the only ones that use XFree) fontconfig and Xft2 is it. As keithp is heavily involved in this, and he did fontconfig, I suspect we’ll see integration soon.
For now, writing a PDF/PostScript display utility using Xr would be virtually impossible.
Yes, but then it’s not finished. I’m not sure why the story says “nearing completion”, afaik it’s quite some way from that.
I just had to comment about how cool it is to have choice. On linux we could build a display system with DirectFB and run some X server entension thing on top of it. Or run XFree86 natively with GNOME/KDE.. or run Enlightenment on X or maybe one day DirectFB and GNOME/KDE on top of that, if we choose. Any way you stack it we get a lot of awesome features, customizability and compatibility with other OSs we recognize on our networks, like Irix, AIX, OSX, BSD, Solaris, win32, etc.
Hello,
I have read here that Display PDF is client based.
I used NeXTStep for Intel and I remember that Display Postscript was server based. You can also have a remote window like in XFree.
Am I wrong? Or Apple has changed all things with Display PDF?
Hello,
I have read here that Display PDF is client based.
I used NeXTStep for Intel and I remember that Display Postscript was server based. You can also have a remote window like in XFree.
Am I wrong? Or Apple has changed all things with Display PDF?
The shared memory rendering model is in place for performance reasons. It’s quite visible in things like Dock Magnification, which, while annoying, does an excellent job in demonstrating the power of Quartz and the WindowServer.
How does this compare to Ghostscript?
DisplayPDF as an imaging model is just an updated to the Postscript imaging model that supports compositing features. Now, Apple’s implementation and NeXT’s is very different. The DPS libraries on NeXT generated actual Postscript code client-side, which was executed on a PS interpreter server-side. Quartz2D, OTOH, doesn’t normally generate PDF code. Quartz2D is just a C/C++ API that draws directly into shared memory buffers owned by the window server.
What is wrong with the font rendering quality in X11? I’ve run X11 on both FreeBSD and Linux, as so long as the toolkits have been compiled against Xft and the latest version of Freetype (2.1.4 with hinting), there is no difference if visual quality, the only application you may see a difference is with OpenOffice on FreeBSD because you will have to enabled XFS to load at boot up time as it still relies on it.
The main drawbacks I see with Xr have to do with its handling of text, which seems to be nonexistant. It says that eventually bindings for fontconfig will be added, so we’re continuing to see fragmentation between fontconfig and STSF.
Well, it doesn’t really matter as STSF has Xft bridging, meaning, even if the application does use Xft STSF will be able to provide the necessary services that Xft would provide, also, STSF is a competitor/replacement for Xft not fontconfig. Fontconfig merly provides a means to index fonts on the system.
Well, it doesn’t really matter as STSF has Xft bridging
Except fontconfig is built on top of the incompatible Xft2 extension.
meaning, even if the application does use Xft STSF will be able to provide the necessary services that Xft would provide
Yes except Xr will use Xft2…
also, STSF is a competitor/replacement for Xft not fontconfig.
No, STSF is a competator for fontconfig/Xft2
Fontconfig merly provides a means to index fonts on the system.
Through Xft2…
Adobe has continuosly stated that it’s flagship products (PhotoShop, Illustrator, InDesign, Acrobat etc.), which all rely heavily on Adobe’s Postcript IP, will NEVER ship on Linux because of the very nature of the open source. John Warnock has openly (sic) stated his hatred of OSS.
This just will add to it all.
Adobe owns postscript. Adobe owns Acrobat and the PDF format. The two are very much intertwined and PDF is very much print and display postscript.
Linux suffers from NOT having the “big gun” applications I use daily (see above) and therefore it is unusable to me (productivity-wise).
What do you think will happen with Xr?
Vic
I see what you mean now, however, hopefully STSF will prove to be a superior solution to Xft. Having had a look, it appears that it should be finished in around 3-4months (0.5 should be released soon) and bundled into Solaris sometime later on this year. If all goes well one will be able to run GNOME 2.x with beautiful anti-aliased fonts.
Fontconfig is most certainly *not* dependent on Xft2, or even X at all. From the fontconfig.org site:
<<<<<<< quote >>>>>>>>>>>
Fontconfig does not:
render the fonts themselves (this is left to FreeType or other rendering mechanisms)
depend on the X Window System in any fashion, so that printer only applications do not have such dependencies.
<<<<<< endquote >>>>>>>>>>
Fontconfig is most certainly *not* dependent on Xft2
Oh please, how is the current solution implemented? Just because something is abstracted doesn’t mean it’s not abstracted on top of one only thing at the present time.
I don’t see this as some big new window manager thingy.
Using wxWindows, the context for drawing can be a window, or transparently can be a postscript file or windows meta file or something. So to print or save a diagram, you just draw it to a non-screen context. Very neat.
If this is another library for authoring postscript, maybe with fancy curve support, then this is a good thing.
Maybe you should read Rayiner’s post repeatedly until you understand it?
Maybe you should read Rayiner’s post repeatedly until you understand it?
And maybe you need to brush up on the functionality of Xft2.
The author talks of using Fontconfig and Freetype in order to render fonts through Xr. Yet how is it going to access fonts? Is it going to go through the FontPaths and pick out and load all the fonts itself, independent of X? Perhaps it will have its own set of fonts? No, of course not, it’s going to use some bridge through X.
It doesn’t take a genius to figure out that if he’s going to be using fontconfig he’s going to use Xft2 as a bridge to FreeType, just like everything else.
No, you have it backwards.
Freetype2 is font reading and glyph rendering library. It doesn’t know where in the system you have your fonts, nor it does care where it will render. Client applications pass filenames for fonts they want to open and memory buffers for glyphs to render. Freetype2 does not depend on X11, only on glibc.
fontconfig is font-enumerating library. It has own configuration files (/etc/fonts/*.conf) with paths, where to look for font files and how to do substitutions. Client applications pass info for fonts, they want to find (like font-family, weight, slant, etc.) and receive path and filename for given font. Fontconfig does not depend on X11, only on glibc, freetype2 and expat (XML parser). Summary: Yes, it loads it’s fonts independently from X11. It does not use any bridge through X – that would defeat the purpose why it was created in first place!
Xft2 is convenience library, for gluing fontconfig and freetype2 into X11. Toolkits like Qt and Gtk+ use this library. This is the first library in chain, that depends on X11.
This is exciting to me– not because I long for translucent windows or bouncing, throbbing hyperactive icons– but because I long for a stable, mature vector graphics editor in the style of Illustrator or Fireworks. Although I can’t comment on speed, the screenshots in the paper look like very high quality renderings, so this takes us one step closer to making Linux a good platform for production graphics.
Bascule, if you have a Linux machine available, just ldd libfontconfig.so. It links only to FreeType, not to libXft or libX11.
FontConfig uses the FreeType library to analyze the font files and get font information. When you call a font matching function in FontConfig, you get a set of matches in the form of a list of FcPattern objects. You then call XftFontOpenPattern() (in Xft2) to actually load the font and create an XftFont object you can pass to the rendering calls. Remember, Xft2/FontConfig is a client side font architecture. The server itself doesn’t even know about FontConfig fonts (they don’t necessarily show up in xlsfonts unless you also configure a font path in X86Config).