#218 Add @svg:points to att.coordinated


The <zone> element (part of the <facsimile> family) currently defines a rectangle on a <surface> by means of four attributes (@ulx, @uly etc.). There is general agreement among those working with <facsimile> that we need a way to define non-rectangular shapes on surfaces. This proposal is the simplest and most generally-liked option arising out of the recent long discussion on TEI-L and the graphics list.

@svg:points is a "list of points", defined here:


It's not really clear to me by what mechanism an attribute from the svg namespace could be added to a core TEI class when the facsimile module is loaded, though.


  • Martin Holmes

    Martin Holmes - 2010-03-31

    Discussion on the GRAPHICS SIG suggests that adding the attribute in a different namespace is actually not a good idea, for various reasons (compatibility with DTDs, requirement for an extra file for XSD, treading on W3C toes by defining an attribute in the SVG namespace). So the proposal is now:

    add @points to att.coordinated, with a content model which is based on SVG @points:


    This definition can easily be reduced to a regular expression, and defined as a token in the same way that application/@version is defined:


    [example only]
    <rng:data type="token">
    <rng:param name="pattern">[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}</rng:param>

    token { pattern = "[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}" }
    [/example only]

  • Martin Holmes

    Martin Holmes - 2010-04-01

    More discussion suggests the following refinement:

    The @points values should all fall within the bounding box of the @ulx, @uly etc.; or, to put it another way, any agent generating or editing @points should simultaneously create @ulx, @uly etc. for the bounding rectangle.

  • Dot Porter

    Dot Porter - 2010-04-02

    The definition of zone in the Guidelines will need to be tweaked:

    Now: <zone> defines a rectangular area contained within a surface element.
    Should be: <zone> defines an area contained within a surface element.

  • Lou Burnard

    Lou Burnard - 2010-04-07
    • milestone: --> GREEN
  • Lou Burnard

    Lou Burnard - 2010-04-07

    I've marked this green and started modifying the definition of att.coordinated. I need examples, and have the following questions:
    - The restriction that the area defined by @points must lie within the bounding box defined by the parent surface is OK, but inconsistent with what we say about rectangular areas (it's perfectly OK to have a zone which extends beyond the borders of the parent surface).
    - I need someone who understands this to tell me what the correct pattern for the datatype should be
    - making these changes to att.coordinated implies the possibility of defining a nonrectangular *surface* -- is that intentional?
    - did we decide whether or not @points was an alternative to (@ulx, urx etc.)?

  • Martin Holmes

    Martin Holmes - 2010-04-07

    This is the pattern for the datatype, as a regexp (according to me -- someone else like Syd should check it):


    With regard to defining a non-rectangular surface, we are saying that @ulx, @urx and friends are mandatory even when @points is provided, so there will always be a rectangular bounding box that serves as the coordinate space for both <surface> and <zone>. But I think the ability to use @points to define a non-rectangular area within <surface> is actually a nice side-effect of this proposal.

    @points is always a supplement, never an alternative to @ulx etc.

  • Martin Holmes

    Martin Holmes - 2010-04-08

    I've just realized that negative values and floating-point values are permitted by the SVG specification. Do we want to follow that model or not? My simple regular expression permits only positive integer values for the coordinates, but it could easily be modified.

  • Nobody/Anonymous

    Council agrees that this should be implemented

  • Lou Burnard

    Lou Burnard - 2010-04-30
    • status: open --> closed
  • Lou Burnard

    Lou Burnard - 2010-04-30

    Examples still needed; implemented at revision #7432 anyway.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks