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=/
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.