paste style loses gradients
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Inkscape |
Fix Released
|
Medium
|
Buliabyak-users | ||
Bug Description
Open samples/
other, ctrl-shift-v. The shape becomes black instead of
getting the same gradient as the other one.
Here's how to fix this:
20:04:39) bbyak: sp_style_read for a repr in clipboard
does not work, because it needs a document to resolve URIs
(20:04:54) bbyak: i.e. it works but not for URIs
(gradients etc)
(20:05:07) bbyak: what's the best workaround?
(20:05:54) bbyak: maybe store a reference to the source
document in a parallel clipboard, and pass it to style
reader?
(20:09:05) bbyak: here i come closer to the old problem
- copying defs when objects referencing them are copied
from document to document
(20:09:54) ***mental nods
(20:09:54) bbyak: i don't feel like attacking that
right now
(20:09:55) mental: hrm
(20:10:14) bbyak: i just want paste style to work
reasonably, at least within one document
(20:10:23) bbyak: and it works now, but not for uris
(20:10:48) mental: really the way we should resolve the
clipboard stuff is to (along with the copied objects)
take any gradients/other referenced objects with them,
and put them in a real SPDocument for the clipboard
(20:10:55) mental: and then pull everything back out
when pasted
(20:11:05) bbyak: ideally yes
(20:11:09) mental: unfortunately that's going to
require _major_ refactoring and reworking before we'll
even be able to chase those references
(20:12:25) bbyak: an ugly workaround may be this:
create a temporary object in target document; attach
the style to it as string, ie. without reading; read
the style from that object
(20:12:37) bbyak: what would you say to that?
(20:13:33) bbyak: that will work at least for copying
style within one document
(20:14:49) ***mental ponders
(20:16:00) mental: how would you cope with id collisions?
(20:16:23) mental: and, where would you put the
SPObject to prevent any rendering hiccups? (probably
<defs>, I guess)
(20:17:03) mental: also, that might cause problems with
SPReprDoc stuff
(20:17:10) bbyak: if it's within one document, there
are unlikely to be any collisions
(20:17:23) bbyak: as to rendering, it can be invisible
(20:18:17) bbyak: or another simpler approach: now
read_style accepts repr and object, and if object is
not null, it must correspond to the repr
(20:18:34) bbyak: but this can be laxed, so it accepts
any object or a document
(20:18:46) bbyak: so we can give it the target document
directly
(20:19:40) bbyak: if it manages to resolve ids against
that document, good; if not, we've done what we could
(20:19:57) bbyak: (at this point in history, at least)
(20:20:03) ***mental ponders
(20:20:56) bbyak: or remove the internals of read_style
into a different function and provide two wrappers for
it: one with strict repr-object correspondence check,
another accepting document instead of an object
(20:20:56) mental: so, wait, why doesn't the style work
without an SPObject again?
(20:21:18) bbyak: currently it works if object is null,
but it cannot resolve uris then
(20:21:27) mental: hmm
(20:21:44) mental: I thought SPStyle just stored raw
URIs though?
(20:21:46) bbyak: because it uses the object to get to
the document
(20:22:09) bbyak: there's ps =
sp_uri_
(20:22:27) bbyak: and if it fails, the property is not set
(20:24:31) mental: I see
(20:24:40) mental: right, it would be storing a paint
server reference in that case
(20:27:04) mental: I'm not really sure it's so good
that we're throwing away references that don't
immediately resolve
(20:27:39) bbyak: what to do with them? store raw?
(20:28:23) mental: probably. but let's not change that yet
(20:29:02) mental: I'm thinking at this point that (for
now) sp_style_
additional SPDocument * parameter, as should
sp_style_read()
(20:29:48) bbyak: via a wrapper, so as not to change
all callers
(20:31:25) mental: not sure
(20:31:41) mental: given the current implementation,
I'm not sure it's really valid to try and parse a style
without a document
(20:32:28) bbyak: but there is a special wrapper for that
(20:32:40) bbyak: which passes a null object
(20:32:52) mental: no, I mean without a document
(20:33:04) mental: right now it infers the document
from the object
(20:33:37) bbyak: but surely if it has no object, it
has no document either
(20:34:11) bbyak: sp_style_
repr); is called 6 times
(20:34:12) mental: I think you're assuming that this
was thought through carefully when it was originally
written
(20:36:26) bbyak: so do you propose to change all
callers of sp_read_style and _repr?
(20:36:46) mental: maybe
(20:38:13) bbyak: well, ok, i will now write a wrapper
which accepts document arg, and then we can change all
callers to use it
(20:38:29) mental: huh?
(20:40:55) mental: hrm
(20:41:07) bbyak: sp_read_
(20:41:47) mental: hrm
(20:47:58) Spark entered the room.
(20:49:07) Spark left the room.
(20:52:32) mental: I think maybe the best thing would
be to store the raw URI along side the paintserver,
actually
(20:55:04) bbyak: and will it be .set then?
(20:55:19) mental: ?
(20:55:33) mental: (sorry, I'm not feeling so well, so
I'm a little dense right now :/)
(20:56:02) bbyak: will the .set flag be true for that
property?
(20:58:08) mental: yes
(20:58:23) mental: .set just means that particular CSS
propertly was expliclty specified "locally", versus
inherited from a parent or defaulted
(20:59:03) bbyak: ok, i guess that will require a
change to the paintserver struct?
(21:00:30) mental: no, don't think so
(21:00:57) mental: why should the paintserver care what
URIs it's being referenced by?
(21:01:05) mental: at least in terms of storing them itself
(21:01:09) bbyak: where to store the raw uri then?
(21:01:26) mental: SPIPaint, outside of the value union
(21:01:27) bbyak: in SPIpaint?
(21:01:31) mental: yeah
(21:01:32) bbyak: aha
(21:01:43) bbyak: struct _SPIPaint {
unsigned int set : 1;
unsigned int inherit : 1;
unsigned int currentcolor : 1;
unsigned int type : 2;
union {
SPColor color;
SPPaintServer *server;
} value;
};
(21:02:00) mental: I see why you were thinking about
the paintserver though
(21:02:06) bbyak: add gchar *uri ?
(21:02:39) mental: union {
SPColor color;
struct {
SPPaintServer *server;
gchar *uri;
} paint;
};
(21:02:45) mental: I think that might be best
(21:03:09) mental: thinking about it more
(21:03:36) bbyak: oh, lots of places to change
(21:04:31) mental: yeah
(21:04:49) mental: that's a fundamental problem with
the current SPStyle code
(21:05:12) mental: even tiny changes have huge
repercussions all over the place :/
(21:07:25) bbyak: and when serializing, it must take
the id of the server if it is set, otherwise simply
copy the uri?
(21:08:39) mental: I think .... always use the uri
(21:08:56) bryce: gquark instead of char for the uri?
(21:09:02) bbyak: why store the paintserver then??
(21:10:16) mental: do you feel like modifying even more
code?
(21:10:36) mental: bryce: for URIs, I don't think it's
worth it
(21:11:19) bbyak: well, actually i always try to limit
my intrusions
(21:11:36) bbyak: maybe you can handle that for me? :)
(21:12:58) mental: not tonight
(21:13:54) mental: I'm too worn out
(21:14:09) bbyak: ok, then i will now commit my
paste-style change (which fixes text objects but breaks
for gradients) and submit the uri/document problem as a bug
| maxmula (mulamax) wrote | #1 |
| maxmula (mulamax) wrote | #2 |
Hi there,
I've encountered the same problem in v. 0.46. (win32)
I don't know if I'm sayng something already known but... here's what I see:
- In my drawing, i define an object and apply a gradient (i.e. see Image 1 attached), then I copy this object
- I define another object (bezier curves/straight lines) and then I Paste Style: I would expect to see the same gradient (or very similar) but it's not. :-(
But if I unzoom the page and select the "Edit Paths by nodes" tool, I see that this could be due to the fact that the gradient "controllers" are not correctly placed in the new object (see Image 2). Their position is not really the same but it's not clear to me what it depends on...