Hi all,
In my quest to implement <tref> I have been examining the <use> element. In its implementation, there are several members related to the connection it makes to the element it wants to use. I'm trying to sort out which of these is necessary because it seems that there is some duplication.
SPUse has the following as members:
gchar * href; SPUseReference *ref; sigc::connection _delete_connection; sigc::connection _changed_connection; sigc::connection _transformed_connection;
But SPUseReference is in fact a subclass of URIReference. Does having this make the other members redundant to a point?
Similarly, SPTextPath uses a subclass of SPUseReference called SPUsePath, which contains all the same sigc::connection stuff that is stored in SPUse.
Is it possible that SPUse could strip itself of the connection stuff and maybe even the href (not sure exactly the need for that one) by replacing the SPUseReference with SPUsePath?
Most importantly, is there any reason that SPTRef could use SPUsePath to refer to the element it will take character data from?
Thanks, your help is much appreciated :)
Gail
An interesting side note to this is that the <use> element with text doesn't work very well. It lets you add characters on screen that don't even get added to the svg document.. etc etc... Anyway, more work I suppose - this bug may take longer than expected. ;)
Gail
Gail Banaszkiewicz wrote:
Hi all,
In my quest to implement <tref> I have been examining the <use> element. In its implementation, there are several members related to the connection it makes to the element it wants to use. I'm trying to sort out which of these is necessary because it seems that there is some duplication.
SPUse has the following as members:
gchar * href; SPUseReference *ref; sigc::connection _delete_connection; sigc::connection _changed_connection; sigc::connection _transformed_connection;
But SPUseReference is in fact a subclass of URIReference. Does having this make the other members redundant to a point?
Similarly, SPTextPath uses a subclass of SPUseReference called SPUsePath, which contains all the same sigc::connection stuff that is stored in SPUse.
Is it possible that SPUse could strip itself of the connection stuff and maybe even the href (not sure exactly the need for that one) by replacing the SPUseReference with SPUsePath?
Most importantly, is there any reason that SPTRef could use SPUsePath to refer to the element it will take character data from?
Thanks, your help is much appreciated :)
Gail
On 6/16/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
gchar * href;
this just stores the string from xlink:href attribute
SPUseReference *ref;
This is the actual reference to the origin object, which has the added convenience: it does not require that the origin object even exists when you set up the reference. This way, when you read a document, you can safely set up the ref of a clone even if the object it refs is below it in document order, i.e. does not yet exist when you build the SPUse. After the reffed object finally emerges, the URIRerefence senses that and sorts everything out.
sigc::connection _delete_connection; sigc::connection _changed_connection; sigc::connection _transformed_connection;
And these are just signal connections that notify the SPUse when something happens to its origin object so the clone needs to update itself.
But SPUseReference is in fact a subclass of URIReference. Does having this make the other members redundant to a point?
No, because URIReference does not notify you when some change happens to the reffed object. The only goal of URIReference is to reliably resolve the URI, i.e. go from the URI string to the SPObject pointer if this is at all possible. For everything else, you use signals.
Similarly, SPTextPath uses a subclass of SPUseReference called SPUsePath, which contains all the same sigc::connection stuff that is stored in SPUse.
And for the same reason: text-on-path needs to update itself when the path it refers to changes.
Is it possible that SPUse could strip itself of the connection stuff and maybe even the href (not sure exactly the need for that one) by replacing the SPUseReference with SPUsePath?
No, as I explained above. Besides, a clone can refer to any object and not just path, whereas a text-on-path can only be linked to a path. This is the reason why there are two different subclasses of URIReference used.
Most importantly, is there any reason that SPTRef could use SPUsePath to refer to the element it will take character data from?
It should use yet another subclass of URIReference that you need to create. Its sole difference from the others will be that it can only link up text or tspan objects. And yes, apart from that you will also need to link to the ::changed signal (but not ::transformed I think) of the linked text object to update your tref when the source changes.
On 6/17/07, Gail Banaszkiewicz <gbanaszk@...1686...> wrote:
According to the spec:
xlink:href = "<uri>": A URI reference to an element/fragment within an SVG document fragment whose character data content shall be used as character data for this 'tref' element. All character data within the referenced element, including character data enclosed within additional markup, will be rendered.
Yes, this seems to imply that tref may refer to any element, not just text/tspan. If we want be compliant we must allow that too. But, as far as I remember, text is stored in SPString children, and only text-related SPObjects can have such children anyway, at this time. I'm not sure we can easily extract text from any given element if it's not text, tspan etc.
bulia byak wrote:
But, as far as I remember, text is stored in SPString children, and only text-related SPObjects can have such children anyway, at this time. I'm not sure we can easily extract text from any given element if it's not text, tspan etc.
Sounds to me like it's less work to concentrate on just text / tspan for now anyway. Nice to get that working well, and then worry about the rest later. Thanks for the feedback.
Gail
participants (2)
-
bulia byak -
Gail Banaszkiewicz