hey

i use inkscape for preparing graphics for duotone printing with scribus... thus, i use transparencys a lot, and if i have colored backgrounds, i have to manually duplicate each transparent object, make the copy all white and lay it under the original. now this is a pain, and it shouldn't be hard to add a function to do it... maybe even using arbitrary color. i haven't seen this feature in illustrator... :)

regards, bostjan

On Fri, 21 Jan 2005 17:35:51 -0800 (PST), John Cliff <simarilius@...12...> wrote:

fairly simple with the tools already available.

1. Make a layer for the white objects between the background and the

main drawing elements 2) select the transparent objects do ctrl+c 3) switch to the white object layer 4) do ctrl+alt+v to paste in place 5) copy another white object 6) do ctrl+a to select all the objects in the layer 7) do shift+ctrl+v to paste style.

right. do that about 15 times each week, and you'll know what i want. :)

regards, bostjan

Up spake Aaron Spike:

Sounds like a very specific need. Perhaps something more general like the ability to write macros would do the trick.

Because Inkscape is written in C++ / C, user-level macros would be extremely difficult to implement (well). Even with something like libguile, it would still be a lot of work.

Up spake Aaron Spike:

...

Because Inkscape is written in C++ / C, user-level macros would be extremely difficult to implement (well). Even with something like libguile, it would still be a lot of work.

Oh, why is that? (If you don't mind my asking.)

Since C / C++ lack an interpreted component. Therefore you have to use a scripting language (e.g. python, scheme), which in turn requires writing C -> scripting language glue. To do it `properly' (i.e. the user as access to every layer of Inkscape internals as first-class procedures in the scripting language), you'd have to write a *lot* of glue (say, five lines of code per Inkscape function).

This is compared to writing extensions for an application that is mostly written in the same language (e.g. emacs), where the user-written code is no different from the pre-written code.

Note that I'm not saying Inkscape should have been written in another language. I'm merely pointing out that to now *add* user-programmability will take a lot of work. I could, also, be dead wrong. I've never done it before, so this is all speculation.

Could the extension/plugin/scripting support be leveraged to sole problems like this one?

Yes, programmability would allow you to script such actions, easily. The difficulty is not the problem->solution->script arc, but the script->compiled-code arc (or so I believe).

Trent Buck wrote:

Since C / C++ lack an interpreted component. Therefore you have to use a scripting language (e.g. python, scheme), which in turn requires writing C -> scripting language glue. To do it `properly' (i.e. the user as access to every layer of Inkscape internals as first-class procedures in the scripting language), you'd have to write a *lot* of glue (say, five lines of code per Inkscape function).

Ahhh... and this is where we've looked into some things. One minor point is that often even if something is in some interpreted component it still might be difficult to add good scripting if there's not a good interface/API on everything.

However, to do it properly we're looking at SWIG. It's made for exposing C++ to various scripting languages including Tcl, Python, Perl, Guile, Java, Ruby, Chicken and more. The good news is that it takes care of all that glue for you. Just list the functions to be exposed, run and voila!

And we also have Bob bringing in most of the related DOM interfaces. That in turn gives us a nice, clean, well thought out interface to document guts.

This is compared to writing extensions for an application that is mostly written in the same language (e.g. emacs), where the user-written code is no different from the pre-written code.

Sometimes. But then sometimes other. Part of what emacs so extensible is well defined paradigms and interfaces. :-)

Note that I'm not saying Inkscape should have been written in another language. I'm merely pointing out that to now *add* user-programmability will take a lot of work. I could, also, be dead wrong. I've never done it before, so this is all speculation.

Thankfully in this case you're only a bit off. :-)

In the roadmap we've had scripting and extensions for a while now, and as the other code's been done scripting has been at least kept in mind. Also much of the intent has been for extensions to be 'first class citizens' in the Inkscape runtime. This helps add to potential user scripting. And many of the core developers are into strange languages like Python and Ruby, so we're trying to keep options open.

...

Could the extension/plugin/scripting support be leveraged to sole problems like this one?

Yes, programmability would allow you to script such actions, easily. The difficulty is not the problem->solution->script arc, but the script->compiled-code arc (or so I believe).

Yes, this is where the main effort lies. However, there are things like SWIG and having nice interfaces designed that can help this happen quicker. And there's that the extensions mechanism is intented to allow for nice user scripting.

Additionally, there's some experimental Glade and C++ working going on that could help a lot with extensions running UIs, and might even end up with some suprisingly nice results. Anyway, there's lots of stuff going on in this area right now.

On Sat, 2005-01-22 at 09:09 -0600, Aaron Spike wrote:

Trent Buck wrote:

...

Because Inkscape is written in C++ / C, user-level macros would be extremely difficult to implement (well). Even with something like libguile, it would still be a lot of work.

Oh, why is that? (If you don't mind my asking.) Could the extension/plugin/scripting support be leveraged to sole problems like this one?

Yes, it is alot of work, and yes, it is on the roadmap. We already have some basic support for Javascript, Perl and Python. Nothing really usable yet, but Bob is working on making a DOM implementation that we should be able to export.

--Ted

On Sat, 22 Jan 2005 07:56:15 -0600, Aaron Spike <fretfind@...248...> wrote:

Boštjan Špetič wrote:

...

On Fri, 21 Jan 2005 17:35:51 -0800 (PST), John Cliff <simarilius@...12...> wrote:

...

fairly simple with the tools already available.

1. Make a layer for the white objects between the background and the

main drawing elements 2) select the transparent objects do ctrl+c 3) switch to the white object layer 4) do ctrl+alt+v to paste in place 5) copy another white object 6) do ctrl+a to select all the objects in the layer 7) do shift+ctrl+v to paste style.

right. do that about 15 times each week, and you'll know what i want. :)

Sounds like a very specific need. Perhaps something more general like the ability to write macros would do the trick.

hm... i'm not sure that this is so uncommon... i cannot imagine doing press-ready graphics without it... or am i simply missing something about the usual workflow? none of you ever places transparent objects onver (or partially over) a background?

regards, bostjan