(Modified by CmykStudent from balooii's original merge request)
When performing image-level operations (resize, crop, scale, flip,
rotate, arbitrary transform), paths referenced by non-rasterized vector
layers were being transformed twice:
1. Via the vector layer's overrides, which explicitly transforms
the referenced path to keep it in sync
2. Via the image-level queue that processes all paths independently
This patch adds a check for whether the layer has been rasterized.
If so, we bypass the vector layer's transform so the path is not
transformed a second time.
The Path Import dialog has an option to choose whether
the imported paths scale to match the dimensions of the
image or not. While this variable guards scaling the paths
themselves, it did not prevent the viewbox from being scaled
Thus, the paths always appeared to be scaled.
This patch adds a check for the scale parameter in parse_svg_viewbox ()
and conditionally scales the viewbox based on user input.
Currently to change vector layer properties,
you need to grab the VectorLayerOptions
and then grab its FillOptions or the
StrokeOptions to make changes.
To make this process more self-contained,
this patch creates a gimp_vector_layer_set ()
function that operates in the same manner
as gimp_text_layer_set ().
This patch adds properties for Fill -
Stroke properties will be added in a
follow-up commit.
This also adds
automatic tracking for Undoing/Redoing
vector property settings.
A demonstration of its use in DnD colors
and patterns onto the layer dock is
included.
...as vectors
Resolves#15997
For vector layers, we transform either the path
or the layer pixels depending on whether it is
rasterized or not. However, the check for this had
not been updated to account for the new
GimpRasterizable interface, so it did not work
properly.
This patch updates the check to use
gimp_item_is_vector_layer () instead of just
checking if the path exists, as this function
also verifies it hasn't been rasterized yet.
When we copy and paste a vector layer,
we need to reattach its path to the
(potentially) new image. Similar to what
we did for NDE filters in 8db97f4e,
we convert the existing path if necessary
before continuing with the gimp_item_convert ()
process. This prevents several CRITICALs,
for instance when copying a group that
contains vector layers rather than the
vector layers directly.
When we export paths in GIMP, we escape the <title>
text to ensure it matches the SVG specification.
On import, we were not unescaping the text. This resulted
in changed path names when copying and pasting within
GIMP itself.
This patch adds a call to g_uri_unescape_string () to convert
the escaped text back to its original format.
In 84ff512c, we made the SVG id attribute
conform to SVG standards by using a
generic ID. However, we also relied on
that field to rename the path when copying
and pasting in GIMP. As a result, the path
name was lost.
This patch adds a <title> element inside the
<path> element, per David Gowers.
This allows us to retain the original
path name when copying and pasting
paths within GIMP itself, as this also adds
a check to see if there's a title element and
uses that as the path name.
GIMP's path import code is largely copied
from an earlier version of rsvg. Therefore,
it does not include updates that made
number processing more robust
(such as properly parsing 'c1.5.2' as '1.5, 0.2'
for curve coordinates)
Per the suggestion by @federico, this patch
updates our code using rsvg-path.c from
the last version of the C-based librsvg
(updated November 3rd, 2016).
Our original code also broke if there was any
spaces after the last item in the SVG transform
attribute. This patch adds a call to
g_strstrip () to trim any unnecessary spaces
either before or after the transform string
to prevent this issue.
Resolves#13570
The SVG specification prohibits certain characters
from being used as part of a path id attribute, such as
whitespace and hyphens. Rather than try to filter the
path name selected by the user, this patch switches to
an auto-incrementing "path%d" format to ensure any
exported path can be read by strict parsers. This also
matches how we implemented ids in the SVG export
plug-in.
Rasterizable objects are all created from some side data and can be
renamed automatically based on this data (from the link file for link
layers; from the path for vector layers; from the text for text layers).
So let's share code.
- Getting rid of the dedicated vector layer options dialog (with fill
and stroke settings) which appeared when double-clicking on a vector
layer. This is a duplicated with the Path tool options.
- Double-clicking a vector layer instead will simply start the Path tool
(same as double-clicking a text layer starts the Text tool).
- The path choice settings only is missing from the Path tool options.
Instead of moving it there, I move it to the generic layer options
dialog. I don't think it's the kind of setting you really change often
(most of the time, you likely just make a new vector layer).
- Offsets are ignored too and hidden for vector layers.
- Also making sure that the path changes shows live when editing the
setting in dialog, but it is properly reverted if canceling the
attributes edition.
- Also make sure the undo step changes the path back.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
… "Confirm Text Editing" one on Text tool.
When selecting a rasterized vector layer, this will suggest to edit it
anyway (hence losing any modification since rasterization), create a new
layer based off the same path, or cancel.
New libgimpwidgets icon macros: GIMP_ICON_LAYER_LINK_LAYER and
GIMP_ICON_LAYER_VECTOR_LAYER. Note that the actual icons still need to
be done so I use temporary actual icon designs for now.
Also adding some TODOs for these.
Fix run warning:
> WARNING: icon theme has no icon 'gimp-vector-layer'.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
Per Martin Owens of Inkscape and Jonathan Watt,
one of the SVG specification editors
(https://jwatt.org/svg/authoring/#doctype-declaration),
we should not export the DTD with the GimpPath SVG.
This patch also adds an explicit SVG version to the
<svg> tag.
This patch adds additional API for setting the stroke/fill
properties of vector layers. You can now set/get color, stroke
width and stroke style via the PDB. Pattern get/set API is not
yet implemented.
This patch also updates a missing parameter check for GimpVectorLayer
in gimp_config_param_spec_duplicate (), and adds additional API
in /app to make it easier to safely retrieve GimpVectorLayerOptions.
This commit will make all transform tools run on a link layer cumulate
their transform matrix on top of the previous transform steps. It means
that as long as you don't edit the pixels another way (e.g. with a paint
tool), all your transformations will apply as a single transformation.
For instance it means that applying several transform tool steps on a
monitored link layer will be less destructive than applying the exact
same transformations on the exact same "normal" layer contents.
Even scaling an image to 1x1 then back to a big size will work very
fine!
Note nevertheless the following limitations in current implementation:
* The link layer with transformations will still show as a standard link
layer. Nothing says it has transformation applied on it right now.
* To drop transformations applied on a link layer, you have to discard
the link info, then monitor the link again. A specific action in the
contextual menu could be worth it.
* This should work with all transform tools (scale, rotation, unified,
perspective, 3D, even Warp…) but it won't work for the Flip tool, nor
will it work for the Transform actions. I will need to implement
GimpItem's rotate(), flip() and resize() methods next.
* The layer mask would still be destructively transformed (I have not
made any tests with layer masks yet, but this should be done next
too).
* I think that the "scaled-only" property is now meaningless. It is now
being replaced by the presence of the GimpMatrix3. Nevertheless I have
still not removed this property.
* The load/save code has not been redone yet to include all these
changes.
The kind of caveats we'd have to know about (and which are not planned
for change, because it's just how it is):
* Any intermediate interpolation methods are dropped when cumulating
transform steps. Only the last interpolation is stored. This is
because anyway the interpolation is only there as the best algorithm
where we visually see the less quality loss. Applying several
transformations as a single matrix will always be visually better than
applying several matrices (whatever the intermediate interpolation
methods chosen).
* This only works with the "Adjust" clipping method (basically no
clipping) because 2 transform steps with clipping won't produce the
same result as the multiplied matrix with clipping. It means that
applying a transform with clipping will downgrade your link layer to
being a normal layer.
The only issue I have with this is how to best convey that clipping is
a major setting setting here, which disables our less-destructive
abilities. Right now, people will just have to "know" it.
* Vector link layers in particular will have 2 levels of
non/less-destructivity transforms. In particular any scaling (both
through "Scale Image", "Scale Layers" and transform tools — since I
added code to detect a matrix doing only scaling and optionally
translation) done **first** will be completely non-destructive since
we will simply reload the original vector source at the right
dimensions. Any other kind of transforms will be appended through the
cumulative matrix, as raster link layers. This also includes scaling
done **after** other transforms, since we cannot easily move the
scaling first (matrix multiplication is not commutative). This second
level of scaling will therefore be *less* destructive, but still
destructive.
It is possible eventually to improve the whole thing if we add some
day the ability to request loading a vector image with a transform
matrix (it will then be up to each vector format plug-in to support
this feature or not).
Note: it could be argued that this whole implementation could in fact be
moved over to base layers, since it would allow also less-destructivity
when applying multiple transformations in a row. We would only merge
results once we edit pixels more directly.
But I think that it's not a bad idea to experiment with this new code in
the link layer. Eventually I may likely move this to the parent
GimpLayer if no blocking issues are found.
Resolves#14705
The path tool prevents creating a vector layer from an empty path.
However, the menu option "Path to Vector Layers" does not have this check.
This patch updates the check to constrain it to just one path.
Additionally, it adds a check for the path being NULL before trying to use
it in g_set_object ().
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
We now have a proper PROP_VECTOR_LAYER property in the XCF which will
store the various data relevant to vector layers.
This also fixes saving this new type of layers at all, since it was
broken in MR !773.
- Some coding style bugs.
- Factorize setting vector layer options into
gimp_vector_layer_set_vector_options(), making sure all code paths to
update the options do the same thing.
- Ceil the vector layer size since stroke width is a double. C rounds
towards zero, which means we may still have too small buffer.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
