© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
bbfa235
demo site
(Get the code!)
> Could the ui been reworked so that we could mix up % and px
> in "expression" ?
> (…)
> If it's too diffcult to add an expression evaluator could we at
> least have extra fields to specify some additionnal spacing in px ?
Based on the current SVG 1.1 specification:
This is unlikely to work the way you propose (or for only very limited use cases where one filter definition is applied only once in the current document, and to an object which is never edited in size later on):
- AFAIU the SVG 1.1 specification does not allow a mix of absolute units with bbox percentages if the coordinate system for attributes ‘x’, ‘y’, ‘width’ and ‘height’ is defined as 'objectBounding
- Inkscape currently only supports 'objectBoundingBox' as coordinate system for the filter effects region when editing/writing filter effects. Any absolute margins (aka offsets) entered in the GUI would need to be converted to percentages of the current object bounding box when saving the filter definition in SVG.
- If the geometry of such a filtered object is edited later on (I'm not talking about scaling with the select tool, which scales the filtered result, not the geometry), the filter effects region will no longer match the user's expectation since it is now based on 'objectBoundingBox' percentages as stored in the filter definition (and knows nothing about prior absolute offset values which might have been entered in the GUI earlier). A similar issue would occur if the same filter effect is applied to differently sized objects.
- Inkscape currently only supports reading/rendering (but not editing/writing) of 'userSpaceOnUse' coordinates for the filter effects region of SVG filter effects.
AFAIU the core of your request probably is to implement 'useSpaceOnUse' coordinates for the filter effects region as option in the filter editor and add support for it when editing such filtered objects (including possibly auto-forking of filter definitions or daisy-chaining filter definitions (per object) to achieve different absolut positions and sizes when reusing the some definition for several objects).
If support for 'userSpaceOnUse' gets implemented, filters probably would need a similar 'Affects:' setting for the select tool (because the coordinates for the filter effects region in 'userSpaceOnUse' filter units need to be adjusted each time the filtered object gets moved or otherwise transformed, similar to what happens now with gradients and patterns (which Inkscape always edits/writes with values in 'userSpaceOnUse' coordinates for now)).
> filter x="-5%" y="-2.5%" width="110%" height="105%" primitiveUnits=
In my understanding, 'primitiveUnits' is the wrong attribute here - the filter effects region as shown and edited in Inkscape's filter editor depends on 'filterUnits', not 'primitiveUnits' ('primitiveUnits' defines the coordinate system of a subregion which restricts calculation and rendering of the given filter primitive):
<http://
<http://
AFAICT based on test files from W3C Inkscape does not yet support 'primitiveUnits' (neither when rendering nor for editing).