TEI to SVG

=A Quick Look Through the TEI Figures Module=

Module: figures (Tables, Formulae, and Graphics, P5 chapter 22)

Elements Defined: table row cell formula figure figDesc graphic binaryObject

The "figure" module really contains three related - but very different - aspects.

 &lt;figure> may also contain &lt;head> (providing a title or heading for the image) &lt;figDesc> (a description of the image) and &lt;p> (commentary or caption, not a description of the image).
 * 1) Tables Elements: table row cell I don't immediately see anything corresponding to this in SVG. It wouldn't make sense, anyway - tables are really for organizing textual material. Anything else?
 * 2) Formulae Elements: formula Formula already allows for the inclusion of elements from outside the TEI, although the examples in the guidelines do not use namespaces, and namespaces are not mentioned in the text. Should we recommend that require namespaces for elements pulled in from elsewhere? If so, what about (as in the first two examples) when the notation is non-XML? Is @notation really enough?
 * 3) *How will this section generally be used? Will the most common usages be MathML or ChemML (or something similar from the sciences), or perhaps simpler formulas expressed in available Unicode characters? "By default, a is assumed to contain character data which is not validated in any way" Is this really a good idea? This means that, if you have a formula that contains non-standard characters, you would be unable to use gaiji without customization. That seems strange.
 * 4) Graphic Images Elements: figure graphic binaryObject figDesc The element is used to contain images, captions, and textual descriptions of the pictures. The images themselves are specified using the element, whose url attribute provides the location of an image.

"Where the graphic itself contains large amounts of text, perhaps with a complex structure, and perhaps difficult to distinguish from the graphic, the encoder should choose whether to regard the graphic as containing the text (in which case, a nested &lt;text> element may be included within the &lt;figure> element) or to regard the enclosed text as being a separate division of the &lt;text> element in which the graphic appears. In this latter case, an appropriate divn class element may be used for the text represented within the graphic, and the &lt;figure> element embedded within it. The choice will depend to a large degree on the encoder's understanding of the relationship between the graphic and the surrounding text."

So &lt;figure> may also contain &lt;text>.

=TEI Elements and their SVG Equivalents (approx.)=

Quick Links:

TEI Chapter 22 Tables, Formulae, and Graphics

Scalable Vector Graphics (SVG) 1.1 Specification

tei:graphic
tei:graphic "indicates the location of an inline graphic, illustration, or figure."

attributes: (In addition to global attributes) width 	The display width of the image Status: Mandatory when applicable Datatype: data.outputMeasurement height 	The display height of the image Status: Mandatory when applicable Datatype: data.outputMeasurement scale 	A scale factor to be applied to the image to make it the desired display size Status: Mandatory when applicable Datatype: data.probability url 	The target URL Status: Mandatory when applicable Datatype: data.pointer Values: The name of a URL which provides the image. mimeType 	The MIME type Status: Mandatory when applicable Datatype: data.word Values: The MIME type to be used for the object when it is decoded  Figure One: The View from the Bridge A Whistleresque view showing four or five sailing boats in the foreground, and a series of buoys strung out between them.

svg:image
svg:image "indicates that the contents of a complete file are to be rendered into a given rectangle within the current user coordinate system. The 'image' element can refer to raster image files such as PNG or JPEG or to files with MIME type of "image/svg+xml""

attributes: x = " " The x-axis coordinate of one corner of the rectangular region into which the referenced document is placed. If the attribute is not specified, the effect is as if a value of "0" were specified. Animatable: yes. y = " " The y-axis coordinate of one corner of the rectangular region into which the referenced document is placed. If the attribute is not specified, the effect is as if a value of "0" were specified. Animatable: yes. width = " " The width of the rectangular region into which the referenced document is placed. A negative value is an error (see Error processing). A value of zero disables rendering of    the element. Animatable: yes. height = " " The height of the rectangular region into which the referenced document is placed. A negative value is an error (see Error processing). A value of zero disables rendering of    the element. Animatable: yes. xlink:href = " " A URI reference. Animatable: yes.


 * Are x and y necessary?
 * xlink:href instead of url = this is nice.

 Figure One: The View from the Bridge A Whistleresque view showing four or five sailing boats in the foreground, and a series of buoys strung out between them.

Thoughts
If we were to recommend a module to import all of SVG, it would be preferable to use only svg:image and to drop tei:graphic entirely (if svg:image does indeed do everything we would need it to do in TEI). But if we don't want to "modulate" SVG (if we just say that we will refer to external SVG files if we need them), do we still want to maintain a separate tei:graphic element?

tei:figure/tei:graphic|tei:head|tei:figDesc

 * figure "contains a block containing graphics, illustrations, or figures."
 * graphic "indicates the location of an inline graphic, illustration, or figure."
 * head "contains any type of heading, for example the title of a section, or the heading of a list, glossary, manuscript description, etc."
 * figDesc "(Description of Figure) contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it."

May map to the SVG:

svg:g/svg:image|svg:title|svg:desc

 * "The 'g' element is a container element for grouping together related graphics elements."
 * "The 'image' element indicates that the contents of a complete file are to be rendered into a given rectangle within the current user coordinate system. The 'image' element can refer to raster image files such as PNG or JPEG or to files with MIME type of "image/svg+xml""
 * "Each container element or graphics element in an SVG drawing can supply a 'desc' and/or a 'title' description string where the description is text-only."
 * "The 'title' child element to an ... element serves the purposes of identifying the content of the given SVG document fragment."

Examples
  Figure One: The View from the Bridge A Whistleresque view showing four or five sailing boats in the foreground, and a series of buoys strung out between them.   Figure One: The View from the Bridge A Whistleresque view showing four or five sailing boats in the foreground, and a series of buoys strung out between them.</svg:desc> </svg:g>

Mapping attributes
Hold coordinates in individual elements using @mets:coords (instead of creating @tei:coords)

As described in the METS documentation: COORDS: an optional string attribute listing a set of visual coordinates within an image (still image or video frame). The COORDS attribute should be used as in HTML 4.

And in HTML 4.01: This attribute specifies the position and shape on the screen. The number and order of values depends on the shape being defined. Possible combinations:
 * rect: left-x, top-y, right-x, bottom-y.
 * circle: center-x, center-y, radius. Note. When the radius value is a percentage value, user agents should calculate the final radius value based on the associated object's width and height. The radius should be the smaller value of the two.
 * poly: x1, y1, x2, y2, ..., xN, yN. The first x and y coordinate pair and the last should be the same to close the polygon. When these coordinate values are not the same, user agents should infer an additional coordinate pair to close the polygon.

Coordinates are relative to the top, left corner of the object. All values are lengths. All values are separated by commas.

METS defines @mets:coords on. For TEI, it would be nice to have this attribute available to "regular" elements, not to a special element. The reasoning is that in many cases, especially when dealing with primary source texts, TEI elements refer not to a text in general but to the text as it appears in a specific physical document. It may not make sense to allow @mets:coords on &lt;p>, but it may make perfect sense to allow it on those elements described in Chapter 18 Transcription of Primary Sources that relate to a specific physical occurrance: <hi> <fw>

SVG defines various attribute values for coordinates. The system is based on a shape (identified by the element), but the attributes vary, so one could use the same attributes in the same element in various combinations to achieve the same result:

rectangle: @svg:x = length @svg:y = length (rounded edges: @svg:rx = length @svg:ry = length) circle: @svg:cx = " " The x-axis coordinate of the center of the circle. @svg:cy = " " The y-axis coordinate of the center of the circle. @svg:r = " " The radius of the circle.

ellipse: @svg:cx = " " The x-axis coordinate of the center of the ellipse. @svg:cy = " " The y-axis coordinate of the center of the ellipse. @svg:rx = " " The x-axis radius of the ellipse. @svg:ry = " " The y-axis radius of the ellipse.

polygon: @svg:points = "<list-of-points>" The points that make up the polygon. All coordinate values are in the user coordinate system.

@svg:points seems to me to be very similar to @mets:coords, except that it cannot be used to form a circle (only boundaries with straight edges)

There may be instances where one would want to use @mets:coords (for simple circles and bounding boxes) and other times when it would make more sense to use svg:x/y/width/height etc. (for more complex shapes).

We need to continue looking at SVG, whether we want to be able to import it in a module or link to external files. Or both.

tei:binaryObject
A rough equivalent for tei:binaryObject in svg. tei:binaryObject is an svg:image whose xlink:href uses the "data" URL scheme. <svg width="4in" height="3in" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"> This graphic links to an external image <image x="200" y="200" width="100px" height="100px" xlink:href="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw  AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz   ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp   a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl   ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis   F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH   hhx4dbgYKAAA7"> My image

=Using SVG with TEI=

In some instances, it makes sense to enable broad use of SVG throughout the TEI document. For instance, although most of the examples here relate to the embedding of bitmap data, the real power of SVG is in describing vector information, and it's the perfect tool for capturing dividing lines on the page, shapes, blocks of text set off from the page, decorative flourishes, simple diagrams, graphs, logos and so on. It's not the case that, for example, illuminated manuscript pages could be described in SVG in place of the use of hi-res page images, but it would be useful to specify the layout of a complex MS page (where there might be annotations on commentaries on commentaries) in terms of SVG shape structures, with the text element blocks embedded inside them, enabling a usefully approximate rendering of the page layout incorporating the transcription.