Re: Manipulate elements by id or class name - Idea for a feature request
"Dominic Lachowicz" <[email protected]>
| Newsgroups | gmane.comp.gnome.lib.librsvg.devel |
|---|---|
| Message-ID | <[email protected]> |
We've discussed this on IRC. I'm just replying here so that people don't think that this list is entirely abandoned. The feature request is asking for parity with an Inkscape feature-let - the ability for some pieces of data's size to stay fixed, while other pieces scale. I believe the example given was rounded corners on rects. * I'm ok with someone implementing an Inkscape-compatible mode for librsvg. * I'm ok with someone implementing a DOM API so that you can manually tweak these things, and then re-render. * I don't much like the proposed API below * I don't personally plan to implement any of the above suggestions, but will certainly consider suitable, maintained patches and will be available to answer questions Cheers, Dom On Mon, Oct 6, 2008 at 6:19 AM, Hagen Schink <[email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hello there! > > I'd like to discuss the idea of a feature request I have in mind. I've bothered a developer (at least I guess he's one) on IRC already but he said that there is no real chance for this request to become accepted. I want to use this mail to point to some advantages I see though. > > The main idea is that librsvg provides an API which allows the developer to manipulate attributes of the SVG file on the fly. In the end this means the manipulation of a RsvgHandle. Here a simplified example: > > static void > rsvg_set_attribute (RsvgHandle *handle, gchar *id, gchar *attribute, gchar *value); > > I think it's obvious that this is much more convenient then a lot of file and libxml magic. At least I hope to preserve the speed benefit librsvg provides. > > This would enable the developer to manipulate SVGs in a way that preserves different measures (and this is very important, at least for the designer and his artwork). With pure Cairo this is not possible (please correct me if I'm wrong). > > I don't know how much effort is needed to provide an API in the way I proposed. Neither I know if there are other concerns which speak against such an API. But I'd like to discuss it to understand a possible refusal. > > Kind regards, > Hagen Schink > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iEYEARECAAYFAkjp5h8ACgkQ1UAqryBcuEX18gCfWInzN6A2WbXCQp6LhAZuaJav > H58AoIAdJ2yD7oYzC6T0p/ouJIy2LnRZ > =EOa8 > -----END PGP SIGNATURE----- > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Librsvg-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/librsvg-devel > -- Counting bodies like sheep to the rhythm of the war drums. ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/