bulia byak wrote:

Hi Popolon,

on another subject, I read your blog post:

http://popolon.org/gblog2/script-masque-opaque-opaque-mask-script

and I think this kind of extension well deserves being in the Inkscape's distribution.

In fact that's moslty a workaround for linked offset I mentionned yesterday. The script group the linked offset with original shape to avoid this bug. It add white coloration to linked offset (that is easier that doing it manually (alt+click left to select linked offset then choose color if the bug is resolved). I think to directly add color choice at creation time.

However, I think that to be really usable and convenient, your script must be changed to do the following:

1. It must embed the bitmap used for the mask into the SVG, using the

data URI (see share/examples/data_uri.svg for an example).

Oh, nice, I searched this kind of trick for long time.

This way the user won't have to fiddle with the separate bitmap files - much simpler to use.

I believe that should be a more general option in inkscape like 'embed bitmaps' Because it could be interesting to keep it separatly to have a lighter svg file, and texture can be reused in several files, that is better for web usage (lower bandwidth and HDD usage, higer speed).

2. The mask must cover objects of any size, so that the user does not

have to think if the object is big enough or not. This can be achieved in two ways: either by scaling the mask bitmap to cover the entire object (but it may grow after that!), or (better) by using seamless bitmap texture and converting it to pattern first (i.e. create a large enough rect; fill it with pattern made from the bitmap; then apply that rect as mask to the object).

I believe pattern is better than growing to keep user control of effect.

There are several bug to be resolved before that, concerning mixing of pattern/clip-path/mask..., this kind of functionalities are not well (or at all) tested, and is buggy in most cases.

This bit is difficult because to do any of this, the script must know the dimensions of the objects currently selected. So I have a question for Ted: how difficult it would be to add new command line parameters in script calls, that would supply these dimensions for each selected object (now, only object IDs are supplied)? Would this break the existing extensions?

This information could be computed by content informations, add it to inkex.py should be the better solution. There is to convert C function to python or wait for an extention API.

3. And finally, to make this really useful, we need to provide at

least several different texturizing extensions - they would only differ by what bitmaps they use (plasma, wood, bubbles, clouds, etc etc)

The user can choose it's bitmap texture, I personnaly made a texture directory where I put textures created with Gimp and added a shortcut in GTK+ file dialog. The SVG filters will be a better solution to keep 100% vector files. There are several examples in the SVG specs doc. and SVG objects can be used for texturing using mask too.

Bitmap is not the better solution. Bitmap could be used for visual work and filter used at export time ?

The user can create it with Inkscape itself or with other bitmap or 3d software (like blender).

What do you all think?

I believe this kind of functionalities are usefull :)