Difference between revisions of "URIs and href"

From Inkscape Wiki
Jump to navigation Jump to search
(Created page with " This page documents Inkscape's handling of URI's. There are two types of URI's: # In attributes: <use xlink:href="#MyObject"> # In properties: style="fill:#MyGradient...")
 
 
Line 31: Line 31:
  
 
Currently only SPPaintServerReference and SPFilterReference are used by properties, although SPMaskReference and SPClipPathReference should be too as they correspond to CSS properties (but Inkscape doesn't support these properties yet).
 
Currently only SPPaintServerReference and SPFilterReference are used by properties, although SPMaskReference and SPClipPathReference should be too as they correspond to CSS properties (but Inkscape doesn't support these properties yet).
 +
 +
URIReference's use is a bit schizophrenic. The lack of a reference can be indicated by either a nullptr or by the function is_attached().
 +
 +
A URI is "attached" to the URIReference via URIAttach(). This function does some checks and then calls the private _setObject() function. The object in _setObject() is the object referenced by the URI. The hrefcount is of the reference object is then increased.
 +
 +
A URIReference is normally "owned" either the object which holds the reference. When used for style properties, the URIReference is usually owned by the object that contains the property. The one exception to this is paint servers in the desktop style which are owned by the document. (Until recently, paint servers were always owned by the document which caused href counting problems when objects were cloned since one could not check if the owner was a clone or not.)

Latest revision as of 09:25, 25 October 2019

This page documents Inkscape's handling of URI's.

There are two types of URI's:

  1. In attributes: <use xlink:href="#MyObject">
  2. In properties: style="fill:#MyGradient"

Basic functionality is handled by the URIReference class which has many derived classes:

  • ItemReference (LPE)
  • PathReference (LPE)
  • LPEObjectReference
  • SPClipPathReference (created in SPItem::SPItem with object )
  • SPGradientReference (created in SPGradient::SPGradient)
  • SPMarkerReference (not used!)
  • SPPaintServerReference (created in SPIPaint::read with document)
  • SPHatchReference
  • SPPatternReference
  • Persp3DReference
  • SPUseReference (created in SPUse::SPUse with object)
  • SPFilterReference (created in SPIFilter::read with object)b
  • SPTagUseReference
  • SPMaskReference (created in SPItem::SPItem with item)
  • SPTRefReference

The derived classes generally only override:

  • The constructor
  • getObject() checking to make sure it's the right type of object
  • _acceptObject() checking to make sure it's the right type of object and checking for circular references

Currently only SPPaintServerReference and SPFilterReference are used by properties, although SPMaskReference and SPClipPathReference should be too as they correspond to CSS properties (but Inkscape doesn't support these properties yet).

URIReference's use is a bit schizophrenic. The lack of a reference can be indicated by either a nullptr or by the function is_attached().

A URI is "attached" to the URIReference via URIAttach(). This function does some checks and then calls the private _setObject() function. The object in _setObject() is the object referenced by the URI. The hrefcount is of the reference object is then increased.

A URIReference is normally "owned" either the object which holds the reference. When used for style properties, the URIReference is usually owned by the object that contains the property. The one exception to this is paint servers in the desktop style which are owned by the document. (Until recently, paint servers were always owned by the document which caused href counting problems when objects were cloned since one could not check if the owner was a clone or not.)