On Sunday 01 December 2002 10:17 pm, Owen Taylor wrote: | Vadim Plessky <[EMAIL PROTECTED]> writes: [...] | > | I don't think they are ready for Rawhide -- rawhide can be quite raw, | > | but it's also stuff that we think is going to be ready for the next | > | release; Once they settle down a bit more, I can look at making | > | unofficial RPMS... the main prerequisite there is a tarball and a | > | version number scheme. | > | > Do you think Xr/Xc wouldn't be ready for your next release? | > I hope it should be ready pretty soon :-) | > We need good groundbase for SVG rendering on X, and Xr/Xc looks like a | > perfect candidate for this task. | | Well, before a library would be considered for inclusion in Red Hat: | | - There would have to be some serious application of the library | to demonstrate that it actually meets the purposes it was | desired for.
this is quite understandable. | | - (Usually) something else in the distribution would need to require | it. The supported devel platform for Red Hat is a small subset | of the libraries we ship as dependencies of apps. | | - The authors of the library would have to express confidence that | the ABI/API of the library is something that will be supported | long term. Agree with both statements, too. | | None of these are there yet for Xr/Xc. I suspect Xr/Xc can progress | quickly, but putting it into a distribution prematurely wouldn't | help. | | If someone wants to use Xr/Xc for a SVG renderer, then they need to | try writing their SVG renderer and figure out what's missing. There | are some pretty obvious gaps currently. (Like the ability to render | and get access to the pixels client side, which you need for SVG | filters.) well, AFAIK Carl Worth took librsvg2 (used in GNOME2 by Nautilus and Eye of Gnome) and decided to port it to Xr/Xc (to check rendering capabilities of those extensions). And, according to him, this resulted in almost complete code re-write, and new library - libxrsvg. Still, apps which use librsvg (in particular - EoG and Nautilus2) can be rather easily ported to libxrsvg. And there was alos suggestion/ide to port librsvg2 itself from libart to Xr/Xc. I don't know wether some work is going in this direction, though. So, current dependency list for , say, Nautilus: Nautilus <- librsvg2 <- libart can become Nautilus <- (new) librsvg2 <- Xr/Xc If Xr/Xc is hardware accelerated (on some graphics adapters), than users would immediately get better rendering speed (and same rendering quality, not sure that it would better but I don't see any degradation over libart so far) On the other hand, Karbon14 (vector-drawing application in KOffice) uses libart, too. Dependency here is something like this: Karbon14 <- VPainter API <- libart which can become Karbon14 <- VPainter API <- Xr/Xc (VPainter needs to be ported from libart to Xr/Xc) Than we get The One World very close to being perfect: single enhancement to Xr/Xc/libxrsvg would result in enhancement for a lot of Linux/Xfree86 apps, running on rather different platforms: GNOME and KDE. Plus pure X apps would be able to use such SVG renderer/PS-like API, too. Isn't this great ? :-) | | Regards, | Owen | _______________________________________________ | Render mailing list | [EMAIL PROTECTED] | http://XFree86.Org/mailman/listinfo/render -- Vadim Plessky SVG Icons * BlueSphere Icons 0.3.0 released http://svgicons.sourceforge.net My KDE page http://kde2.newmail.ru (English) KDE mini-Themes http://kde2.newmail.ru/themes/ _______________________________________________ Render mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/render
