TEIWiki - User contributions [en]

Firefox

2015-09-25T12:31:21Z

Conal: /* Bookmarklet access */

==Bookmarklet access==

As I tend to look up the reference section for TEI elements in the P5 Guidelines on a regular basis, I've created some bookmarklets on my Mozilla Firefox Bookmarks Toolbar. These help me get to the information I'm after more swiftly. If they interest you, you are welcome to them. One of them is given below. To add some of the ones I use see: http://james.cummingsfamily.org.uk/TEI-LookUp.html Or to add one to your bookmarks toolbar yourself:

# Highlight and copy the code below
# Click on 'Bookmarks', then 'Organize Bookmarks'
# Select the 'Bookmarks Toolbar Folder'
# Click 'New Bookmark' icon (or 'File' -> 'New Bookmark')
# Type 'TEI P5 LookUp' (or similar) as the 'name'
# Paste the code your copied into 'location'
# Optionally give this a keyword shortcut (see below for more details) and description
# Click Ok to save the bookmark
# If the bookmark ends up somewhere else, drag and drop it back in the 'Bookmarks Toolbar Folder'
# Close the Bookmark Manager.

<pre>
<nowiki>
javascript:Qr=document.getSelection();
if(!Qr){void(Qr=prompt('P5 Element Name: ',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

In later versions of Firefox (at least from version 41), you will need to use the following bookmarklet:
<pre>
<nowiki>
javascript:Qr=document.getSelection().toString();
if(Qr==''){void(Qr=prompt('P5%20Element%20Name:%20',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

==Keyword access==
Another method in Firefox you can use is:

# Go to Bookmarks -> Organize Bookmarks -> New Bookmark
# Add a location such as http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-%s.html where "%s" indicates that this portion of the URL will be variable
# Add a name (e.g., TEI reference) and optionally description
# Add a keyword such as "tei" or even just "t" if you may use this frequently enough
# Hit OK.

Now you will be able to go to the location bar (where you type "http:..." etc. normally)--you might learn the keyboard shortcut (control-L) to be even faster) and do something like this:

tei valList

and after hitting return, you'll get brought to that reference page...

To import a predefined set of such shortcuts (to also jump to TEI Chapters, search this wiki, etc., see [http://bahai-library.com/zamir/tei-bookmarks.html this file]...

# go to Bookmarks -> Organize bookmarks
# On the window that appears, go to File -> Import
# Choose "From File"
# Find the attached file on your hard drive and click ok.

Then to use its contents,
# Go to the URL Location bar (control-L is a nice fast way)
# To go to a specific chapter, type teiN, where "N" is the chapter number. e.g., "tei7" or "teivi". The appendices are by lower case letter number, except for the probably most frequently used, A, B, and C ('m' for model classes, 'e' for elements, 'a' or attributes, respectively) and E ('b' for bibliography - done to avoid conflicting with 'e' for elements). For example, you'd type teie to go to the elements page. "teitoc" brings you to the Table of Contents.
# To search for specific content in the Guidelines, type "tgoo" then a space and then the content to search for. This will use Google to search at just the TEI site for the content you specify.
# To search at the wiki, 'teiw' followed by a space and the page title searches for a page by wiki title, while 'teiws' followed by a space and search terms searches for content at the wiki.

You can view the shortcuts by going to Bookmarks -> Organize Bookmarks . To edit their features, including optionally redefining the keyword shortcuts (but be sure not to use the same keyword used elsewhere), you can single-click an entry in the window that appears and click "Properties". (You can sort the list by keyword, etc. for a better view.)

[[Category:Documentation access tools]]

Firefox

2015-09-25T12:02:26Z

Conal: /* Bookmarklet access */

==Bookmarklet access==

As I tend to look up the reference section for TEI elements in the P5 Guidelines on a regular basis, I've created some bookmarklets on my Mozilla Firefox Bookmarks Toolbar. These help me get to the information I'm after more swiftly. If they interest you, you are welcome to them. One of them is given below. To add some of the ones I use see: http://james.cummingsfamily.org.uk/TEI-LookUp.html Or to add one to your bookmarks toolbar yourself:

# Highlight and copy the code below
# Click on 'Bookmarks', then 'Organize Bookmarks'
# Select the 'Bookmarks Toolbar Folder'
# Click 'New Bookmark' icon (or 'File' -> 'New Bookmark')
# Type 'TEI P5 LookUp' (or similar) as the 'name'
# Paste the code your copied into 'location'
# Optionally give this a keyword shortcut (see below for more details) and description
# Click Ok to save the bookmark
# If the bookmark ends up somewhere else, drag and drop it back in the 'Bookmarks Toolbar Folder'
# Close the Bookmark Manager.

<pre>
<nowiki>
javascript:Qr=document.getSelection();
if(!Qr){void(Qr=prompt('P5 Element Name: ',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

In Firefox, you will need to use the following bookmarklet:
<pre>
<nowiki>
javascript:Qr=document.getSelection().toString();
if(Qr==''){void(Qr=prompt('P5%20Element%20Name:%20',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

==Keyword access==
Another method in Firefox you can use is:

# Go to Bookmarks -> Organize Bookmarks -> New Bookmark
# Add a location such as http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-%s.html where "%s" indicates that this portion of the URL will be variable
# Add a name (e.g., TEI reference) and optionally description
# Add a keyword such as "tei" or even just "t" if you may use this frequently enough
# Hit OK.

Now you will be able to go to the location bar (where you type "http:..." etc. normally)--you might learn the keyboard shortcut (control-L) to be even faster) and do something like this:

tei valList

and after hitting return, you'll get brought to that reference page...

To import a predefined set of such shortcuts (to also jump to TEI Chapters, search this wiki, etc., see [http://bahai-library.com/zamir/tei-bookmarks.html this file]...

# go to Bookmarks -> Organize bookmarks
# On the window that appears, go to File -> Import
# Choose "From File"
# Find the attached file on your hard drive and click ok.

Then to use its contents,
# Go to the URL Location bar (control-L is a nice fast way)
# To go to a specific chapter, type teiN, where "N" is the chapter number. e.g., "tei7" or "teivi". The appendices are by lower case letter number, except for the probably most frequently used, A, B, and C ('m' for model classes, 'e' for elements, 'a' or attributes, respectively) and E ('b' for bibliography - done to avoid conflicting with 'e' for elements). For example, you'd type teie to go to the elements page. "teitoc" brings you to the Table of Contents.
# To search for specific content in the Guidelines, type "tgoo" then a space and then the content to search for. This will use Google to search at just the TEI site for the content you specify.
# To search at the wiki, 'teiw' followed by a space and the page title searches for a page by wiki title, while 'teiws' followed by a space and search terms searches for content at the wiki.

You can view the shortcuts by going to Bookmarks -> Organize Bookmarks . To edit their features, including optionally redefining the keyword shortcuts (but be sure not to use the same keyword used elsewhere), you can single-click an entry in the window that appears and click "Properties". (You can sort the list by keyword, etc. for a better view.)

[[Category:Documentation access tools]]

Firefox

2015-09-25T12:01:47Z

Conal: fix bug in bookmarklet on Firefox v41; an empty selection is still a selection - needs to convert to string

==Bookmarklet access==

As I tend to look up the reference section for TEI elements in the P5 Guidelines on a regular basis, I've created some bookmarklets on my Mozilla Firefox Bookmarks Toolbar. These help me get to the information I'm after more swiftly. If they interest you, you are welcome to them. One of them is given below. To add some of the ones I use see: http://james.cummingsfamily.org.uk/TEI-LookUp.html Or to add one to your bookmarks toolbar yourself:

# Highlight and copy the code below
# Click on 'Bookmarks', then 'Organize Bookmarks'
# Select the 'Bookmarks Toolbar Folder'
# Click 'New Bookmark' icon (or 'File' -> 'New Bookmark')
# Type 'TEI P5 LookUp' (or similar) as the 'name'
# Paste the code your copied into 'location'
# Optionally give this a keyword shortcut (see below for more details) and description
# Click Ok to save the bookmark
# If the bookmark ends up somewhere else, drag and drop it back in the 'Bookmarks Toolbar Folder'
# Close the Bookmark Manager.

<pre>
<nowiki>
javascript:Qr=document.getSelection();
if(!Qr){void(Qr=prompt('P5 Element Name: ',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

In Firefox, you will need to use the following bookmarklet:
<pre>
<nowiki>
javascript:Qr=document.getSelection().toString();%
if(Qr==''){void(Qr=prompt('P5%20Element%20Name:%20',''))};
if(Qr)location.href=
'http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-'+escape(Qr)+'.html'
</nowiki>
</pre>

==Keyword access==
Another method in Firefox you can use is:

# Go to Bookmarks -> Organize Bookmarks -> New Bookmark
# Add a location such as http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-%s.html where "%s" indicates that this portion of the URL will be variable
# Add a name (e.g., TEI reference) and optionally description
# Add a keyword such as "tei" or even just "t" if you may use this frequently enough
# Hit OK.

Now you will be able to go to the location bar (where you type "http:..." etc. normally)--you might learn the keyboard shortcut (control-L) to be even faster) and do something like this:

tei valList

and after hitting return, you'll get brought to that reference page...

To import a predefined set of such shortcuts (to also jump to TEI Chapters, search this wiki, etc., see [http://bahai-library.com/zamir/tei-bookmarks.html this file]...

# go to Bookmarks -> Organize bookmarks
# On the window that appears, go to File -> Import
# Choose "From File"
# Find the attached file on your hard drive and click ok.

Then to use its contents,
# Go to the URL Location bar (control-L is a nice fast way)
# To go to a specific chapter, type teiN, where "N" is the chapter number. e.g., "tei7" or "teivi". The appendices are by lower case letter number, except for the probably most frequently used, A, B, and C ('m' for model classes, 'e' for elements, 'a' or attributes, respectively) and E ('b' for bibliography - done to avoid conflicting with 'e' for elements). For example, you'd type teie to go to the elements page. "teitoc" brings you to the Table of Contents.
# To search for specific content in the Guidelines, type "tgoo" then a space and then the content to search for. This will use Google to search at just the TEI site for the content you specify.
# To search at the wiki, 'teiw' followed by a space and the page title searches for a page by wiki title, while 'teiws' followed by a space and search terms searches for content at the wiki.

You can view the shortcuts by going to Bookmarks -> Organize Bookmarks . To edit their features, including optionally redefining the keyword shortcuts (but be sure not to use the same keyword used elsewhere), you can single-click an entry in the window that appears and click "Properties". (You can sort the list by keyword, etc. for a better view.)

[[Category:Documentation access tools]]

Serving "application/tei+xml" from Cocoon

2010-10-22T04:57:41Z

Conal:

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

This page describes how to configure [[Apache Cocoon]] to serve TEI content as "application/tei+xml".

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

To invoke the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

This configuration will always send the TEI using the "application/tei+xml" content type. However, this may not be ideal for browsers which are not configured to handle it.

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

== Configuring your browser to request "application/tei+xml" ==

Using this configuration, you will need to configure your browser to declare that it's prepared to accept "application/tei+xml".

To configure Firefox, enter "about:config" into the address bar, find the key called "network.http.accept.default" and change it to include "application/tei+xml" in the list of acceptable content types, e.g.:

<pre>text/html;q=0.7,application/xhtml+xml;q=0.8,application/tei+xml;q=0.7,application/xml;q=0.6,*/*;q=0.4,application/json;q=0.5</pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:57:25Z

Conal:

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

This page describes how to configure [Apache Cocoon] to serve TEI content as "application/tei+xml".

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

To invoke the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

This configuration will always send the TEI using the "application/tei+xml" content type. However, this may not be ideal for browsers which are not configured to handle it.

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

== Configuring your browser to request "application/tei+xml" ==

Using this configuration, you will need to configure your browser to declare that it's prepared to accept "application/tei+xml".

To configure Firefox, enter "about:config" into the address bar, find the key called "network.http.accept.default" and change it to include "application/tei+xml" in the list of acceptable content types, e.g.:

<pre>text/html;q=0.7,application/xhtml+xml;q=0.8,application/tei+xml;q=0.7,application/xml;q=0.6,*/*;q=0.4,application/json;q=0.5</pre>

Apache Cocoon

2010-10-22T04:54:13Z

Conal:

[[Category:Tools]]
[[Category:Publishing and delivery tools]]

= Summary =

Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. The TEI consortium website is dynamically produced from TEI XML using Cocoon.

= Description =

Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development.

Cocoon implements these concepts around the notion of "component pipelines", each component on the pipeline specializing on a particular operation. This makes it possible to use a "building block" approach for web solutions, hooking together components into pipelines without any required programming.

Cocoon is "web glue for your web application development needs". It is a glue that keeps concerns separate and allows parallel evolution of the two sides, improving development pace and reducing the chance of conflicts.

Cocoon has been designed to coexist and interoperate side-by-side with your existing J2EE solutions or to give them new functionality without requiring any change in the existing infrastructure.

Cocoon interacts with many data sources, including filesystems, RDBMS, LDAP, native XML databases, SAP® systems and network-based data sources. It adapts content delivery to the capabilities of different devices like HTML, WML, PDF, SVG, and RTF, to name just a few. You can run Cocoon as a Servlet as well as through a powerful, commandline interface. The deliberate design of its abstract environment gives you the freedom to extend its functionality to meet your special needs in a highly modular fashion.

= Installation Notes =

There are many different ways to install Cocoon, and so it is probably best that you look at the [http://cocoon.apache.org/2.1/installing/index.html Cocoon installation instructions]. However, those of you using debian-compatible systems can install a packaged version of cocoon maintained by Sebastian Rahtz. See: http://tei.oucs.ox.ac.uk/teideb/

Cocoon is also distributed with the [http://exist.sourceforge.net/ eXist] XML database already built into it (Cocoon built with eXist as a "block") by the eXist project. If you are likely to want both eXist and Cocoon, this is a very handy package. [http://hcmc.uvic.ca/blogs/index.php?blog=11&p=2595&more=1&c=1&tb=1&pb=1 This blog entry] gives is a step-by-step guide used by staff at the UVic HCMC when they deploy a new Cocoon+eXist instance under the Tomcat servlet container.

= Configuration =

[[Serving "application/tei+xml" from Cocoon]]

= External Links =

* http://cocoon.apache.org/
* http://cocoon.apache.org/2.1/installing/index.html
* http://cocoon.apache.org/2.1/introduction.html
* http://tei.oucs.ox.ac.uk/teideb/
* http://en.wikipedia.org/wiki/Apache_Cocoon

Serving "application/tei+xml" from Cocoon

2010-10-22T04:53:21Z

Conal:

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

To invoke the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

This configuration will always send the TEI using the "application/tei+xml" content type. However, this may not be ideal for browsers which are not configured to handle it.

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

== Configuring your browser to request "application/tei+xml" ==

Using this configuration, you will need to configure your browser to declare that it's prepared to accept "application/tei+xml".

To configure Firefox, enter "about:config" into the address bar, find the key called "network.http.accept.default" and change it to include "application/tei+xml" in the list of acceptable content types, e.g.:

<pre>text/html;q=0.7,application/xhtml+xml;q=0.8,application/tei+xml;q=0.7,application/xml;q=0.6,*/*;q=0.4,application/json;q=0.5</pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:52:11Z

Conal:

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

To invoke the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

This configuration will always send the TEI using the "application/tei+xml" content type. However, this may not be ideal for browsers which are not configured to handle it.

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

== Configuring your browser to request "application/tei+xml" ==

Using this configuration, you will need to configure your browser to declare that it's prepared to accept "application/tei+xml".

To configure Firefox, enter "about:config" into the address bar, find the key called "network.http.accept.default" and change it to include "application/tei+xml" in the list of acceptable content types, e.g.:

<pre>text/html;q=0.7,application/xhtml+xml;q=0.8,application/tei+xml;q=0.7,application/xml;q=0.6,*/*;q=0.4,application/json;q=0.5</pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:50:47Z

Conal:

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

Invoking the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

== Configuring your browser to request "application/tei+xml" ==

Using this configuration, you will need to configure your browser to declare that it's prepared to accept "application/tei+xml".

To configure Firefox, enter "about:config" into the address bar, find the key called "network.http.accept.default" and change it to include "application/tei+xml" in the list of acceptable content types, e.g.:

<pre>text/html;q=0.7,application/xhtml+xml;q=0.8,application/tei+xml;q=0.7,application/xml;q=0.6,*/*;q=0.4,application/json;q=0.5</pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:45:30Z

Conal:

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

Invoking the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>

<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:43:27Z

Conal:

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a TEI [http://cocoon.apache.org/2.1/userdocs/xml-serializer.html XML serializer] in your sitemap.xmap file, and then invoke the serializer in your TEI pipelines.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

Invoking the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap file shows:

* A plain XML serializer
* A TEI XML serializer
* A selector for determining if a browser will accept "application/tei+xml"
* A pipeline fragment ("resource") which uses the selector to determine if a browser will accept "application/tei+xml", and uses the appropriate XML serializer
* A pipeline which invokes the above resource instead of just invoking a serializer directly

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>
<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:36:50Z

Conal:

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a serializer in your sitemap.xmap file, and then invoke the serializer in your TEI pipeline.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

Invoking the serializer:

<pre><nowiki>
<serialize type="tei"/>
</nowiki></pre>

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap shows a Reg

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>
<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</nowiki></pre>

Serving "application/tei+xml" from Cocoon

2010-10-22T04:35:46Z

Conal: New page: = How to serve TEI XML from Cocoon with the content-type "application/tei+xml" = Most websites which publish TEI XML documents describe them with the content type "application/xml" or "te...

= How to serve TEI XML from Cocoon with the content-type "application/tei+xml" =

Most websites which publish TEI XML documents describe them with the content type "application/xml" or "text/xml". These are two labels for XML files in general, and don't identify the files as specifically ''TEI'' XML. By using the content type "application/tei+xml", a webserver can make the specific claim that the XML file is TEI rather than any other kind of XML. This has the advantage that browsers can be configured to handle TEI files distinctly from the way they handle other XML files (for instance, by opening them in an XML editor).

= Simple configuration =

To specify the content type, simply configure a serializer in your sitemap.xmap file, and then invoke the serializer in your TEI pipeline.

To declare the serializer:

<pre><nowiki>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</nowiki></pre>

Invoking the serializer:

<pre><nowiki>
<serialize type="tei"/>
</pre></nowiki>

= Preferred configuration =

Most browsers will adequately display generic XML but will not be configured to handle the specific content type "application/tei+xml". For this reason, it's usually better to serve the TEI as "application/tei+xml" only if the browser specifically asks for it, and otherwise to serve it as the generic "application/xml".

In Cocoon, you can use a [http://cocoon.apache.org/2.1/userdocs/regular-expression-header-selector.html RegexpHeaderSelector] to determine if a browser is prepared to handle the specific content type. The following Cocoon sitemap shows a Reg

<pre><nowiki>
<?xml version="1.0" encoding="UTF-8"?>
<sitemap xmlns="http://apache.org/cocoon/sitemap/1.0">
<components>

<serializers>
<serializer mime-type="application/xml" name="xml" src="org.apache.cocoon.serialization.XMLSerializer"/>
<serializer mime-type="application/tei+xml" name="tei" src="org.apache.cocoon.serialization.XMLSerializer"/>
</serializers>

<selectors>
<selector name="accept-content-type" src="org.apache.cocoon.selection.RegexpHeaderSelector">
<pattern xmlns="" name="tei">application/tei\+xml</pattern>
<header-name xmlns="">accept</header-name>
</selector>
</selectors>
</components>

<resources>


<resource name="serialize-tei">
<select type="accept-content-type">
<when test="tei">
<serialize type="tei"/>
</when>
<otherwise>
<serialize type="xml"/>
</otherwise>
</select>
</resource>
</resources>

<pipelines>
<pipeline>
<match pattern="transcript/*.xml">
<generate src="tei/{1}.xml"/>
<call resource="serialize-tei"/>
</match>
</pipeline>
</pipelines>

</sitemap>
</pre></nowiki>

Apache Cocoon

2010-10-22T04:09:47Z

Conal:

[[Category:Tools]]
[[Category:Publishing and delivery tools]]

= Summary =

Apache Cocoon is a web development framework built around the concepts of separation of concerns and component-based web development. The TEI consortium website is dynamically produced from TEI XML using Cocoon.

= Description =

Apache Cocoon is a web development framework built around the concepts of separation of concerns (making sure people can interact and collaborate on a project, without stepping on each other toes) and component-based web development.

Cocoon implements these concepts around the notion of "component pipelines", each component on the pipeline specializing on a particular operation. This makes it possible to use a "building block" approach for web solutions, hooking together components into pipelines without any required programming.

Cocoon is "web glue for your web application development needs". It is a glue that keeps concerns separate and allows parallel evolution of the two sides, improving development pace and reducing the chance of conflicts.

Cocoon has been designed to coexist and interoperate side-by-side with your existing J2EE solutions or to give them new functionality without requiring any change in the existing infrastructure.

Cocoon interacts with many data sources, including filesystems, RDBMS, LDAP, native XML databases, SAP® systems and network-based data sources. It adapts content delivery to the capabilities of different devices like HTML, WML, PDF, SVG, and RTF, to name just a few. You can run Cocoon as a Servlet as well as through a powerful, commandline interface. The deliberate design of its abstract environment gives you the freedom to extend its functionality to meet your special needs in a highly modular fashion.

= Installation Notes =

There are many different ways to install Cocoon, and so it is probably best that you look at the [http://cocoon.apache.org/2.1/installing/index.html Cocoon installation instructions]. However, those of you using debian-compatible systems can install a packaged version of cocoon maintained by Sebastian Rahtz. See: http://tei.oucs.ox.ac.uk/teideb/

Cocoon is also distributed with the [http://exist.sourceforge.net/ eXist] XML database already built into it (Cocoon built with eXist as a "block") by the eXist project. If you are likely to want both eXist and Cocoon, this is a very handy package. [http://hcmc.uvic.ca/blogs/index.php?blog=11&p=2595&more=1&c=1&tb=1&pb=1 This blog entry] gives is a step-by-step guide used by staff at the UVic HCMC when they deploy a new Cocoon+eXist instance under the Tomcat servlet container.

[[Serving "application/tei+xml" from Cocoon]]

= External Links =

* http://cocoon.apache.org/
* http://cocoon.apache.org/2.1/installing/index.html
* http://cocoon.apache.org/2.1/introduction.html
* http://tei.oucs.ox.ac.uk/teideb/
* http://en.wikipedia.org/wiki/Apache_Cocoon

FacsimileMarkup

2007-01-26T06:21:58Z

Conal:

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

[[FacsimileMarkupODD|Facsimile Markup schema (ODD)]]

Notes:

# [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# early straw man facsimile modules:
## a [[StrawManFacsimileMarkup|high-end markup]]:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD equiv system to map low-end to the high-end markup?
# [[TEI_to_SVG|Investigate relations/mapping between the TEI and SVG]].

[[Category:SIG]]

FacsimileMarkup

2007-01-26T06:21:08Z

Conal:

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

# [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# [FacsimileMarkupODD|Facsimile Markup schema (ODD)]
# early straw man facsimile modules:
## a [[StrawManFacsimileMarkup|high-end markup]]:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD equiv system to map low-end to the high-end markup?
# [[TEI_to_SVG|Investigate relations/mapping between the TEI and SVG]].

[[Category:SIG]]

FacsimileMarkupODD

2007-01-26T06:19:00Z

Conal:

A sample ODD for facsimile markup. Needs documentation inserted.

<pre>
<?xml version="1.0"?>
<TEI xmlns="http://www.tei-c.org/ns/1.0" xml:lang="en">
<teiHeader>
<fileDesc>
<titleStmt>
<title>Facsimile</title>
<author><ref target="mailto:conal@nzetc.org">Conal Tuohy</ref></author>
</titleStmt>
<publicationStmt>
<p>Draft schema for TEI Council</p>
</publicationStmt>
<sourceDesc>
<p>Based on documents developed by Conal and Dot for the TEI Council in 2006</p>
</sourceDesc>
</fileDesc>
</teiHeader>
<text>
<body>
<head>Linking pages of text to graphical facsimiles</head>
<schemaSpec ident="fax-spec" xml:lang="en" prefix="">
<elementSpec ident="pg" mode="add">
<attList>
<attDef ident="start" mode="add">
<desc>Pointer to the pb element where the page starts.</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.pointer"/>
</datatype>
<default/>
<valList type="open"/>
</attDef>
</attList>
<desc>Defines a page and associated graphical facsimiles</desc>
<classes>
<memberOf key="model.sourceDescPart"/>
<memberOf key="att.global"/>
</classes>
<content xmlns:rng="http://relaxng.org/ns/structure/1.0">
<rng:zeroOrMore>
<rng:ref name="model.graphicLike"/>
</rng:zeroOrMore>
</content>
</elementSpec>
<moduleRef key="core"/>
<moduleRef key="textstructure"/>
<moduleRef key="tei"/>
<moduleRef key="header"/>
<elementSpec ident="graphic" module="core" mode="change">
<classes>
<memberOf key="model.graphicLike"/>
<memberOf key="model.titlepagePart"/>
<memberOf key="att.typed"/>
<memberOf key="att.projection"/>
</classes>
</elementSpec>
<elementSpec ident="catDesc" module="header" mode="change">
<classes>
<memberOf key="att.naming"/>
</classes>
</elementSpec>


<classSpec ident="att.projection" type="atts" mode="add">
<attList>
<attDef ident="rotation" mode="add">
<desc>Specifies an angle in degrees to rotate the graphic in a clockwise direction</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.numeric"/>
</datatype>
<default>0</default>
<valList type="open"/>
</attDef>
<attDef ident="left" mode="add">
<desc>Specifies the position of the left edge of an area within the image</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<default>0</default>
<valList type="open"/>
</attDef>
<attDef ident="top" mode="add">
<desc>Specifies the position of the top edge of an area within the image</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<default>0</default>
<valList type="open"/>
</attDef>
<attDef ident="right" mode="add">
<desc>Specifies the position of the right edge of an area within the image</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<valList type="open"/>
</attDef>
<attDef ident="bottom" mode="add">
<desc>Specifies the position of the bottom edge of an area within the image</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<valList type="open"/>
</attDef>
<attDef ident="scale" mode="add">
<desc>Specifies a scale factor to apply to the image</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<default>1</default>
<valList type="open"/>
</attDef>
<attDef ident="xscale" mode="add">
<desc>Specifies a scale factor to apply to the image in the horizontal dimension</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<default>1</default>
<valList type="open"/>
</attDef>
<attDef ident="yscale" mode="add">
<desc>Specifies a scale factor to apply to the image in the vertical dimension</desc>
<datatype>
<rng:ref xmlns:rng="http://relaxng.org/ns/structure/1.0" name="data.outputMeasurement"/>
</datatype>
<default>1</default>
<valList type="open"/>
</attDef>
</attList>
</classSpec>
<elementSpec ident="area" mode="add">
<desc>Defines a rectangular area on a page. The corresp attribute contains the value of the xml:id attribute of any TEI element whose content corresponds to this area.</desc>
<classes>
<memberOf key="model.graphicLike"/>
<memberOf key="att.projection"/>
<memberOf key="att.global.linking"/>
</classes>
<content>
<rng:empty xmlns:rng="http://relaxng.org/ns/structure/1.0"/>
</content>
</elementSpec>
<elementSpec ident="p" mode="change">
<classes>
<memberOf key="model.pLike"/>
<memberOf key="model.divPart"/>
<memberOf key="att.projection"/>
</classes>
</elementSpec>
<elementSpec ident="seg" mode="change">
<classes>
<memberOf key="model.blockLike"/>
<memberOf key="model.segLike"/>
<memberOf key="att.segLike"/>
<memberOf key="model.choicePart"/>
<memberOf key="att.projection"/>
</classes>
</elementSpec>
<elementSpec ident="ab" mode="change">
<classes>
<memberOf key="model.pLike"/>
<memberOf key="model.divPart"/>
<memberOf key="att.typed"/>
<memberOf key="att.projection"/>
</classes>
</elementSpec>
</schemaSpec>
</body>
</text>
</TEI>
</pre>

TEI to SVG

2006-07-27T01:27:42Z

Conal: /* tei:binaryObject */

=A Quick Look Through the TEI Figures Module=

Module: figures (Tables, Formulae, and Graphics, [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html P5 chapter 22])

Elements Defined: table row cell formula figure figDesc graphic binaryObject

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

#Tables<br/>Elements: table row cell<br/>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?
#Formulae<br/>Elements: formula<br/>Formula already allows for the inclusion of elements from outside the TEI, although the [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html#id2784077 examples in the guidelines] do not use namespaces, and namespaces are not mentioned in the text. Should we recommend that <figure> 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?
#*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?<br/>"By default, a <formula> is assumed to contain character data which is not validated in any way"<br/>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.
#Graphic Images<br/>Elements: figure graphic binaryObject figDesc<br/>The <figure> element is used to contain images, captions, and textual descriptions of the pictures.<br/>The images themselves are specified using the <graphic> element, whose url attribute provides the location of an image.
<pre>
<figure>
<graphic url="Fig1.pdf"/>
</figure>
</pre>
<figure> may also contain <head> (providing a title or heading for the image) <figDesc> (a description of the image) and <p> (commentary or caption, not a description of the 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 <text> element may be included within the <figure> element) or to regard the enclosed text as being a separate division of the <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 <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 <figure> may also contain <text>.

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

Quick Links:

TEI Chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics]

Scalable Vector Graphics (SVG) [http://www.w3.org/TR/SVG/ 1.1 Specification]

==tei:graphic and svg:image==

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

attributes: (In addition to global attributes)
<pre>
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
</pre>
<pre>
<figure>
<graphic url="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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:
<pre>
x = "<coordinate>"
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 = "<coordinate>"
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 = "<length>"
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 = "<length>"
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 = "<uri>"
A URI reference.
Animatable: yes.
</pre>

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

<pre>
<figure>
<svg:image xlink:href="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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?

==The nested grouping of TEI image elements==

===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===
<pre>
<figure xml:id="id1">
<graphic width="4" height="2" url="fig1.png" mimeType="image/png"/>
<head type="image title">Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>
<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
</pre>

===Notes===
*svg:g has @id, not @xml:id.
*tei:graphic/@scale and svg:image/@preserveAspectRatio (http://www.w3.org/TR/SVG/coords.html#preserveAspectRatio) are, I believe, similar, but they are Greek to me. I need help here.
*svg:image lacks @mimeType, but is it necessary?
*svg:title does not seem to have a type attribute, but since this element would be used only in reference to image titles, I don't think that this is a problem.
*As noted in a previous section, <figure> may also contain <p> or <text>. There are no equivalent elements in SVG. Would it make sense to include those elements in an SVG group as TEI namespace?

<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</svg:desc>
<tei:p>paragraph here</tei:p>
<tei:text>text contained on the image</tei:text>
</svg:g>
</pre>

Or should we encourage use of a standard TEI
block element such as a <div> or <figure> to bracket together an svg element
and any tei elements that need to be tied to it:
<pre>
<figure>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
<p>paragraph here</p>
<text>text contained on the image</text>
</figure>
</pre>

==Mapping attributes==

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

As described in the [http://www.loc.gov/standards/mets/docs/mets.v1-5.html#area 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 [http://www.w3.org/TR/REC-html40/struct/objects.html#adef-coords 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 <area>. 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 <p>, but it may make perfect sense to allow it on those elements described in Chapter 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Sources] that relate to a specific physical occurrance:
<pre>
<abbr>
<sic>
<add>
<del>
<hi>
<restore>
<gap>
<damage>
<unclear>
<space>
<fw>
</pre>

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:
<pre>
@svg:x = length
@svg:y = length
(rounded edges:
@svg:rx = length
@svg:ry = length)
</pre>
circle:
<pre>
@svg:cx = "<coordinate>"
The x-axis coordinate of the center of the circle.
@svg:cy = "<coordinate>"
The y-axis coordinate of the center of the circle.
@svg:r = "<length>"
The radius of the circle.
</pre>

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

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

@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 [http://tools.ietf.org/html/rfc2397 "data" URL scheme].
<pre>
<svg width="4in" height="3in" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<desc>This graphic links to a picture of Larry Masinter</desc>
<image x="200" y="200" width="48px" height="48px"
xlink:href="data:image/gif;base64,R0lGODdhMAAwAPAAAAAAAP///ywAAAAAMAAw
AAAC8IyPqcvt3wCcDkiLc7C0qwyGHhSWpjQu5yqmCYsapyuvUUlvONmOZtfzgFz
ByTB10QgxOR0TqBQejhRNzOfkVJ+5YiUqrXF5Y5lKh/DeuNcP5yLWGsEbtLiOSp
a/TPg7JpJHxyendzWTBfX0cxOnKPjgBzi4diinWGdkF8kjdfnycQZXZeYGejmJl
ZeGl9i2icVqaNVailT6F5iJ90m6mvuTS4OK05M0vDk0Q4XUtwvKOzrcd3iq9uis
F81M1OIcR7lEewwcLp7tuNNkM3uNna3F2JQFo97Vriy/Xl4/f1cf5VWzXyym7PH
hhx4dbgYKAAA7">
<title>Larry Masinter</title>
</image>
</svg>
</pre>

=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.

TEI to SVG

2006-07-27T01:25:47Z

Conal: /* tei:binaryObject */

=A Quick Look Through the TEI Figures Module=

Module: figures (Tables, Formulae, and Graphics, [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html P5 chapter 22])

Elements Defined: table row cell formula figure figDesc graphic binaryObject

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

#Tables<br/>Elements: table row cell<br/>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?
#Formulae<br/>Elements: formula<br/>Formula already allows for the inclusion of elements from outside the TEI, although the [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html#id2784077 examples in the guidelines] do not use namespaces, and namespaces are not mentioned in the text. Should we recommend that <figure> 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?
#*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?<br/>"By default, a <formula> is assumed to contain character data which is not validated in any way"<br/>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.
#Graphic Images<br/>Elements: figure graphic binaryObject figDesc<br/>The <figure> element is used to contain images, captions, and textual descriptions of the pictures.<br/>The images themselves are specified using the <graphic> element, whose url attribute provides the location of an image.
<pre>
<figure>
<graphic url="Fig1.pdf"/>
</figure>
</pre>
<figure> may also contain <head> (providing a title or heading for the image) <figDesc> (a description of the image) and <p> (commentary or caption, not a description of the 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 <text> element may be included within the <figure> element) or to regard the enclosed text as being a separate division of the <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 <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 <figure> may also contain <text>.

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

Quick Links:

TEI Chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics]

Scalable Vector Graphics (SVG) [http://www.w3.org/TR/SVG/ 1.1 Specification]

==tei:graphic and svg:image==

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

attributes: (In addition to global attributes)
<pre>
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
</pre>
<pre>
<figure>
<graphic url="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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:
<pre>
x = "<coordinate>"
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 = "<coordinate>"
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 = "<length>"
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 = "<length>"
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 = "<uri>"
A URI reference.
Animatable: yes.
</pre>

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

<pre>
<figure>
<svg:image xlink:href="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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?

==The nested grouping of TEI image elements==

===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===
<pre>
<figure xml:id="id1">
<graphic width="4" height="2" url="fig1.png" mimeType="image/png"/>
<head type="image title">Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>
<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
</pre>

===Notes===
*svg:g has @id, not @xml:id.
*tei:graphic/@scale and svg:image/@preserveAspectRatio (http://www.w3.org/TR/SVG/coords.html#preserveAspectRatio) are, I believe, similar, but they are Greek to me. I need help here.
*svg:image lacks @mimeType, but is it necessary?
*svg:title does not seem to have a type attribute, but since this element would be used only in reference to image titles, I don't think that this is a problem.
*As noted in a previous section, <figure> may also contain <p> or <text>. There are no equivalent elements in SVG. Would it make sense to include those elements in an SVG group as TEI namespace?

<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</svg:desc>
<tei:p>paragraph here</tei:p>
<tei:text>text contained on the image</tei:text>
</svg:g>
</pre>

Or should we encourage use of a standard TEI
block element such as a <div> or <figure> to bracket together an svg element
and any tei elements that need to be tied to it:
<pre>
<figure>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
<p>paragraph here</p>
<text>text contained on the image</text>
</figure>
</pre>

==Mapping attributes==

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

As described in the [http://www.loc.gov/standards/mets/docs/mets.v1-5.html#area 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 [http://www.w3.org/TR/REC-html40/struct/objects.html#adef-coords 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 <area>. 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 <p>, but it may make perfect sense to allow it on those elements described in Chapter 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Sources] that relate to a specific physical occurrance:
<pre>
<abbr>
<sic>
<add>
<del>
<hi>
<restore>
<gap>
<damage>
<unclear>
<space>
<fw>
</pre>

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:
<pre>
@svg:x = length
@svg:y = length
(rounded edges:
@svg:rx = length
@svg:ry = length)
</pre>
circle:
<pre>
@svg:cx = "<coordinate>"
The x-axis coordinate of the center of the circle.
@svg:cy = "<coordinate>"
The y-axis coordinate of the center of the circle.
@svg:r = "<length>"
The radius of the circle.
</pre>

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

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

@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 [http://tools.ietf.org/html/rfc2397 "data" URL scheme].
<pre>
<svg width="4in" height="3in" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<desc>This graphic links to a picture of Larry Masinter</desc>
<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">
<title>Larry Masinter</title>
</image>
</svg>
</pre>

=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.

TEI to SVG

2006-07-27T01:24:59Z

Conal: /* tei:binaryObject */

=A Quick Look Through the TEI Figures Module=

Module: figures (Tables, Formulae, and Graphics, [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html P5 chapter 22])

Elements Defined: table row cell formula figure figDesc graphic binaryObject

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

#Tables<br/>Elements: table row cell<br/>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?
#Formulae<br/>Elements: formula<br/>Formula already allows for the inclusion of elements from outside the TEI, although the [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html#id2784077 examples in the guidelines] do not use namespaces, and namespaces are not mentioned in the text. Should we recommend that <figure> 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?
#*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?<br/>"By default, a <formula> is assumed to contain character data which is not validated in any way"<br/>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.
#Graphic Images<br/>Elements: figure graphic binaryObject figDesc<br/>The <figure> element is used to contain images, captions, and textual descriptions of the pictures.<br/>The images themselves are specified using the <graphic> element, whose url attribute provides the location of an image.
<pre>
<figure>
<graphic url="Fig1.pdf"/>
</figure>
</pre>
<figure> may also contain <head> (providing a title or heading for the image) <figDesc> (a description of the image) and <p> (commentary or caption, not a description of the 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 <text> element may be included within the <figure> element) or to regard the enclosed text as being a separate division of the <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 <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 <figure> may also contain <text>.

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

Quick Links:

TEI Chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics]

Scalable Vector Graphics (SVG) [http://www.w3.org/TR/SVG/ 1.1 Specification]

==tei:graphic and svg:image==

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

attributes: (In addition to global attributes)
<pre>
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
</pre>
<pre>
<figure>
<graphic url="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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:
<pre>
x = "<coordinate>"
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 = "<coordinate>"
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 = "<length>"
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 = "<length>"
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 = "<uri>"
A URI reference.
Animatable: yes.
</pre>

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

<pre>
<figure>
<svg:image xlink:href="fig1.png"/>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>

===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?

==The nested grouping of TEI image elements==

===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===
<pre>
<figure xml:id="id1">
<graphic width="4" height="2" url="fig1.png" mimeType="image/png"/>
<head type="image title">Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
</figure>
</pre>
<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
</pre>

===Notes===
*svg:g has @id, not @xml:id.
*tei:graphic/@scale and svg:image/@preserveAspectRatio (http://www.w3.org/TR/SVG/coords.html#preserveAspectRatio) are, I believe, similar, but they are Greek to me. I need help here.
*svg:image lacks @mimeType, but is it necessary?
*svg:title does not seem to have a type attribute, but since this element would be used only in reference to image titles, I don't think that this is a problem.
*As noted in a previous section, <figure> may also contain <p> or <text>. There are no equivalent elements in SVG. Would it make sense to include those elements in an SVG group as TEI namespace?

<pre>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</svg:desc>
<tei:p>paragraph here</tei:p>
<tei:text>text contained on the image</tei:text>
</svg:g>
</pre>

Or should we encourage use of a standard TEI
block element such as a <div> or <figure> to bracket together an svg element
and any tei elements that need to be tied to it:
<pre>
<figure>
<svg:g id="id1">
<svg:image width="4" height="2" xlink:href="fig1.png"/>
<svg:title>Figure One: The View from the Bridge</svg:title>
<svg:desc>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>
<p>paragraph here</p>
<text>text contained on the image</text>
</figure>
</pre>

==Mapping attributes==

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

As described in the [http://www.loc.gov/standards/mets/docs/mets.v1-5.html#area 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 [http://www.w3.org/TR/REC-html40/struct/objects.html#adef-coords 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 <area>. 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 <p>, but it may make perfect sense to allow it on those elements described in Chapter 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Sources] that relate to a specific physical occurrance:
<pre>
<abbr>
<sic>
<add>
<del>
<hi>
<restore>
<gap>
<damage>
<unclear>
<space>
<fw>
</pre>

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:
<pre>
@svg:x = length
@svg:y = length
(rounded edges:
@svg:rx = length
@svg:ry = length)
</pre>
circle:
<pre>
@svg:cx = "<coordinate>"
The x-axis coordinate of the center of the circle.
@svg:cy = "<coordinate>"
The y-axis coordinate of the center of the circle.
@svg:r = "<length>"
The radius of the circle.
</pre>

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

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

@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 [http://tools.ietf.org/html/rfc2397 "data" URL scheme].
<pre>
<svg width="4in" height="3in" version="1.1"
xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<desc>This graphic links to an external image
</desc>
<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">
<title>My image</title>
</image>
</svg>
</pre>

=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.

StrawManFacsimileMarkup

2006-07-26T05:14:38Z

Conal: added a new version using @decls to link page breaks to page facimiles

=v v3 =
<pre>
<TEI>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...


<pg xml:id="pg1" width="100mm" height="120mm">







<graphic
facsimileType="#thumbnail"
xml:id="thumb-p1"
url="thumb-p1.jpg"
mimeType="image/jpeg"
scale="4.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>
<graphic
graphicType="#access"
xml:id="access-p1"
url="access-p1.jpg"
mimeType="image/jpeg"
scale="1.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>

</pg>


<pg xml:id="pg2" width="100mm" height="120mm">
<graphic facsimileType="#thumbnail" xml:id="thumb-p2" url="thumb-p2.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p2" url="access-p2.jpg" mimeType="image/jpeg"/>
</pg>

...
</teiHeader>
<body>
...
<pb xml:id="pb1" decls="#pg1"/>
...

<p leftX="20" topY="200" width="100" height="30">Blah blah blah blah blah.</p>
...
<pb xml:id="pb2" decls="#pg2"/>
...
<pb xml:id="pb3" decls="#pg3"/>
...
<pb xml:id="pb4" decls="#pg4"/>
...
<pb xml:id="pb5" decls="#pg5"/>
...
</body>
</TEI>
</pre>
= v2 =
<pre>
<TEI>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...



<pg xml:id="pg1" from="#pb1" to="#pb2" width="100mm" height="120mm">







<graphic
facsimileType="#thumbnail"
xml:id="thumb-p1"
url="thumb-p1.jpg"
mimeType="image/jpeg"
scale="4.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>
<graphic
graphicType="#access"
xml:id="access-p1"
url="access-p1.jpg"
mimeType="image/jpeg"
scale="1.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>

</pg>


<pg xml:id="pg2" from="#pb2" to="#pb3" width="100mm" height="120mm">
<graphic facsimileType="#thumbnail" xml:id="thumb-p2" url="thumb-p2.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p2" url="access-p2.jpg" mimeType="image/jpeg"/>
</pg>

...
</teiHeader>
<body>
...
<pb xml:id="pb1"/>
...

<p leftX="20" topY="200" width="100" height="30">Blah blah blah blah blah.</p>
...
<pb xml:id="pb2"/>
...
<pb xml:id="pb3"/>
...
<pb xml:id="pb4"/>
...
<pb xml:id="pb5"/>
...
</body>
</TEI>
</pre>

= v1 =
<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-07-25T07:34:50Z

Conal: /* v2 */

= v2 =
<pre>
<TEI>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...



<pg xml:id="pg1" from="#pb1" to="#pb2" width="100mm" height="120mm">







<graphic
facsimileType="#thumbnail"
xml:id="thumb-p1"
url="thumb-p1.jpg"
mimeType="image/jpeg"
scale="4.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>
<graphic
graphicType="#access"
xml:id="access-p1"
url="access-p1.jpg"
mimeType="image/jpeg"
scale="1.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>

</pg>


<pg xml:id="pg2" from="#pb2" to="#pb3" width="100mm" height="120mm">
<graphic facsimileType="#thumbnail" xml:id="thumb-p2" url="thumb-p2.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p2" url="access-p2.jpg" mimeType="image/jpeg"/>
</pg>

...
</teiHeader>
<body>
...
<pb xml:id="pb1"/>
...

<p leftX="20" topY="200" width="100" height="30">Blah blah blah blah blah.</p>
...
<pb xml:id="pb2"/>
...
<pb xml:id="pb3"/>
...
<pb xml:id="pb4"/>
...
<pb xml:id="pb5"/>
...
</body>
</TEI>
</pre>

= v1 =
<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-07-25T07:28:22Z

Conal: /* v2 */

= v2 =
<pre>
<TEI>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...

<pg xml:id="pg1" from="#pb1" to="#pb2" width="100mm" height="120mm">



<graphic
facsimileType="#thumbnail"
xml:id="thumb-p1"
url="thumb-p1.jpg"
mimeType="image/jpeg"
scale="4.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>
<graphic
graphicType="#access"
xml:id="access-p1"
url="access-p1.jpg"
mimeType="image/jpeg"
scale="1.0"
leftX="10mm"
topY="10mm"
width="80mm"
height="100mm"/>

</pg>
<pg xml:id="pg2" from="#pb2" to="#pb3" width="100mm" height="120mm">
<graphic facsimileType="#thumbnail" xml:id="thumb-p2" url="thumb-p2.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p2" url="access-p2.jpg" mimeType="image/jpeg"/>
</pg>

...
</teiHeader>
<body>
...
<pb xml:id="pb1"/>
...

<p leftX="20" topY="200" width="100" height="30">Blah blah blah blah blah.</p>
...
<pb xml:id="pb2"/>
...
<pb xml:id="pb3"/>
...
<pb xml:id="pb4"/>
...
<pb xml:id="pb5"/>
...
</body>
</TEI>
</pre>

= v1 =
<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-07-25T07:04:53Z

Conal:

= v2 =
<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...

<pg xml:id="pg1">
<graphic facsimileType="#thumbnail" xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
</pg>
<pg xml:id="pg2">
<graphic facsimileType="#thumbnail" xml:id="thumb-p2" url="thumb-p2.jpg" mimeType="image/jpeg"/>
<graphic facsimileType="#access" xml:id="access-p2" url="access-p2.jpg" mimeType="image/jpeg"/>
</pg>

...
</teiHeader>
</pre>

= v1 =
<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
</bibl>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

LegacyFacsimileMarkup

2006-07-25T06:50:46Z

Conal: /* ALTO */

This page includes some examples of different approaches for facsimile (image-based) markup.

=P5 Guidelines, 22.3 (Specific Elements for Graphic Images)=

The P5 Guidelines describe four elements for including graphic images in TEI documents:

*figure: contains a block containing graphics, illustrations, or figures.
*graphic: indicates the location of an inline graphic, illustration, or figure.
*binaryObject: provides encoded binary data representing an inline graphic or other object.
*figdesc: contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

<figure> is the parent element for the others. <figure> may also contain <head> (a header or title) and <p> (commentary or caption, not a description of the image):

Figure is also self-nesting, which allows for description of image fragments, though as TEI is now described those image fragments would have to be separate image files. Would it be useful to instead have a way to note coordinates using an attribute or attributes in <graphic>? (@mets:coords or @svg coordinate attributes; see [[TEI_to_SVG#Mapping_attributes]]):
<pre>
<figure>
<head>My entire image</head>
<graphic.../>
<figure>
<head>fragment 1</head>
<graphic.../>
</figure>
<figure>
<head>fragment 2</head>
<graphic.../>
</figure>
</figure>
</pre>
If a graphic contains a large amount of text, and the editor determines that the graphic actually contains that text (the text is not part of the surrounding text), <figure> may contain <text>.

==Linking Text & Image in P5==

The Guidelines describes a number of ways to link text and image using methods described fully in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment].

===Linking thumbnails to full-resolution images===
To link thumbnails to larger images, create a <ref> tag that points to the xml:id of the corresponding figure. Include the thumbnail as a graphic in the <ref>

<pre>
<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>
</pre>

===Associate images/parts of images with text elements===
Use the linking mechanism described in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment] to link together a figure (the example in the guidelines uses an external SVG file, parts of which are identified with xml:ids) and TEI elements (which are likewise identified using xml:ids).

First, we use pointers to the graphic image:
<pre>
<ptr xml:id="PD1" target="Fig1.svg#object1"/>
<ptr xml:id="PD2" target="Fig1.svg#object2"/>
</pre>

These point inside the SVG file:
<pre>
<svg width="8cm" height="3cm" viewBox="2 1 8 3">
<g id="object1">
<ellipse style="fill: #ffffff" cx="3.875" cy="3.025" rx="1.175" ry="1.175"/>
</g>
<g id="object2">
<rect style="fill: #a81616" x="7.8" y="1.9" width="2.17581" height="2.24833"/>
</g>
</svg>
</pre>

Areas in the TEI file are also uniquely identified:
<pre>
<div1 type="chapter" xml:id="CHAP1">


</div1>
<div1 type="chapter" xml:id="CHAP2">


</div1>
</pre>

Then we can use a linkgroup to pull this all together:
<pre>
<linkGrp type="callout">
<link targets="#CHAP1 #PD1"/>
<link targets="#CHAP2 #PD2"/>
</linkGrp>
</pre>

=Draft Recommendations for TEI Digital Facsimiles=

http://users.ox.ac.uk/~lou/wip/digfax.html

This document, authored by Richard Gartner and Lou Burnard and last updated in 2001, outlines ways to use TEI to represent three types of digital objects:

*complete digital transcriptions of the content of manuscript or print originals (possibly including illustrations as well as text)
*collections of digitized page images (''digital facsimiles'') intended for use as surrogates for complete manuscript or print originals
*digital objects (''digital editions'') combining both page facsimiles and transcriptions, possibly also including layers of editorial annotation

The authors attempt to address these areas of concern:

*the need to distinguish images of a manuscript or print source from images located within it;
*the need to support multiple formats of a single image;
*the need to associate metadata at different levels (e.g. collection level, item level);
*the need to associate transcription and facsimile in a standard way;
*the need to define practices which can be used equally well in both SGML and XML environments;
*the desire to avoid special purpose rules which assume nonstandard or ad hoc processing rules.

==Case 1: Transcription==

Updated to cite chapters in P5:

The content of a transcription should be marked up as a single <TEI> element using the standard TEI elements <text>, <body>, <div>, etc. from the TEI core tag sets.

Follow the Guidelines chapters 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Resources] and 13 [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html Manuscript Description].

If the source contains "significant illustrative material", use <figure> (and children) from Guidelines chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics] to insert illustrations in their proper location in the transcript.

[[Image:Teidr-fig1.gif|left|thumb|Example of the TEI <figure> element.]]

<pre>
<lb n="12"/>feond mid his geferum eallum. Feollon þa ufon
<lb n="13"/>of heofnum þurhlonge swa þreo niht and da
<lb n="14"/>gas, þa englas of heofnum on helle, and heo ealle
<lb n="15"/>forsceop drihten to deoflum.

<figure>
<head>Fall of the Angels</head>
<figDesc>Above, God, cross-nimbed, beardless, and holding a closed book,
accompanied by three angels, turns and gestures toward three angels on
the left, one of whom (Lucifer?) holds a palm frond ...</figDesc>
</figure>

<pb n="17"/>
</pre>

==Case 2: Digital Facsimile==

Should be marked as a separate <TEI> element. TEI structural tags may be used, but need not be, especially if differences between textual structure and physical structure cause overlap.

Each distinct image making up the facsimile should be encoded as a <figure> element, arranged in the normal reading sequence of the facsimile. The appropriate milestone element (<pb/> or <cb/>) should be used at the appropriate place in the facsimile.

[[Image:Teidr-fig2.gif|left|thumb|Example of the TEI <figure> element with reference to manuscript folio number.]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
</figure>
</pre>

<figure> elements may be self-nested to show that one image logically contains others (in cases where two image fit together to form one larger image).

[[Image:Teidr-fig3.gif|left|thumb|Example of nesting TEI <figure> elements.]]

<pre>
<figure n="16">
<figDesc>
<figure>
<figDesc>[Page 16: 15 lines of text (detail of upper part)]</figDesc>
</figure>
<figure>
<figDesc>[Page 16: Image of "Fall of Angels" (Ohlgren 16.11) (detail of lower part)</figDesc>
</figure>
</figDesc>
</figure>
</pre>

==3: Techniques for Referencing Images==

Recommends declaring the file containing the image as an external entity and then referencing that entity using the "entity" attribute in <figure>. This approach depends on the use of the DTD (no longer practical given the TEI's move towards using the RelaxNG schema), and relies on an attribute that is no longer included in P5.

In TEI P5 there are also two new elements, <graphic> and <binaryObject> which may be used to represent image references or images respectively. These permit the encoding of figures containing multiple images, for example. The <graphic> element has a "url" attribute which enables the association of a <figure> with its corresponding image file. The recommendations in Gartner and Burnard need to be revised substantially in this respect.

[[Image:Teidr-fig4.gif|left|thumb|Example of the TEI <graphic> element with reference to image file URL]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
</figure>
</pre>

<figure> may contain more than one graphic, so it is possible to relate multiple image files to a single physical object:
<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels" (Ohlgren
16.11)]</figDesc>
<graphic n="daylight" url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
<graphic n="uv" url="http://image.ox.ac.uk/images/bodleian/msjunius11/UV/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels" (Ohlgren
16.12)]</figDesc>
<graphic n="daylight" url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
<graphic n="uv" url="http://image.ox.ac.uk/images/bodleian/msjunius11/UV/17.jpg"/>
</figure>
</pre>

Other options mentioned in the recommendation: Xlink or Xinclude.

==4: Aligning transcription and facsimile==

The TEI Guidelines propose a number of methods for aligning parts of a document (see www.tei-c.org/Guidelines/SA). These may be briefly summarized as follows
*use the @corresp attribute to assert that a <pb> (or other reference point) in the transcription corresponds with a <pb> in the facsimile (or the reverse);
*alternatively, use a stand-off <link> element to assert the association between the two <pb> elements;
*for cross-document linking, an intermediate <xptr> may be used as the target.
(see [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html Chapter 14 Linking, Segmentation, and Alignment]).

[[Image:Teidr-fig5.gif|left|thumb|Example of linking image file with transcription using @corresp on <pb>.]]

=Method used by the Edition Production Technology (EPT): Link text and images=

The EPT (now EPPT: http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html) uses a system combining a Image Catalog combined with a special attribute for coordinates to enable linking between text and image. For more details, see here: http://beowulf.engl.uky.edu/~kiernan/eBoethius/tech.htm#tech.

==Image Catalog==

The Image Catalog is a simple XML file that consists of lists of image files organized by category. There is one category for every set of image files for a given source.
*daylight (images taken under regular lighting)
*ultraviolet (images taken under ultraviolet lighting)
*microfilm (images scanned from microfilm)

Categories are assigned unique IDs.

Within each category, the user associates each file with an ID that is ''unique within the category''. IDs will repeat across categories. Essentially, these IDs associate the files with the same object, which may be represented by multiple images.

[[Image:Ept-fig1.gif|left|thumb|Example of the EPT Image Catalog configuration file.]]

<pre>
<category name="daylight" id="d">
<file name="aih0244-JPG.jpg" id="5v" />
<file name="aih0245-JPG.jpg" id="6r" />
<file name="aih0242-JPG.jpg" id="6v" />
</category>
<category name="ultraviolet" id="u">
<file name="uv-5v.jpg" id="5v" />
<file name="uv-6r.jpg" id="6r" />
<file name="uv-6v.jpg" id="6v" />
</category>
<category name="microfilm" id="m">
<file name="mf-5v.jpg" id="5v" />
<file name="mf-6r.jpg" id="6r" />
<file name="mf-6v.jpg" id="6v" />
</category>
</pre>

The file IDs from image catalog are then associated with an attribute within the text markup itself. The attribute used is configured by the user; for the Electronic Boethius, we used the attribute ''n'' in the element ''<fol>'' (folio). The content for each folio is thus associated with the correct image files (from every category):

<pre>
<fol n="5v">
</pre>
points to
<pre>
<daylight><file id="5v"/>
</pre>
and
<pre>
<ultraviolet><file id=“5v”/>
</pre>
and
<pre>
<microfilm><file id=“5v”/>
</pre>

[[Image:Ept-fig2.gif|left|thumb|Example of EPT Image Catalog links image files with sections of text.]]

==Attribute for Coordinates==

A TEI element can be associated with a rectangular region of an image by encoding the co-ordinates of the region's corners as an attribute of that element. The EPT allows the user to assign an attribute (Electronic Boethius uses ''coords''). In whatever elements that attribute is defined, the coordinates, selected by the editor, are automatically entered by the software. The ID assigned to the categories in the Image Catalog are appended to the beginning of the coordinates.

[[Image:Ept-fig3.gif|left|thumb|Example of @coords on <figure>.]]
[[Image:Ept-fig4.gif|thumb|Screenshot of EPPT]]
<pre>
<damage coords="d:1058,738,1093,798">
</pre>

=Method used by the UVic Image Markup Tool: Annotate images=

The UVic Image Markup Tool (http://www.tapor.uvic.ca/~mholmes/image_markup/) uses TEI, modified to allow for the inclusion of SVG (http://www.w3.org/Graphics/SVG/), to create a system for annotating images.

Stated goals of the Tool:

*be simple for novices to use
*load and display a wide variety of different image formats
*allow the user to specify arbitrary rectangles on the image, and associate them with annotations
*allow such rectangles to overlap if the user wishes
*provide mechanisms for bringing overlapped rectangles to the front easily
*allow annotations to be grouped into categories, distinguished by name and appearance, to allow different classes of annotation
*require no significant knowledge of XML or TEI
*allow the use of XML code if the user wishes
*save data in an XML file which conforms to a TEI P5-based schema
*reload data from its own files
*generate a simple "Web view" of the data for display in a browser
*come packaged with an installer, Help file, and basic tutorial
*be simple for novices to use!

Simplified example from the IMT web:
<pre>
<TEI>
<teiHeader>

</teiHeader>
<text>
<body>

<div type="imtAnnotatedImage">
<svg xmlns="http://www.w3.org/2000/svg">

<image>

</image>
<rect>

</rect>
</svg>
<div type="imtAnnotationLayer">

</div>
</div>

</body>
</text>
</TEI>
</pre>

Using this system, a user can annotate many sections of a single image. Unlike the EPT system described above, in which the coordinates are stored directly in the element, here the image coordinates are stored in a separate section and linked to the annotations using unique IDs (''svg:id'' in ''<rect>'') to link the areas to the annotation content (''n'' in ''<div type="imtAnnotationLayer">'').

[[Image:Uvic-fig1.gif|left|thumb|Example of the coordinate system used by the UVic IMT.]]

<pre>
<div type="imtAnnotatedImage" xml:id="NB-B-17328">
<svg xmlns="http://www.w3.org/2000/svg">
<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="NB-B-17328.jpg" width="5060" height="6025"/>
<title>NB-B-17328.jpg</title>
<desc>5060 x 6025</desc>
<rect svg:id="NB-B-17328_0" x="4287" y="1412" width="580" height="426" style="3" color="#ff0000"/>
<rect svg:id="NB-B-17328_1" x="4067" y="2019" width="720" height="747" style="3" color="#ff0000"/>
</svg>
<div type="imtAnnotationLayer" n="NB-B-17328_0">
<head>la chandelle allume la découverte.</head>
<p>Il a trouvé la cache.</p>
</div>
<div type="imtAnnotationLayer" n="NB-B-17328_1">
<head>le couvercle de la malle</head>
<p>Il est pris sans vert</p>
</div>
</pre>

[[Image:Uvic-fig2.gif|left|thumb|Screenshot from the UVic IMT interface.]]
[[Image:Uvic-fig3.gif|thumb|Browser view of output from the UVic IMT.]]

(TEI examples from the UVic file example: http://www.tapor.uvic.ca/~mholmes/image_markup/Amant.xml)

For more details on the TEI/SVG used by the IMT, see here: http://www.tapor.uvic.ca/~mholmes/image_markup/xml.php

=Using METS to link text and image=

==What is METS?==
*Metadata Encoding and Transmission Standard (http://www.loc.gov/standards/mets/)
*“a standard for encoding … metadata regarding objects within a digital library”
*Centered at the Library of Congress
*Developed out of the metadata specs from the LOC’s “Making of America 2” project (MOA2)
*Developed by librarians and archivists, for librarians and archivists
*Accepted standard with a broad user base (http://sunsite.berkeley.edu/mets/registry/)
*Unrelated to TEI
<blockquote>
While a library may record descriptive metadata regarding a book in its collection, the book will not dissolve into a series of unconnected pages if the library fails to record structural metadata regarding the book's organization, nor will scholars be unable to evaluate the book's worth if the library fails to note that the book was produced using a Ryobi offset press.” (METS: An Overview and Tutorial)
</blockquote>

==Why METS?==
*System to organize disparate parts and relate files (and pieces of files):
**Areas on images correspond with sections of text
**Areas on images relate to one another
**Areas of text relate to one another
*METS provides sections for defining the logical and/or physical structure of the digital object
**File Section (fileSec)
**Structural Map (structMap)

==File Section==
“lists all files containing content which comprise the electronic versions of the digital object.”
*Similar to the EPT Image Catalog

==Within the FileSec==
*FileSec consists of Groups of File Locaters
**File Group: contains related files
<blockquote><fileGrp USE="facsimile"></blockquote>
**File: assigns the individual files unique identifiers
<blockquote><file ID="C-Clbiv-69v" MIMETYPE="image/tiff"></blockquote>
**File Locater: points to the location of the file, using xlink syntax
<blockquote><FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.jpg"/></blockquote>

===Example (Images)===
<pre>
<fileGrp USE="facsimile">
<file ID="C-Clbiv-69v" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.tif"/>
</file>
<file ID="C-Clbiv-70r" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-70r.tif"/>
</file>
…
</fileGrp>
</pre>

===Example (Transcript)===
<pre>
<fileGrp USE="transcript">
<file ID="id-pref-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/pref-genesis.xml"/>
</file>
<file ID="id-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/genesis.xml"/>
</file>
<file ID="id-exodus" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/exodus.xml"/>
</file>
…
</fileGrp>
</pre>

==Structural Map==
“outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files … that pertain to each element.”
*Organization may be logical or physical
*A single METS file may contain multiple structural maps

==Within the StructMap==
*StructMap consists of organizational divisions, that may nest
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
...
</div>
</div>
</pre>
*The divisions contain pointers to the files, and areas of files, indexed in the fileSec
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
<fptr FILEID="C-Clbiv-1v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="1v.32" END="1v.38"/>
</fptr>
</div>
</div>
</pre>

===Example (Basic)===
The first file pointer references the corresponding image file, while the second one references the corresponding line range (BEGIN and END) in the XML file (these are the values of, for example, @xml:id on <lb/>
<pre>
<div LABEL="Folio 69v" ORDER=“139">
<fptr FILEID="C-Clbiv-69v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.12"/>
</fptr>
</div>
<div LABEL="Folio 70r" ORDER="140">
<fptr FILEID="C-Clbiv-70r"/>
<fptr>
<area FILEID="id-genesis" BEGIN="70r.1" END="70r.38"/>
</fptr>
</div>
</pre>

===Example (Advanced)===
*<area>: reference coordinates within an image file.
**especially useful for extensively illustrated manuscripts
*create links between text and image.
**@COORDS in <area> for image files
**@BEGIN and @END in <area> for XML/TEI files
*Simplifies encoding:
**no need to define @COORDS to clutter up the TEI;
**no need to find a place to store a linking section in the TEI file
**no need to use the SVG namespace
**separate the objects (image and XML files) from the indexing of their relationships with one another

[[Image:mets-fig1.gif|left|thumb|Advanced Example of using METS and TEI to link sections of text with sections of image]]

<pre>
<div LABEL="Folio 69v" ORDER="139">
<div LABEL="Annotation 1"
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="40,12,975,121"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.annot.1"/>
</fptr>
</div>
<div LABEL="Illustration 1">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="96,87979,572"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.illus.1"/>
</fptr>
</div>
<div LABEL="Text">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="71,531,978,859"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.9"/>
</fptr>
</div>
</div>
</pre>

=ALTO=

[http://www.ccs-gmbh.com/alto/ ALTO (Analysed Layout and Text Object)] is an extension schema for METS, allowing the markup of layout information of digitised texts. It has had a bit of use in newspaper digitisation in the States, in the National Digital Newspaper Project.

In summary, it defines digitised texts as consisting of "page" elements containing "blocks" which have rectangular coordinates assigned to them using attributes HPOS, VPOS, WIDTH, and HEIGHT, and also a ROTATION. Each block element's page is associated with image files with stand-off markup in the normal METS way.

By contrast we need a different way to relate TEI content elements to pages, since the dominant hierarchy in TEI is logical rather than physical (i.e. div rather than page).

[http://www.loc.gov/ndnp/alto_1-1-041.xsd XML Schema for ALTO]

=Conclusions=
*Draft Recommendations for TEI Digital Facsimiles
**Not robust
**No specific image/text linking
**Based on TEI P3 (though updated on this page to TEI P5)
*Edition Production Technology (EPT)
**Designed for textual annotation, but can annotate illustrations as well
**Markup schema is not defined - editors can use their own markup schemas (requires @coords)
**Complex
**Dependent on editing software
**Supports most image file formats (jpeg, tiff, gif, bmp)
**No visualization outside of the editing environment
*UVic Image Annotation Tool
**Simple
**Annotates via description – no “text encoding” (i.e., cannot include in an electronic transcription)
**Based on accepted standards
**Markup schema is defined (extended TEI + SVG)
**Visualization through SVG-enabled browser
*METS
**Very complex
**Objects separate from indexes
**Flexible – can link many textual and image sections (Venetus A – link main text and several layers of annotations)
**No visualization (yet) for the more advanced image-text links

LegacyFacsimileMarkup

2006-07-25T06:48:19Z

Conal: added ALTO references

This page includes some examples of different approaches for facsimile (image-based) markup.

=P5 Guidelines, 22.3 (Specific Elements for Graphic Images)=

The P5 Guidelines describe four elements for including graphic images in TEI documents:

*figure: contains a block containing graphics, illustrations, or figures.
*graphic: indicates the location of an inline graphic, illustration, or figure.
*binaryObject: provides encoded binary data representing an inline graphic or other object.
*figdesc: contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

<figure> is the parent element for the others. <figure> may also contain <head> (a header or title) and <p> (commentary or caption, not a description of the image):

Figure is also self-nesting, which allows for description of image fragments, though as TEI is now described those image fragments would have to be separate image files. Would it be useful to instead have a way to note coordinates using an attribute or attributes in <graphic>? (@mets:coords or @svg coordinate attributes; see [[TEI_to_SVG#Mapping_attributes]]):
<pre>
<figure>
<head>My entire image</head>
<graphic.../>
<figure>
<head>fragment 1</head>
<graphic.../>
</figure>
<figure>
<head>fragment 2</head>
<graphic.../>
</figure>
</figure>
</pre>
If a graphic contains a large amount of text, and the editor determines that the graphic actually contains that text (the text is not part of the surrounding text), <figure> may contain <text>.

==Linking Text & Image in P5==

The Guidelines describes a number of ways to link text and image using methods described fully in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment].

===Linking thumbnails to full-resolution images===
To link thumbnails to larger images, create a <ref> tag that points to the xml:id of the corresponding figure. Include the thumbnail as a graphic in the <ref>

<pre>
<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>
</pre>

===Associate images/parts of images with text elements===
Use the linking mechanism described in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment] to link together a figure (the example in the guidelines uses an external SVG file, parts of which are identified with xml:ids) and TEI elements (which are likewise identified using xml:ids).

First, we use pointers to the graphic image:
<pre>
<ptr xml:id="PD1" target="Fig1.svg#object1"/>
<ptr xml:id="PD2" target="Fig1.svg#object2"/>
</pre>

These point inside the SVG file:
<pre>
<svg width="8cm" height="3cm" viewBox="2 1 8 3">
<g id="object1">
<ellipse style="fill: #ffffff" cx="3.875" cy="3.025" rx="1.175" ry="1.175"/>
</g>
<g id="object2">
<rect style="fill: #a81616" x="7.8" y="1.9" width="2.17581" height="2.24833"/>
</g>
</svg>
</pre>

Areas in the TEI file are also uniquely identified:
<pre>
<div1 type="chapter" xml:id="CHAP1">


</div1>
<div1 type="chapter" xml:id="CHAP2">


</div1>
</pre>

Then we can use a linkgroup to pull this all together:
<pre>
<linkGrp type="callout">
<link targets="#CHAP1 #PD1"/>
<link targets="#CHAP2 #PD2"/>
</linkGrp>
</pre>

=Draft Recommendations for TEI Digital Facsimiles=

http://users.ox.ac.uk/~lou/wip/digfax.html

This document, authored by Richard Gartner and Lou Burnard and last updated in 2001, outlines ways to use TEI to represent three types of digital objects:

*complete digital transcriptions of the content of manuscript or print originals (possibly including illustrations as well as text)
*collections of digitized page images (''digital facsimiles'') intended for use as surrogates for complete manuscript or print originals
*digital objects (''digital editions'') combining both page facsimiles and transcriptions, possibly also including layers of editorial annotation

The authors attempt to address these areas of concern:

*the need to distinguish images of a manuscript or print source from images located within it;
*the need to support multiple formats of a single image;
*the need to associate metadata at different levels (e.g. collection level, item level);
*the need to associate transcription and facsimile in a standard way;
*the need to define practices which can be used equally well in both SGML and XML environments;
*the desire to avoid special purpose rules which assume nonstandard or ad hoc processing rules.

==Case 1: Transcription==

Updated to cite chapters in P5:

The content of a transcription should be marked up as a single <TEI> element using the standard TEI elements <text>, <body>, <div>, etc. from the TEI core tag sets.

Follow the Guidelines chapters 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Resources] and 13 [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html Manuscript Description].

If the source contains "significant illustrative material", use <figure> (and children) from Guidelines chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics] to insert illustrations in their proper location in the transcript.

[[Image:Teidr-fig1.gif|left|thumb|Example of the TEI <figure> element.]]

<pre>
<lb n="12"/>feond mid his geferum eallum. Feollon þa ufon
<lb n="13"/>of heofnum þurhlonge swa þreo niht and da
<lb n="14"/>gas, þa englas of heofnum on helle, and heo ealle
<lb n="15"/>forsceop drihten to deoflum.

<figure>
<head>Fall of the Angels</head>
<figDesc>Above, God, cross-nimbed, beardless, and holding a closed book,
accompanied by three angels, turns and gestures toward three angels on
the left, one of whom (Lucifer?) holds a palm frond ...</figDesc>
</figure>

<pb n="17"/>
</pre>

==Case 2: Digital Facsimile==

Should be marked as a separate <TEI> element. TEI structural tags may be used, but need not be, especially if differences between textual structure and physical structure cause overlap.

Each distinct image making up the facsimile should be encoded as a <figure> element, arranged in the normal reading sequence of the facsimile. The appropriate milestone element (<pb/> or <cb/>) should be used at the appropriate place in the facsimile.

[[Image:Teidr-fig2.gif|left|thumb|Example of the TEI <figure> element with reference to manuscript folio number.]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
</figure>
</pre>

<figure> elements may be self-nested to show that one image logically contains others (in cases where two image fit together to form one larger image).

[[Image:Teidr-fig3.gif|left|thumb|Example of nesting TEI <figure> elements.]]

<pre>
<figure n="16">
<figDesc>
<figure>
<figDesc>[Page 16: 15 lines of text (detail of upper part)]</figDesc>
</figure>
<figure>
<figDesc>[Page 16: Image of "Fall of Angels" (Ohlgren 16.11) (detail of lower part)</figDesc>
</figure>
</figDesc>
</figure>
</pre>

==3: Techniques for Referencing Images==

Recommends declaring the file containing the image as an external entity and then referencing that entity using the "entity" attribute in <figure>. This approach depends on the use of the DTD (no longer practical given the TEI's move towards using the RelaxNG schema), and relies on an attribute that is no longer included in P5.

In TEI P5 there are also two new elements, <graphic> and <binaryObject> which may be used to represent image references or images respectively. These permit the encoding of figures containing multiple images, for example. The <graphic> element has a "url" attribute which enables the association of a <figure> with its corresponding image file. The recommendations in Gartner and Burnard need to be revised substantially in this respect.

[[Image:Teidr-fig4.gif|left|thumb|Example of the TEI <graphic> element with reference to image file URL]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
</figure>
</pre>

<figure> may contain more than one graphic, so it is possible to relate multiple image files to a single physical object:
<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels" (Ohlgren
16.11)]</figDesc>
<graphic n="daylight" url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
<graphic n="uv" url="http://image.ox.ac.uk/images/bodleian/msjunius11/UV/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels" (Ohlgren
16.12)]</figDesc>
<graphic n="daylight" url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
<graphic n="uv" url="http://image.ox.ac.uk/images/bodleian/msjunius11/UV/17.jpg"/>
</figure>
</pre>

Other options mentioned in the recommendation: Xlink or Xinclude.

==4: Aligning transcription and facsimile==

The TEI Guidelines propose a number of methods for aligning parts of a document (see www.tei-c.org/Guidelines/SA). These may be briefly summarized as follows
*use the @corresp attribute to assert that a <pb> (or other reference point) in the transcription corresponds with a <pb> in the facsimile (or the reverse);
*alternatively, use a stand-off <link> element to assert the association between the two <pb> elements;
*for cross-document linking, an intermediate <xptr> may be used as the target.
(see [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html Chapter 14 Linking, Segmentation, and Alignment]).

[[Image:Teidr-fig5.gif|left|thumb|Example of linking image file with transcription using @corresp on <pb>.]]

=Method used by the Edition Production Technology (EPT): Link text and images=

The EPT (now EPPT: http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html) uses a system combining a Image Catalog combined with a special attribute for coordinates to enable linking between text and image. For more details, see here: http://beowulf.engl.uky.edu/~kiernan/eBoethius/tech.htm#tech.

==Image Catalog==

The Image Catalog is a simple XML file that consists of lists of image files organized by category. There is one category for every set of image files for a given source.
*daylight (images taken under regular lighting)
*ultraviolet (images taken under ultraviolet lighting)
*microfilm (images scanned from microfilm)

Categories are assigned unique IDs.

Within each category, the user associates each file with an ID that is ''unique within the category''. IDs will repeat across categories. Essentially, these IDs associate the files with the same object, which may be represented by multiple images.

[[Image:Ept-fig1.gif|left|thumb|Example of the EPT Image Catalog configuration file.]]

<pre>
<category name="daylight" id="d">
<file name="aih0244-JPG.jpg" id="5v" />
<file name="aih0245-JPG.jpg" id="6r" />
<file name="aih0242-JPG.jpg" id="6v" />
</category>
<category name="ultraviolet" id="u">
<file name="uv-5v.jpg" id="5v" />
<file name="uv-6r.jpg" id="6r" />
<file name="uv-6v.jpg" id="6v" />
</category>
<category name="microfilm" id="m">
<file name="mf-5v.jpg" id="5v" />
<file name="mf-6r.jpg" id="6r" />
<file name="mf-6v.jpg" id="6v" />
</category>
</pre>

The file IDs from image catalog are then associated with an attribute within the text markup itself. The attribute used is configured by the user; for the Electronic Boethius, we used the attribute ''n'' in the element ''<fol>'' (folio). The content for each folio is thus associated with the correct image files (from every category):

<pre>
<fol n="5v">
</pre>
points to
<pre>
<daylight><file id="5v"/>
</pre>
and
<pre>
<ultraviolet><file id=“5v”/>
</pre>
and
<pre>
<microfilm><file id=“5v”/>
</pre>

[[Image:Ept-fig2.gif|left|thumb|Example of EPT Image Catalog links image files with sections of text.]]

==Attribute for Coordinates==

A TEI element can be associated with a rectangular region of an image by encoding the co-ordinates of the region's corners as an attribute of that element. The EPT allows the user to assign an attribute (Electronic Boethius uses ''coords''). In whatever elements that attribute is defined, the coordinates, selected by the editor, are automatically entered by the software. The ID assigned to the categories in the Image Catalog are appended to the beginning of the coordinates.

[[Image:Ept-fig3.gif|left|thumb|Example of @coords on <figure>.]]
[[Image:Ept-fig4.gif|thumb|Screenshot of EPPT]]
<pre>
<damage coords="d:1058,738,1093,798">
</pre>

=Method used by the UVic Image Markup Tool: Annotate images=

The UVic Image Markup Tool (http://www.tapor.uvic.ca/~mholmes/image_markup/) uses TEI, modified to allow for the inclusion of SVG (http://www.w3.org/Graphics/SVG/), to create a system for annotating images.

Stated goals of the Tool:

*be simple for novices to use
*load and display a wide variety of different image formats
*allow the user to specify arbitrary rectangles on the image, and associate them with annotations
*allow such rectangles to overlap if the user wishes
*provide mechanisms for bringing overlapped rectangles to the front easily
*allow annotations to be grouped into categories, distinguished by name and appearance, to allow different classes of annotation
*require no significant knowledge of XML or TEI
*allow the use of XML code if the user wishes
*save data in an XML file which conforms to a TEI P5-based schema
*reload data from its own files
*generate a simple "Web view" of the data for display in a browser
*come packaged with an installer, Help file, and basic tutorial
*be simple for novices to use!

Simplified example from the IMT web:
<pre>
<TEI>
<teiHeader>

</teiHeader>
<text>
<body>

<div type="imtAnnotatedImage">
<svg xmlns="http://www.w3.org/2000/svg">

<image>

</image>
<rect>

</rect>
</svg>
<div type="imtAnnotationLayer">

</div>
</div>

</body>
</text>
</TEI>
</pre>

Using this system, a user can annotate many sections of a single image. Unlike the EPT system described above, in which the coordinates are stored directly in the element, here the image coordinates are stored in a separate section and linked to the annotations using unique IDs (''svg:id'' in ''<rect>'') to link the areas to the annotation content (''n'' in ''<div type="imtAnnotationLayer">'').

[[Image:Uvic-fig1.gif|left|thumb|Example of the coordinate system used by the UVic IMT.]]

<pre>
<div type="imtAnnotatedImage" xml:id="NB-B-17328">
<svg xmlns="http://www.w3.org/2000/svg">
<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="NB-B-17328.jpg" width="5060" height="6025"/>
<title>NB-B-17328.jpg</title>
<desc>5060 x 6025</desc>
<rect svg:id="NB-B-17328_0" x="4287" y="1412" width="580" height="426" style="3" color="#ff0000"/>
<rect svg:id="NB-B-17328_1" x="4067" y="2019" width="720" height="747" style="3" color="#ff0000"/>
</svg>
<div type="imtAnnotationLayer" n="NB-B-17328_0">
<head>la chandelle allume la découverte.</head>
<p>Il a trouvé la cache.</p>
</div>
<div type="imtAnnotationLayer" n="NB-B-17328_1">
<head>le couvercle de la malle</head>
<p>Il est pris sans vert</p>
</div>
</pre>

[[Image:Uvic-fig2.gif|left|thumb|Screenshot from the UVic IMT interface.]]
[[Image:Uvic-fig3.gif|thumb|Browser view of output from the UVic IMT.]]

(TEI examples from the UVic file example: http://www.tapor.uvic.ca/~mholmes/image_markup/Amant.xml)

For more details on the TEI/SVG used by the IMT, see here: http://www.tapor.uvic.ca/~mholmes/image_markup/xml.php

=Using METS to link text and image=

==What is METS?==
*Metadata Encoding and Transmission Standard (http://www.loc.gov/standards/mets/)
*“a standard for encoding … metadata regarding objects within a digital library”
*Centered at the Library of Congress
*Developed out of the metadata specs from the LOC’s “Making of America 2” project (MOA2)
*Developed by librarians and archivists, for librarians and archivists
*Accepted standard with a broad user base (http://sunsite.berkeley.edu/mets/registry/)
*Unrelated to TEI
<blockquote>
While a library may record descriptive metadata regarding a book in its collection, the book will not dissolve into a series of unconnected pages if the library fails to record structural metadata regarding the book's organization, nor will scholars be unable to evaluate the book's worth if the library fails to note that the book was produced using a Ryobi offset press.” (METS: An Overview and Tutorial)
</blockquote>

==Why METS?==
*System to organize disparate parts and relate files (and pieces of files):
**Areas on images correspond with sections of text
**Areas on images relate to one another
**Areas of text relate to one another
*METS provides sections for defining the logical and/or physical structure of the digital object
**File Section (fileSec)
**Structural Map (structMap)

==File Section==
“lists all files containing content which comprise the electronic versions of the digital object.”
*Similar to the EPT Image Catalog

==Within the FileSec==
*FileSec consists of Groups of File Locaters
**File Group: contains related files
<blockquote><fileGrp USE="facsimile"></blockquote>
**File: assigns the individual files unique identifiers
<blockquote><file ID="C-Clbiv-69v" MIMETYPE="image/tiff"></blockquote>
**File Locater: points to the location of the file, using xlink syntax
<blockquote><FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.jpg"/></blockquote>

===Example (Images)===
<pre>
<fileGrp USE="facsimile">
<file ID="C-Clbiv-69v" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.tif"/>
</file>
<file ID="C-Clbiv-70r" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-70r.tif"/>
</file>
…
</fileGrp>
</pre>

===Example (Transcript)===
<pre>
<fileGrp USE="transcript">
<file ID="id-pref-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/pref-genesis.xml"/>
</file>
<file ID="id-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/genesis.xml"/>
</file>
<file ID="id-exodus" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/exodus.xml"/>
</file>
…
</fileGrp>
</pre>

==Structural Map==
“outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files … that pertain to each element.”
*Organization may be logical or physical
*A single METS file may contain multiple structural maps

==Within the StructMap==
*StructMap consists of organizational divisions, that may nest
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
...
</div>
</div>
</pre>
*The divisions contain pointers to the files, and areas of files, indexed in the fileSec
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
<fptr FILEID="C-Clbiv-1v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="1v.32" END="1v.38"/>
</fptr>
</div>
</div>
</pre>

===Example (Basic)===
The first file pointer references the corresponding image file, while the second one references the corresponding line range (BEGIN and END) in the XML file (these are the values of, for example, @xml:id on <lb/>
<pre>
<div LABEL="Folio 69v" ORDER=“139">
<fptr FILEID="C-Clbiv-69v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.12"/>
</fptr>
</div>
<div LABEL="Folio 70r" ORDER="140">
<fptr FILEID="C-Clbiv-70r"/>
<fptr>
<area FILEID="id-genesis" BEGIN="70r.1" END="70r.38"/>
</fptr>
</div>
</pre>

===Example (Advanced)===
*<area>: reference coordinates within an image file.
**especially useful for extensively illustrated manuscripts
*create links between text and image.
**@COORDS in <area> for image files
**@BEGIN and @END in <area> for XML/TEI files
*Simplifies encoding:
**no need to define @COORDS to clutter up the TEI;
**no need to find a place to store a linking section in the TEI file
**no need to use the SVG namespace
**separate the objects (image and XML files) from the indexing of their relationships with one another

[[Image:mets-fig1.gif|left|thumb|Advanced Example of using METS and TEI to link sections of text with sections of image]]

<pre>
<div LABEL="Folio 69v" ORDER="139">
<div LABEL="Annotation 1"
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="40,12,975,121"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.annot.1"/>
</fptr>
</div>
<div LABEL="Illustration 1">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="96,87979,572"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.illus.1"/>
</fptr>
</div>
<div LABEL="Text">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="71,531,978,859"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.9"/>
</fptr>
</div>
</div>
</pre>

=ALTO=

[http://www.ccs-gmbh.com/alto/ ALTO (Analysed Layout and Text Object)] is an extension schema for METS, allowing the markup of layout information of digitised texts. It has had a bit of use in newspaper digitisation in the States, in the National Digital Newspaper Project.

In summary, it defines digitised texts as belonging to "blocks" which have rectangular coordinates assigned to them using attributes HPOS, VPOS, WIDTH, and HEIGHT, and also a ROTATION. Each block belongs to a page which is associated with image files in the normal METS way.

By contrast we need a different way to relate TEI content elements to pages, since the dominant hierarchy in TEI is logical rather than physical (i.e. div rather than page).

[http://www.loc.gov/ndnp/alto_1-1-041.xsd XML Schema for ALTO]

=Conclusions=
*Draft Recommendations for TEI Digital Facsimiles
**Not robust
**No specific image/text linking
**Based on TEI P3 (though updated on this page to TEI P5)
*Edition Production Technology (EPT)
**Designed for textual annotation, but can annotate illustrations as well
**Markup schema is not defined - editors can use their own markup schemas (requires @coords)
**Complex
**Dependent on editing software
**Supports most image file formats (jpeg, tiff, gif, bmp)
**No visualization outside of the editing environment
*UVic Image Annotation Tool
**Simple
**Annotates via description – no “text encoding” (i.e., cannot include in an electronic transcription)
**Based on accepted standards
**Markup schema is defined (extended TEI + SVG)
**Visualization through SVG-enabled browser
*METS
**Very complex
**Objects separate from indexes
**Flexible – can link many textual and image sections (Venetus A – link main text and several layers of annotations)
**No visualization (yet) for the more advanced image-text links

LegacyFacsimileMarkup

2006-06-07T11:58:49Z

Conal: /* Method used by the UVic Image Markup Tool: Annotate images */

This page includes some examples of different approaches for facsimile (image-based) markup.

=P5 Guidelines, 22.3 (Specific Elements for Graphic Images)=

The P5 Guidelines describe four elements for including graphic images in TEI documents:

*figure: contains a block containing graphics, illustrations, or figures.
*graphic: indicates the location of an inline graphic, illustration, or figure.
*binaryObject: provides encoded binary data representing an inline graphic or other object.
*figdesc: contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

<figure> is the parent element for the others. <figure> may also contain <head> (a header or title) and <p> (commentary or caption, not a description of the image).

If a graphic contains a large amount of text, and the editor determines that the graphic actually contains that text (the text is not part of the surrounding text), <figure> may contain <text>.

==Linking Text & Image in P5==

The Guidelines describes a number of ways to link text and image using methods described fully in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment].

===Linking thumbnails to full-resolution images===
To link thumbnails to larger images, create a <ref> tag that points to the xml:id of the corresponding figure. Include the thumbnail as a graphic in the <ref>

<pre>
<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>
</pre>

===Associate images/parts of images with text elements===
Use the linking mechanism described in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment] to link together a figure (the example in the guidelines uses an external SVG file, parts of which are identified with xml:ids) and TEI elements (which are likewise identified using xml:ids).

First, we use pointers to the graphic image:
<pre>
<ptr xml:id="PD1" target="Fig1.svg#object1"/>
<ptr xml:id="PD2" target="Fig1.svg#object2"/>
</pre>

These point inside the SVG file:
<pre>
<svg width="8cm" height="3cm" viewBox="2 1 8 3">
<g id="object1">
<ellipse style="fill: #ffffff" cx="3.875" cy="3.025" rx="1.175" ry="1.175"/>
</g>
<g id="object2">
<rect style="fill: #a81616" x="7.8" y="1.9" width="2.17581" height="2.24833"/>
</g>
</svg>
</pre>

Areas in the TEI file are also uniquely identified:
<pre>
<div1 type="chapter" xml:id="CHAP1">


</div1>
<div1 type="chapter" xml:id="CHAP2">


</div1>
</pre>

Then we can use a linkgroup to pull this all together:
<pre>
<linkGrp type="callout">
<link targets="#CHAP1 #PD1"/>
<link targets="#CHAP2 #PD2"/>
</linkGrp>
</pre>

=Draft Recommendations for TEI Digital Facsimiles=

http://users.ox.ac.uk/~lou/wip/digfax.html

This document, authored by Richard Gartner and Lou Burnard and last updated in 2001, outlines ways to use TEI to represent three types of digital objects:

*complete digital transcriptions of the content of manuscript or print originals (possibly including illustrations as well as text)
*collections of digitized page images (''digital facsimiles'') intended for use as surrogates for complete manuscript or print originals
*digital objects (''digital editions'') combining both page facsimiles and transcriptions, possibly also including layers of editorial annotation

The authors attempt to address these areas of concern:

*the need to distinguish images of a manuscript or print source from images located within it;
*the need to support multiple formats of a single image;
*the need to associate metadata at different levels (e.g. collection level, item level);
*the need to associate transcription and facsimile in a standard way;
*the need to define practices which can be used equally well in both SGML and XML environments;
*the desire to avoid special purpose rules which assume nonstandard or ad hoc processing rules.

==Case 1: Transcription==

Updated to cite chapters in P5:

The content of a transcription should be marked up as a single <TEI> element using the standard TEI elements <text>, <body>, <div>, etc. from the TEI core tag sets.

Follow the Guidelines chapters 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Resources] and 13 [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html Manuscript Description].

If the source contains "significant illustrative material", use <figure> (and children) from Guidelines chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics] to insert illustrations in their proper location in the transcript.

[[Image:Teidr-fig1.gif|left|thumb|Example of the TEI <figure> element.]]

<pre>
<lb n="12"/>feond mid his geferum eallum. Feollon þa ufon
<lb n="13"/>of heofnum þurhlonge swa þreo niht and da
<lb n="14"/>gas, þa englas of heofnum on helle, and heo ealle
<lb n="15"/>forsceop drihten to deoflum.

<figure>
<head>Fall of the Angels</head>
<figDesc>Above, God, cross-nimbed, beardless, and holding a closed book,
accompanied by three angels, turns and gestures toward three angels on
the left, one of whom (Lucifer?) holds a palm frond ...</figDesc>
</figure>

<pb n="17"/>
</pre>

==Case 2: Digital Facsimile==

Should be marked as a separate <TEI> element. TEI structural tags may be used, but need not be, especially if differences between textual structure and physical structure cause overlap.

Each distinct image making up the facsimile should be encoded as a <figure> element, arranged in the normal reading sequence of the facsimile. The appropriate milestone element (<pb/> or <cb/>) should be used at the appropriate place in the facsimile.

[[Image:Teidr-fig2.gif|left|thumb|Example of the TEI <figure> element with reference to manuscript folio number.]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
</figure>
</pre>

<figure> elements may be self-nested to show that one image logically contains others (in cases where two image fit together to form one larger image).

[[Image:Teidr-fig3.gif|left|thumb|Example of nesting TEI <figure> elements.]]

<pre>
<figure n="16">
<figDesc>
<figure>
<figDesc>[Page 16: 15 lines of text (detail of upper part)]</figDesc>
</figure>
<figure>
<figDesc>[Page 16: Image of "Fall of Angels" (Ohlgren 16.11) (detail of lower part)</figDesc>
</figure>
</figDesc>
</figure>
</pre>

==3: Techniques for Referencing Images==

Recommends declaring the file containing the image as an external entity and then referencing that entity using the "entity" attribute in <figure>. This approach depends on the use of the DTD (no longer practical given the TEI's move towards using the RelaxNG schema), and relies on an attribute that is no longer included in P5.

In TEI P5 there are also two new elements, <graphic> and <binaryObject> which may be used to represent image references or images respectively. These permit the encoding of figures containing multiple images, for example. The <graphic> element has a "url" attribute which enables the association of a <figure> with its corresponding image file. The recommendations in Gartner and Burnard need to be revised substantially in this respect.

[[Image:Teidr-fig4.gif|left|thumb|Example of the TEI <graphic> element with reference to image file URL]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17" url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
</figure>
</pre>

This approach is simple, though it is not practical if one has multiple images of the same page in various resolutions

<pre>
<figure>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
<graphic url="http://www.somewhere.eu/fig1.png" scale="0.5"/>
</figure>
</pre>

Other options mentioned in the recommendation: Xlink or Xinclude.

==4: Aligning transcription and fascimile==

The TEI Guidelines propose a number of methods for aligning parts of a document (see www.tei-c.org/Guidelines/SA). These may be briefly summarized as follows
*use the @corresp attribute to assert that a <pb> (or other reference point) in the transcription corresponds with a <pb> in the facsimile (or the reverse);
*alternatively, use a stand-off <link> element to assert the association between the two <pb> elements;
*for cross-document linking, an intermediate <xptr> may be used as the target.
(see [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html Chapter 14 Linking, Segmentation, and Alignment]).

[[Image:Teidr-fig5.gif|left|thumb|Example of linking image file with transcription using @corresp on <pb>.]]

=Method used by the Edition Production Technology (EPT): Link text and images=

The EPT (now EPPT: http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html) uses a system combining a Image Catalog combined with a special attribute for coordinates to enable linking between text and image. For more details, see here: http://beowulf.engl.uky.edu/~kiernan/eBoethius/tech.htm#tech.

==Image Catalog==

The Image Catalog is a simple XML file that consists of lists of image files organized by category. There is one category for every set of image files for a given source.
*daylight (images taken under regular lighting)
*ultraviolet (images taken under ultraviolet lighting)
*microfilm (images scanned from microfilm)

Categories are assigned unique IDs.

Within each category, the user associates each file with an ID that is ''unique within the category''. IDs will repeat across categories. Essentially, these IDs associate the files with the same object, which may be represented by multiple images.

[[Image:Ept-fig1.gif|left|thumb|Example of the EPT Image Catalog configuration file.]]

<pre>
<category name="daylight" id="d">
<file name="aih0244-JPG.jpg" id="5v" />
<file name="aih0245-JPG.jpg" id="6r" />
<file name="aih0242-JPG.jpg" id="6v" />
</category>
<category name="ultraviolet" id="u">
<file name="uv-5v.jpg" id="5v" />
<file name="uv-6r.jpg" id="6r" />
<file name="uv-6v.jpg" id="6v" />
</category>
<category name="microfilm" id="m">
<file name="mf-5v.jpg" id="5v" />
<file name="mf-6r.jpg" id="6r" />
<file name="mf-6v.jpg" id="6v" />
</category>
</pre>

The file IDs from image catalog are then associated with an attribute within the text markup itself. The attribute used is configured by the user; for the Electronic Boethius, we used the attribute ''n'' in the element ''<fol>'' (folio). The content for each folio is thus associated with the correct image files (from every category):

<pre>
<fol n="5v">
</pre>
points to
<pre>
<daylight><file id="5v"/>
</pre>
and
<pre>
<ultraviolet><file id=“5v”/>
</pre>
and
<pre>
<microfilm><file id=“5v”/>
</pre>

[[Image:Ept-fig2.gif|left|thumb|Example of EPT Image Catalog links image files with sections of text.]]

==Attribute for Coordinates==

A TEI element can be associated with a rectangular region of an image by encoding the co-ordinates of the region's corners as an attribute of that element. The EPT allows the user to assign an attribute (Electronic Boethius uses ''coords''). In whatever elements that attribute is defined, the coordinates, selected by the editor, are automatically entered by the software. The ID assigned to the categories in the Image Catalog are appended to the beginning of the coordinates.

[[Image:Ept-fig3.gif|left|thumb|Example of @coords on <figure>.]]
[[Image:Ept-fig4.gif|thumb|Screenshot of EPPT]]
<pre>
<damage coords="d:1058,738,1093,798">
</pre>

=Method used by the UVic Image Markup Tool: Annotate images=

The UVic Image Markup Tool (http://www.tapor.uvic.ca/~mholmes/image_markup/) uses TEI, modified to allow for the inclusion of SVG (http://www.w3.org/Graphics/SVG/), to create a system for annotating images.

Stated goals of the Tool:

*be simple for novices to use
*load and display a wide variety of different image formats
*allow the user to specify arbitrary rectangles on the image, and associate them with annotations
*allow such rectangles to overlap if the user wishes
*provide mechanisms for bringing overlapped rectangles to the front easily
*allow annotations to be grouped into categories, distinguished by name and appearance, to allow different classes of annotation
*require no significant knowledge of XML or TEI
*allow the use of XML code if the user wishes
*save data in an XML file which conforms to a TEI P5-based schema
*reload data from its own files
*generate a simple "Web view" of the data for display in a browser
*come packaged with an installer, Help file, and basic tutorial
*be simple for novices to use!

Simplified example from the IMT web:
<pre>
<TEI>
<teiHeader>

</teiHeader>
<text>
<body>

<div type="imtAnnotatedImage">
<svg xmlns="http://www.w3.org/2000/svg">

<image>

</image>
<rect>

</rect>
</svg>
<div type="imtAnnotationLayer">

</div>
</div>

</body>
</text>
</TEI>
</pre>

Using this system, a user can annotate many sections of a single image. Unlike the EPT system described above, in which the coordinates are stored directly in the element, here the image coordinates are stored in a separate section and linked to the annotations using unique IDs (''svg:id'' in ''<rect>'') to link the areas to the annotation content (''n'' in ''<div type="imtAnnotationLayer">'').

[[Image:Uvic-fig1.gif|left|thumb|Example of the coordinate system used by the UVic IMT.]]

<pre>
<div type="imtAnnotatedImage" xml:id="NB-B-17328">
<svg xmlns="http://www.w3.org/2000/svg">
<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="NB-B-17328.jpg" width="5060" height="6025"/>
<title>NB-B-17328.jpg</title>
<desc>5060 x 6025</desc>
<rect svg:id="NB-B-17328_0" x="4287" y="1412" width="580" height="426" style="3" color="#ff0000"/>
<rect svg:id="NB-B-17328_1" x="4067" y="2019" width="720" height="747" style="3" color="#ff0000"/>
</svg>
<div type="imtAnnotationLayer" n="NB-B-17328_0">
<head>la chandelle allume la découverte.</head>
<p>Il a trouvé la cache.</p>
</div>
<div type="imtAnnotationLayer" n="NB-B-17328_1">
<head>le couvercle de la malle</head>
<p>Il est pris sans vert</p>
</div>
</pre>

[[Image:Uvic-fig2.gif|left|thumb|Screenshot from the UVic IMT interface.]]
[[Image:Uvic-fig3.gif|thumb|Browser view of output from the UVic IMT.]]

(TEI examples from the UVic file example: http://www.tapor.uvic.ca/~mholmes/image_markup/Amant.xml)

For more details on the TEI/SVG used by the IMT, see here: http://www.tapor.uvic.ca/~mholmes/image_markup/xml.php

=Using METS to link text and image=

==What is METS?==
*Metadata Encoding and Transmission Standard (http://www.loc.gov/standards/mets/)
*“a standard for encoding … metadata regarding objects within a digital library”
*Centered at the Library of Congress
*Developed out of the metadata specs from the LOC’s “Making of America 2” project (MOA2)
*Developed by librarians and archivists, for librarians and archivists
*Accepted standard with a broad user base (http://sunsite.berkeley.edu/mets/registry/)
*Unrelated to TEI
<blockquote>
While a library may record descriptive metadata regarding a book in its collection, the book will not dissolve into a series of unconnected pages if the library fails to record structural metadata regarding the book's organization, nor will scholars be unable to evaluate the book's worth if the library fails to note that the book was produced using a Ryobi offset press.” (METS: An Overview and Tutorial)
</blockquote>

==Why METS?==
*System to organize disparate parts and relate files (and pieces of files):
**Areas on images correspond with sections of text
**Areas on images relate to one another
**Areas of text relate to one another
*METS provides sections for defining the logical and/or physical structure of the digital object
**File Section (fileSec)
**Structural Map (structMap)

==File Section==
“lists all files containing content which comprise the electronic versions of the digital object.”
*Similar to the EPT Image Catalog

==Within the FileSec==
*FileSec consists of Groups of File Locaters
**File Group: contains related files
<blockquote><fileGrp USE="facsimile"></blockquote>
**File: assigns the individual files unique identifiers
<blockquote><file ID="C-Clbiv-69v" MIMETYPE="image/tiff"></blockquote>
**File Locater: points to the location of the file, using xlink syntax
<blockquote><FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.jpg"/></blockquote>

===Example (Images)===
<pre>
<fileGrp USE="facsimile">
<file ID="C-Clbiv-69v" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.tif"/>
</file>
<file ID="C-Clbiv-70r" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-70r.tif"/>
</file>
…
</fileGrp>
</pre>

===Example (Transcript)===
<pre>
<fileGrp USE="transcript">
<file ID="id-pref-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/pref-genesis.xml"/>
</file>
<file ID="id-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/genesis.xml"/>
</file>
<file ID="id-exodus" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/exodus.xml"/>
</file>
…
</fileGrp>
</pre>

==Structural Map==
“outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files … that pertain to each element.”
*Organization may be logical or physical
*A single METS file may contain multiple structural maps

==Within the StructMap==
*StructMap consists of organizational divisions, that may nest
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
...
</div>
</div>
</pre>
*The divisions contain pointers to the files, and areas of files, indexed in the fileSec
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
<fptr FILEID="C-Clbiv-1v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="1v.32" END="1v.38"/>
</fptr>
</div>
</div>
</pre>

===Example (Basic)===
The first file pointer references the corresponding image file, while the second one references the corresponding line range (BEGIN and END) in the XML file (these are the values of, for example, @xml:id on <lb/>
<pre>
<div LABEL="Folio 69v" ORDER=“139">
<fptr FILEID="C-Clbiv-69v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.12"/>
</fptr>
</div>
<div LABEL="Folio 70r" ORDER="140">
<fptr FILEID="C-Clbiv-70r"/>
<fptr>
<area FILEID="id-genesis" BEGIN="70r.1" END="70r.38"/>
</fptr>
</div>
</pre>

===Example (Advanced)===
*<area>: reference coordinates within an image file.
**especially useful for extensively illustrated manuscripts
*create links between text and image.
**@COORDS in <area> for image files
**@BEGIN and @END in <area> for XML/TEI files
*Simplifies encoding:
**no need to define @COORDS to clutter up the TEI;
**no need to find a place to store a linking section in the TEI file
**no need to use the SVG namespace
**separate the objects (image and XML files) from the indexing of their relationships with one another

[[Image:mets-fig1.gif|left|thumb|Advanced Example of using METS and TEI to link sections of text with sections of image]]

<pre>
<div LABEL="Folio 69v" ORDER="139">
<div LABEL="Annotation 1"
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="40,12,975,121"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.annot.1"/>
</fptr>
</div>
<div LABEL="Illustration 1">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="96,87979,572"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.illus.1"/>
</fptr>
</div>
<div LABEL="Text">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="71,531,978,859"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.9"/>
</fptr>
</div>
</div>
</pre>

=Conclusions=
*Draft Recommendations for TEI Digital Facsimiles
**Not robust
**No specific image/text linking
**Need to be updated for TEI P5
*Edition Production Technology (EPT)
**Designed for textual annotation, but can annotate illustrations as well
**Markup schema is not defined
**Complex
**Dependent on editing software
**Limited image file support
**No visualization outside of the editing environment
*UVic Image Annotation Tool
**Simple
**Annotates via description – no “text encoding” (i.e., cannot include in an electronic transcription)
**Based on accepted standards
**Markup schema is defined (extended TEI + SVG)
**Visualization through SVG-enabled browser
*METS
**Very complex
**Objects separate from indexes
**Flexible – can link many textual and image sections (Venetus A – link main text and several layers of annotations)
**No visualization (yet) for the more advanced image-text links

LegacyFacsimileMarkup

2006-06-07T11:36:31Z

Conal: /* Attribute for Coordinates */

This page includes some examples of different approaches for facsimile (image-based) markup.

=P5 Guidelines, 22.3 (Specific Elements for Graphic Images)=

The P5 Guidelines describe four elements for including graphic images in TEI documents:

*figure: contains a block containing graphics, illustrations, or figures.
*graphic: indicates the location of an inline graphic, illustration, or figure.
*binaryObject: provides encoded binary data representing an inline graphic or other object.
*figdesc: contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

<figure> is the parent element for the others. <figure> may also contain <head> (a header or title) and <p> (commentary or caption, not a description of the image).

If a graphic contains a large amount of text, and the editor determines that the graphic actually contains that text (the text is not part of the surrounding text), <figure> may contain <text>.

==Linking Text & Image in P5==

The Guidelines describes a number of ways to link text and image using methods described fully in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment].

===Linking thumbnails to full-resolution images===
To link thumbnails to larger images, create a <ref> tag that points to the xml:id of the corresponding figure. Include the thumbnail as a graphic in the <ref>

<pre>
<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>
</pre>

===Associate images/parts of images with text elements===
Use the linking mechanism described in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment] to link together a figure (the example in the guidelines uses an external SVG file, parts of which are identified with xml:ids) and TEI elements (which are likewise identified using xml:ids).

First, we use pointers to the graphic image:
<pre>
<ptr xml:id="PD1" target="Fig1.svg#object1"/>
<ptr xml:id="PD2" target="Fig1.svg#object2"/>
</pre>

These point inside the SVG file:
<pre>
<svg width="8cm" height="3cm" viewBox="2 1 8 3">
<g id="object1">
<ellipse style="fill: #ffffff" cx="3.875" cy="3.025" rx="1.175" ry="1.175"/>
</g>
<g id="object2">
<rect style="fill: #a81616" x="7.8" y="1.9" width="2.17581" height="2.24833"/>
</g>
</svg>
</pre>

Areas in the TEI file are also uniquely identified:
<pre>
<div1 type="chapter" xml:id="CHAP1">


</div1>
<div1 type="chapter" xml:id="CHAP2">


</div1>
</pre>

Then we can use a linkgroup to pull this all together:
<pre>
<linkGrp type="callout">
<link targets="#CHAP1 #PD1"/>
<link targets="#CHAP2 #PD2"/>
</linkGrp>
</pre>

=Draft Recommendations for TEI Digital Facsimiles=

http://users.ox.ac.uk/~lou/wip/digfax.html

This document, authored by Richard Gartner and Lou Burnard and last updated in 2001, outlines ways to use TEI to represent three types of digital objects:

*complete digital transcriptions of the content of manuscript or print originals (possibly including illustrations as well as text)
*collections of digitized page images (''digital facsimiles'') intended for use as surrogates for complete manuscript or print originals
*digital objects (''digital editions'') combining both page facsimiles and transcriptions, possibly also including layers of editorial annotation

The authors attempt to address these areas of concern:

*the need to distinguish images of a manuscript or print source from images located within it;
*the need to support multiple formats of a single image;
*the need to associate metadata at different levels (e.g. collection level, item level);
*the need to associate transcription and facsimile in a standard way;
*the need to define practices which can be used equally well in both SGML and XML environments;
*the desire to avoid special purpose rules which assume nonstandard or ad hoc processing rules.

==Case 1: Transcription==

Updated to cite chapters in P5:

The content of a transcription should be marked up as a single <TEI> element using the standard TEI elements <text>, <body>, <div>, etc. from the TEI core tag sets.

Follow the Guidelines chapters 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Resources] and 13 [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html Manuscript Description].

If the source contains "significant illustrative material", use <figure> (and children) from Guidelines chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics] to insert illustrations in their proper location in the transcript.

[[Image:Teidr-fig1.gif|left|thumb|Example of the TEI <figure> element.]]

<pre>
<lb n="12"/>feond mid his geferum eallum. Feollon þa ufon
<lb n="13"/>of heofnum þurhlonge swa þreo niht and da
<lb n="14"/>gas, þa englas of heofnum on helle, and heo ealle
<lb n="15"/>forsceop drihten to deoflum.

<figure>
<head>Fall of the Angels</head>
<figDesc>Above, God, cross-nimbed, beardless, and holding a closed book,
accompanied by three angels, turns and gestures toward three angels on
the left, one of whom (Lucifer?) holds a palm frond ...</figDesc>
</figure>

<pb n="17"/>
</pre>

==Case 2: Digital Facsimile==

Should be marked as a separate <TEI> element. TEI structural tags may be used, but need not be, especially if differences between textual structure and physical structure cause overlap.

Each distinct image making up the facsimile should be encoded as a <figure> element, arranged in the normal reading sequence of the facsimile. The appropriate milestone element (<pb/> or <cb/>) should be used at the appropriate place in the facsimile.

[[Image:Teidr-fig2.gif|left|thumb|Example of the TEI <figure> element with reference to manuscript folio number.]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
</figure>
</pre>

<figure> elements may be self-nested to show that one image logically contains others (in cases where two image fit together to form one larger image).

[[Image:Teidr-fig3.gif|left|thumb|Example of nesting TEI <figure> elements.]]

<pre>
<figure n="16">
<figDesc>
<figure>
<figDesc>[Page 16: 15 lines of text (detail of upper part)]</figDesc>
</figure>
<figure>
<figDesc>[Page 16: Image of "Fall of Angels" (Ohlgren 16.11) (detail of lower part)</figDesc>
</figure>
</figDesc>
</figure>
</pre>

==3: Techniques for Referencing Images==

Recommends declaring the file containing the image as an external entity and then referencing that entity using the "entity" attribute in <figure>. This approach depends on the use of the DTD (no longer practical given the TEI's move towards using the RelaxNG schema), and relies on an attribute that is no longer included in P5.

In TEI P5 there are also two new elements, <graphic> and <binaryObject> which may be used to represent image references or images respectively. These permit the encoding of figures containing multiple images, for example. The <graphic> element has a "url" attribute which enables the association of a <figure> with its corresponding image file. The recommendations in Gartner and Burnard need to be revised substantially in this respect.

[[Image:Teidr-fig4.gif|left|thumb|Example of the TEI <graphic> element with reference to image file URL]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17" url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
</figure>
</pre>

This approach is simple, though it is not practical if one has multiple images of the same page in various resolutions

<pre>
<figure>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
<graphic url="http://www.somewhere.eu/fig1.png" scale="0.5"/>
</figure>
</pre>

Other options mentioned in the recommendation: Xlink or Xinclude.

==4: Aligning transcription and fascimile==

The TEI Guidelines propose a number of methods for aligning parts of a document (see www.tei-c.org/Guidelines/SA). These may be briefly summarized as follows
*use the @corresp attribute to assert that a <pb> (or other reference point) in the transcription corresponds with a <pb> in the facsimile (or the reverse);
*alternatively, use a stand-off <link> element to assert the association between the two <pb> elements;
*for cross-document linking, an intermediate <xptr> may be used as the target.
(see [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html Chapter 14 Linking, Segmentation, and Alignment]).

[[Image:Teidr-fig5.gif|left|thumb|Example of linking image file with transcription using @corresp on <pb>.]]

=Method used by the Edition Production Technology (EPT): Link text and images=

The EPT (now EPPT: http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html) uses a system combining a Image Catalog combined with a special attribute for coordinates to enable linking between text and image. For more details, see here: http://beowulf.engl.uky.edu/~kiernan/eBoethius/tech.htm#tech.

==Image Catalog==

The Image Catalog is a simple XML file that consists of lists of image files organized by category. There is one category for every set of image files for a given source.
*daylight (images taken under regular lighting)
*ultraviolet (images taken under ultraviolet lighting)
*microfilm (images scanned from microfilm)

Categories are assigned unique IDs.

Within each category, the user associates each file with an ID that is ''unique within the category''. IDs will repeat across categories. Essentially, these IDs associate the files with the same object, which may be represented by multiple images.

[[Image:Ept-fig1.gif|left|thumb|Example of the EPT Image Catalog configuration file.]]

<pre>
<category name="daylight" id="d">
<file name="aih0244-JPG.jpg" id="5v" />
<file name="aih0245-JPG.jpg" id="6r" />
<file name="aih0242-JPG.jpg" id="6v" />
</category>
<category name="ultraviolet" id="u">
<file name="uv-5v.jpg" id="5v" />
<file name="uv-6r.jpg" id="6r" />
<file name="uv-6v.jpg" id="6v" />
</category>
<category name="microfilm" id="m">
<file name="mf-5v.jpg" id="5v" />
<file name="mf-6r.jpg" id="6r" />
<file name="mf-6v.jpg" id="6v" />
</category>
</pre>

The file IDs from image catalog are then associated with an attribute within the text markup itself. The attribute used is configured by the user; for the Electronic Boethius, we used the attribute ''n'' in the element ''<fol>'' (folio). The content for each folio is thus associated with the correct image files (from every category):

<pre>
<fol n="5v">
</pre>
points to
<pre>
<daylight><file id="5v"/>
</pre>
and
<pre>
<ultraviolet><file id=“5v”/>
</pre>
and
<pre>
<microfilm><file id=“5v”/>
</pre>

[[Image:Ept-fig2.gif|left|thumb|Example of EPT Image Catalog links image files with sections of text.]]

==Attribute for Coordinates==

A TEI element can be associated with a rectangular region of an image by encoding the co-ordinates of the region's corners as an attribute of that element. The EPT allows the user to assign an attribute (Electronic Boethius uses ''coords''). In whatever elements that attribute is defined, the coordinates, selected by the editor, are automatically entered by the software. The ID assigned to the categories in the Image Catalog are appended to the beginning of the coordinates.

[[Image:Ept-fig3.gif|left|thumb|Example of @coords on <figure>.]]
[[Image:Ept-fig4.gif|thumb|Screenshot of EPPT]]
<pre>
<damage coords="d:1058,738,1093,798">
</pre>

=Method used by the UVic Image Markup Tool: Annotate images=

The UVic Image Markup Tool (http://www.tapor.uvic.ca/~mholmes/image_markup/) uses TEI, modified to allow for the inclusion of SVG (http://www.w3.org/Graphics/SVG/), to create a system for annotating images.

Stated goals of the Tool:

*be simple for novices to use
*load and display a wide variety of different image formats
*allow the user to specify arbitrary rectangles on the image, and associate them with annotations
*allow such rectangles to overlap if the user wishes
*provide mechanisms for bringing overlapped rectangles to the front easily
*allow annotations to be grouped into categories, distinguished by name and appearance, to allow different classes of annotation
*require no significant knowledge of XML or TEI
*allow the use of XML code if the user wishes
*save data in an XML file which conforms to a TEI P5-based schema
*reload data from its own files
*generate a simple "Web view" of the data for display in a browser
*come packaged with an installer, Help file, and basic tutorial
*be simple for novices to use!

Simplified example from the IMT web:
<pre>
<TEI>
<teiHeader>

</teiHeader>
<text>
<body>

<div type="imtAnnotatedImage">
<svg>

<image>

</image>
<rect>

</rect>
</svg>
<div type="imtAnnotationLayer">

</div>
</div>

</body>
</text>
</TEI>
</pre>

Using this system, a user can annotate many sections of a single image. Unlike the EPT system described above, in which the coordinates are stored directly in the element, here the image coordinates are stored in a separate section and linked to the annotations using unique IDs (''svg:id'' in ''<rect>'') to link the areas to the annotation content (''n'' in ''<div type="imtAnnotationLayer">'').

[[Image:Uvic-fig1.gif|left|thumb|Example of the coordinate system used by the UVic IMT.]]

<pre>
<div type="imtAnnotatedImage" xml:id="NB-B-17328">
<svg xmlns="http://www.w3.org/2000/svg">
<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="NB-B-17328.jpg" width="5060" height="6025"/>
<title>NB-B-17328.jpg</title>
<desc>5060 x 6025</desc>
<rect svg:id="NB-B-17328_0" x="4287" y="1412" width="580" height="426" style="3" color="#ff0000"/>
<rect svg:id="NB-B-17328_1" x="4067" y="2019" width="720" height="747" style="3" color="#ff0000"/>
</svg>
<div type="imtAnnotationLayer" n="NB-B-17328_0">
<head>la chandelle allume la découverte.</head>
<p>Il a trouvé la cache.</p>
</div>
<div type="imtAnnotationLayer" n="NB-B-17328_1">
<head>le couvercle de la malle</head>
<p>Il est pris sans vert</p>
</div>
</pre>

[[Image:Uvic-fig2.gif|left|thumb|Screenshot from the UVic IMT interface.]]
[[Image:Uvic-fig3.gif|thumb|Browser view of output from the UVic IMT.]]

(TEI examples from the UVic file example: http://www.tapor.uvic.ca/~mholmes/image_markup/Amant.xml)

For more details on the TEI/SVG used by the IMT, see here: http://www.tapor.uvic.ca/~mholmes/image_markup/xml.php

=Using METS to link text and image=

==What is METS?==
*Metadata Encoding and Transmission Standard (http://www.loc.gov/standards/mets/)
*“a standard for encoding … metadata regarding objects within a digital library”
*Centered at the Library of Congress
*Developed out of the metadata specs from the LOC’s “Making of America 2” project (MOA2)
*Developed by librarians and archivists, for librarians and archivists
*Accepted standard with a broad user base (http://sunsite.berkeley.edu/mets/registry/)
*Unrelated to TEI
<blockquote>
While a library may record descriptive metadata regarding a book in its collection, the book will not dissolve into a series of unconnected pages if the library fails to record structural metadata regarding the book's organization, nor will scholars be unable to evaluate the book's worth if the library fails to note that the book was produced using a Ryobi offset press.” (METS: An Overview and Tutorial)
</blockquote>

==Why METS?==
*System to organize disparate parts and relate files (and pieces of files):
**Areas on images correspond with sections of text
**Areas on images relate to one another
**Areas of text relate to one another
*METS provides sections for defining the logical and/or physical structure of the digital object
**File Section (fileSec)
**Structural Map (structMap)

==File Section==
“lists all files containing content which comprise the electronic versions of the digital object.”
*Similar to the EPT Image Catalog

==Within the FileSec==
*FileSec consists of Groups of File Locaters
**File Group: contains related files
<blockquote><fileGrp USE="facsimile"></blockquote>
**File: assigns the individual files unique identifiers
<blockquote><file ID="C-Clbiv-69v" MIMETYPE="image/tiff"></blockquote>
**File Locater: points to the location of the file, using xlink syntax
<blockquote><FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.jpg"/></blockquote>

===Example (Images)===
<pre>
<fileGrp USE="facsimile">
<file ID="C-Clbiv-69v" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.tif"/>
</file>
<file ID="C-Clbiv-70r" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-70r.tif"/>
</file>
…
</fileGrp>
</pre>

===Example (Transcript)===
<pre>
<fileGrp USE="transcript">
<file ID="id-pref-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/pref-genesis.xml"/>
</file>
<file ID="id-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/genesis.xml"/>
</file>
<file ID="id-exodus" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/exodus.xml"/>
</file>
…
</fileGrp>
</pre>

==Structural Map==
“outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files … that pertain to each element.”
*Organization may be logical or physical
*A single METS file may contain multiple structural maps

==Within the StructMap==
*StructMap consists of organizational divisions, that may nest
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
...
</div>
</div>
</pre>
*The divisions contain pointers to the files, and areas of files, indexed in the fileSec
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
<fptr FILEID="C-Clbiv-1v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="1v.32" END="1v.38"/>
</fptr>
</div>
</div>
</pre>

===Example (Basic)===
The first file pointer references the corresponding image file, while the second one references the corresponding line range (BEGIN and END) in the XML file (these are the values of, for example, @xml:id on <lb/>
<pre>
<div LABEL="Folio 69v" ORDER=“139">
<fptr FILEID="C-Clbiv-69v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.12"/>
</fptr>
</div>
<div LABEL="Folio 70r" ORDER="140">
<fptr FILEID="C-Clbiv-70r"/>
<fptr>
<area FILEID="id-genesis" BEGIN="70r.1" END="70r.38"/>
</fptr>
</div>
</pre>

===Example (Advanced)===
*<area>: reference coordinates within an image file.
**especially useful for extensively illustrated manuscripts
*create links between text and image.
**@COORDS in <area> for image files
**@BEGIN and @END in <area> for XML/TEI files
*Simplifies encoding:
**no need to define @COORDS to clutter up the TEI;
**no need to find a place to store a linking section in the TEI file
**no need to use the SVG namespace
**separate the objects (image and XML files) from the indexing of their relationships with one another

[[Image:mets-fig1.gif|left|thumb|Advanced Example of using METS and TEI to link sections of text with sections of image]]

<pre>
<div LABEL="Folio 69v" ORDER="139">
<div LABEL="Annotation 1"
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="40,12,975,121"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.annot.1"/>
</fptr>
</div>
<div LABEL="Illustration 1">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="96,87979,572"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.illus.1"/>
</fptr>
</div>
<div LABEL="Text">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="71,531,978,859"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.9"/>
</fptr>
</div>
</div>
</pre>

=Conclusions=
*Draft Recommendations for TEI Digital Facsimiles
**Not robust
**No specific image/text linking
**Need to be updated for TEI P5
*Edition Production Technology (EPT)
**Designed for textual annotation, but can annotate illustrations as well
**Markup schema is not defined
**Complex
**Dependent on editing software
**Limited image file support
**No visualization outside of the editing environment
*UVic Image Annotation Tool
**Simple
**Annotates via description – no “text encoding” (i.e., cannot include in an electronic transcription)
**Based on accepted standards
**Markup schema is defined (extended TEI + SVG)
**Visualization through SVG-enabled browser
*METS
**Very complex
**Objects separate from indexes
**Flexible – can link many textual and image sections (Venetus A – link main text and several layers of annotations)
**No visualization (yet) for the more advanced image-text links

LegacyFacsimileMarkup

2006-06-07T11:02:54Z

Conal: /* Conclusions */

This page includes some examples of different approaches for facsimile (image-based) markup.

=P5 Guidelines, 22.3 (Specific Elements for Graphic Images)=

The P5 Guidelines describe four elements for including graphic images in TEI documents:

*figure: contains a block containing graphics, illustrations, or figures.
*graphic: indicates the location of an inline graphic, illustration, or figure.
*binaryObject: provides encoded binary data representing an inline graphic or other object.
*figdesc: contains a brief prose description of the appearance or content of a graphic figure, for use when documenting an image without displaying it.

<figure> is the parent element for the others. <figure> may also contain <head> (a header or title) and <p> (commentary or caption, not a description of the image).

If a graphic contains a large amount of text, and the editor determines that the graphic actually contains that text (the text is not part of the surrounding text), <figure> may contain <text>.

==Linking Text & Image in P5==

The Guidelines describes a number of ways to link text and image using methods described fully in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment].

===Linking thumbnails to full-resolution images===
To link thumbnails to larger images, create a <ref> tag that points to the xml:id of the corresponding figure. Include the thumbnail as a graphic in the <ref>

<pre>
<ref target="#IM1">Click here
<graphic url="fig1th.png"/>
for enlightenment
</ref>
<figure xml:id="IM1">
<graphic url="fig1.jpg"/>
</figure>
</pre>

===Associate images/parts of images with text elements===
Use the linking mechanism described in [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html 14 Linking, Segmentation, and Alignment] to link together a figure (the example in the guidelines uses an external SVG file, parts of which are identified with xml:ids) and TEI elements (which are likewise identified using xml:ids).

First, we use pointers to the graphic image:
<pre>
<ptr xml:id="PD1" target="Fig1.svg#object1"/>
<ptr xml:id="PD2" target="Fig1.svg#object2"/>
</pre>

These point inside the SVG file:
<pre>
<svg width="8cm" height="3cm" viewBox="2 1 8 3">
<g id="object1">
<ellipse style="fill: #ffffff" cx="3.875" cy="3.025" rx="1.175" ry="1.175"/>
</g>
<g id="object2">
<rect style="fill: #a81616" x="7.8" y="1.9" width="2.17581" height="2.24833"/>
</g>
</svg>
</pre>

Areas in the TEI file are also uniquely identified:
<pre>
<div1 type="chapter" xml:id="CHAP1">


</div1>
<div1 type="chapter" xml:id="CHAP2">


</div1>
</pre>

Then we can use a linkgroup to pull this all together:
<pre>
<linkGrp type="callout">
<link targets="#CHAP1 #PD1"/>
<link targets="#CHAP2 #PD2"/>
</linkGrp>
</pre>

=Draft Recommendations for TEI Digital Facsimiles=

http://users.ox.ac.uk/~lou/wip/digfax.html

This document, authored by Richard Gartner and Lou Burnard and last updated in 2001, outlines ways to use TEI to represent three types of digital objects:

*complete digital transcriptions of the content of manuscript or print originals (possibly including illustrations as well as text)
*collections of digitized page images (''digital facsimiles'') intended for use as surrogates for complete manuscript or print originals
*digital objects (''digital editions'') combining both page facsimiles and transcriptions, possibly also including layers of editorial annotation

The authors attempt to address these areas of concern:

*the need to distinguish images of a manuscript or print source from images located within it;
*the need to support multiple formats of a single image;
*the need to associate metadata at different levels (e.g. collection level, item level);
*the need to associate transcription and facsimile in a standard way;
*the need to define practices which can be used equally well in both SGML and XML environments;
*the desire to avoid special purpose rules which assume nonstandard or ad hoc processing rules.

==Case 1: Transcription==

Updated to cite chapters in P5:

The content of a transcription should be marked up as a single <TEI> element using the standard TEI elements <text>, <body>, <div>, etc. from the TEI core tag sets.

Follow the Guidelines chapters 18 [http://www.tei-c.org/release/doc/tei-p5-doc/html/PH.html Transcription of Primary Resources] and 13 [http://www.tei-c.org/release/doc/tei-p5-doc/html/MS.html Manuscript Description].

If the source contains "significant illustrative material", use <figure> (and children) from Guidelines chapter 22 [http://www.tei-c.org/release/doc/tei-p5-doc/html/FT.html Tables, Formulae, and Graphics] to insert illustrations in their proper location in the transcript.

[[Image:Teidr-fig1.gif|left|thumb|Example of the TEI <figure> element.]]

<pre>
<lb n="12"/>feond mid his geferum eallum. Feollon þa ufon
<lb n="13"/>of heofnum þurhlonge swa þreo niht and da
<lb n="14"/>gas, þa englas of heofnum on helle, and heo ealle
<lb n="15"/>forsceop drihten to deoflum.

<figure>
<head>Fall of the Angels</head>
<figDesc>Above, God, cross-nimbed, beardless, and holding a closed book,
accompanied by three angels, turns and gestures toward three angels on
the left, one of whom (Lucifer?) holds a palm frond ...</figDesc>
</figure>

<pb n="17"/>
</pre>

==Case 2: Digital Facsimile==

Should be marked as a separate <TEI> element. TEI structural tags may be used, but need not be, especially if differences between textual structure and physical structure cause overlap.

Each distinct image making up the facsimile should be encoded as a <figure> element, arranged in the normal reading sequence of the facsimile. The appropriate milestone element (<pb/> or <cb/>) should be used at the appropriate place in the facsimile.

[[Image:Teidr-fig2.gif|left|thumb|Example of the TEI <figure> element with reference to manuscript folio number.]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
</figure>
<pb n="17"/>
<figure n="17">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
</figure>
</pre>

<figure> elements may be self-nested to show that one image logically contains others (in cases where two image fit together to form one larger image).

[[Image:Teidr-fig3.gif|left|thumb|Example of nesting TEI <figure> elements.]]

<pre>
<figure n="16">
<figDesc>
<figure>
<figDesc>[Page 16: 15 lines of text (detail of upper part)]</figDesc>
</figure>
<figure>
<figDesc>[Page 16: Image of "Fall of Angels" (Ohlgren 16.11) (detail of lower part)</figDesc>
</figure>
</figDesc>
</figure>
</pre>

==3: Techniques for Referencing Images==

Recommends declaring the file containing the image as an external entity and then referencing that entity using the "entity" attribute in <figure>. This approach depends on the use of the DTD (no longer practical given the TEI's move towards using the RelaxNG schema), and relies on an attribute that is no longer included in P5.

In TEI P5 there are also two new elements, <graphic> and <binaryObject> which may be used to represent image references or images respectively. These permit the encoding of figures containing multiple images, for example. The <graphic> element has a "url" attribute which enables the association of a <figure> with its corresponding image file. The recommendations in Gartner and Burnard need to be revised substantially in this respect.

[[Image:Teidr-fig4.gif|left|thumb|Example of the TEI <graphic> element with reference to image file URL]]

<pre>
<pb n="16"/>
<figure n="16">
<figDesc>[Page 16: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.11)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/16.jpg"/>
</figure>
<pb n="17"/>
<figure n="17" url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg">
<figDesc>[Page 17: 15 lines of text followed by image of "Fall of Angels"
(Ohlgren 16.12)]</figDesc>
<graphic url="http://image.ox.ac.uk/images/bodleian/msjunius11/17.jpg"/>
</figure>
</pre>

This approach is simple, though it is not practical if one has multiple images of the same page in various resolutions

<pre>
<figure>
<head>Figure One: The View from the Bridge</head>
<figDesc>A Whistleresque view showing four
or five sailing boats in the foreground, and a
series of buoys strung out between them.</figDesc>
<graphic url="http://www.somewhere.eu/fig1.png" scale="0.5"/>
</figure>
</pre>

Other options mentioned in the recommendation: Xlink or Xinclude.

==4: Aligning transcription and fascimile==

The TEI Guidelines propose a number of methods for aligning parts of a document (see www.tei-c.org/Guidelines/SA). These may be briefly summarized as follows
*use the @corresp attribute to assert that a <pb> (or other reference point) in the transcription corresponds with a <pb> in the facsimile (or the reverse);
*alternatively, use a stand-off <link> element to assert the association between the two <pb> elements;
*for cross-document linking, an intermediate <xptr> may be used as the target.
(see [http://www.tei-c.org/release/doc/tei-p5-doc/html/SA.html Chapter 14 Linking, Segmentation, and Alignment]).

[[Image:Teidr-fig5.gif|left|thumb|Example of linking image file with transcription using @corresp on <pb>.]]

=Method used by the Edition Production Technology (EPT): Link text and images=

The EPT (now EPPT: http://beowulf.engl.uky.edu/~eft/EPPT-Demo.html) uses a system combining a Image Catalog combined with a special attribute for coordinates to enable linking between text and image. For more details, see here: http://beowulf.engl.uky.edu/~kiernan/eBoethius/tech.htm#tech.

==Image Catalog==

The Image Catalog is a simple XML file that consists of lists of image files organized by category. There is one category for every set of image files for a given source.
*daylight (images taken under regular lighting)
*ultraviolet (images taken under ultraviolet lighting)
*microfilm (images scanned from microfilm)

Categories are assigned unique IDs.

Within each category, the user associates each file with an ID that is ''unique within the category''. IDs will repeat across categories. Essentially, these IDs associate the files with the same object, which may be represented by multiple images.

[[Image:Ept-fig1.gif|left|thumb|Example of the EPT Image Catalog configuration file.]]

<pre>
<category name="daylight" id="d">
<file name="aih0244-JPG.jpg" id="5v" />
<file name="aih0245-JPG.jpg" id="6r" />
<file name="aih0242-JPG.jpg" id="6v" />
</category>
<category name="ultraviolet" id="u">
<file name="uv-5v.jpg" id="5v" />
<file name="uv-6r.jpg" id="6r" />
<file name="uv-6v.jpg" id="6v" />
</category>
<category name="microfilm" id="m">
<file name="mf-5v.jpg" id="5v" />
<file name="mf-6r.jpg" id="6r" />
<file name="mf-6v.jpg" id="6v" />
</category>
</pre>

The file IDs from image catalog are then associated with an attribute within the text markup itself. The attribute used is configured by the user; for the Electronic Boethius, we used the attribute ''n'' in the element ''<fol>'' (folio). The content for each folio is thus associated with the correct image files (from every category):

<pre>
<fol n="5v">
</pre>
points to
<pre>
<daylight><file id="5v"/>
</pre>
and
<pre>
<ultraviolet><file id=“5v”/>
</pre>
and
<pre>
<microfilm><file id=“5v”/>
</pre>

[[Image:Ept-fig2.gif|left|thumb|Example of EPT Image Catalog links image files with sections of text.]]

==Attribute for Coordinates==

To store coordinates from an image that correspond with a given piece of XML content, the EPT simply allows the user to assign an attribute (Electronic Boethius uses ''coords''). In whatever elements that attribute is defined, the coordinates, selected by the editor, are automatically entered by the software. The ID assigned to the categories in the Image Catalog are appended to the beginning of the coordinates.

[[Image:Ept-fig3.gif|left|thumb|Example of @coords on <figure>.]]
[[Image:Ept-fig4.gif|thumb|Screenshot of EPPT]]
<pre>
<damage coords="d:1058,738,1093,798">
</pre>

=Method used by the UVic Image Markup Tool: Annotate images=

The UVic Image Markup Tool (http://www.tapor.uvic.ca/~mholmes/image_markup/) uses TEI, modified to allow for the inclusion of SVG (http://www.w3.org/Graphics/SVG/), to create a system for annotating images.

Stated goals of the Tool:

*be simple for novices to use
*load and display a wide variety of different image formats
*allow the user to specify arbitrary rectangles on the image, and associate them with annotations
*allow such rectangles to overlap if the user wishes
*provide mechanisms for bringing overlapped rectangles to the front easily
*allow annotations to be grouped into categories, distinguished by name and appearance, to allow different classes of annotation
*require no significant knowledge of XML or TEI
*allow the use of XML code if the user wishes
*save data in an XML file which conforms to a TEI P5-based schema
*reload data from its own files
*generate a simple "Web view" of the data for display in a browser
*come packaged with an installer, Help file, and basic tutorial
*be simple for novices to use!

Simplified example from the IMT web:
<pre>
<TEI>
<teiHeader>

</teiHeader>
<text>
<body>

<div type="imtAnnotatedImage">
<svg>

<image>

</image>
<rect>

</rect>
</svg>
<div type="imtAnnotationLayer">

</div>
</div>

</body>
</text>
</TEI>
</pre>

Using this system, a user can annotate many sections of a single image. Unlike the EPT system described above, in which the coordinates are stored directly in the element, here the image coordinates are stored in a separate section and linked to the annotations using unique IDs (''svg:id'' in ''<rect>'') to link the areas to the annotation content (''n'' in ''<div type="imtAnnotationLayer">'').

[[Image:Uvic-fig1.gif|left|thumb|Example of the coordinate system used by the UVic IMT.]]

<pre>
<div type="imtAnnotatedImage" xml:id="NB-B-17328">
<svg xmlns="http://www.w3.org/2000/svg">
<image xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="NB-B-17328.jpg" width="5060" height="6025"/>
<title>NB-B-17328.jpg</title>
<desc>5060 x 6025</desc>
<rect svg:id="NB-B-17328_0" x="4287" y="1412" width="580" height="426" style="3" color="#ff0000"/>
<rect svg:id="NB-B-17328_1" x="4067" y="2019" width="720" height="747" style="3" color="#ff0000"/>
</svg>
<div type="imtAnnotationLayer" n="NB-B-17328_0">
<head>la chandelle allume la découverte.</head>
<p>Il a trouvé la cache.</p>
</div>
<div type="imtAnnotationLayer" n="NB-B-17328_1">
<head>le couvercle de la malle</head>
<p>Il est pris sans vert</p>
</div>
</pre>

[[Image:Uvic-fig2.gif|left|thumb|Screenshot from the UVic IMT interface.]]
[[Image:Uvic-fig3.gif|thumb|Browser view of output from the UVic IMT.]]

(TEI examples from the UVic file example: http://www.tapor.uvic.ca/~mholmes/image_markup/Amant.xml)

For more details on the TEI/SVG used by the IMT, see here: http://www.tapor.uvic.ca/~mholmes/image_markup/xml.php

=Using METS to link text and image=

==What is METS?==
*Metadata Encoding and Transmission Standard (http://www.loc.gov/standards/mets/)
*“a standard for encoding … metadata regarding objects within a digital library”
*Centered at the Library of Congress
*Developed out of the metadata specs from the LOC’s “Making of America 2” project (MOA2)
*Developed by librarians and archivists, for librarians and archivists
*Accepted standard with a broad user base (http://sunsite.berkeley.edu/mets/registry/)
*Unrelated to TEI
<blockquote>
While a library may record descriptive metadata regarding a book in its collection, the book will not dissolve into a series of unconnected pages if the library fails to record structural metadata regarding the book's organization, nor will scholars be unable to evaluate the book's worth if the library fails to note that the book was produced using a Ryobi offset press.” (METS: An Overview and Tutorial)
</blockquote>

==Why METS?==
*System to organize disparate parts and relate files (and pieces of files):
**Areas on images correspond with sections of text
**Areas on images relate to one another
**Areas of text relate to one another
*METS provides sections for defining the logical and/or physical structure of the digital object
**File Section (fileSec)
**Structural Map (structMap)

==File Section==
“lists all files containing content which comprise the electronic versions of the digital object.”
*Similar to the EPT Image Catalog

==Within the FileSec==
*FileSec consists of Groups of File Locaters
**File Group: contains related files
<blockquote><fileGrp USE="facsimile"></blockquote>
**File: assigns the individual files unique identifiers
<blockquote><file ID="C-Clbiv-69v" MIMETYPE="image/tiff"></blockquote>
**File Locater: points to the location of the file, using xlink syntax
<blockquote><FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.jpg"/></blockquote>

===Example (Images)===
<pre>
<fileGrp USE="facsimile">
<file ID="C-Clbiv-69v" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-69v.tif"/>
</file>
<file ID="C-Clbiv-70r" MIMETYPE="image/tiff">
<FLocat LOCTYPE="URN" xlink:href="images/C-Clbiv-70r.tif"/>
</file>
…
</fileGrp>
</pre>

===Example (Transcript)===
<pre>
<fileGrp USE="transcript">
<file ID="id-pref-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/pref-genesis.xml"/>
</file>
<file ID="id-genesis" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/genesis.xml"/>
</file>
<file ID="id-exodus" MIMETYPE="text/xml">
<FLocat LOCTYPE="URN" xlink:href=“transcription/exodus.xml"/>
</file>
…
</fileGrp>
</pre>

==Structural Map==
“outlines a hierarchical structure for the digital library object, and links the elements of that structure to content files … that pertain to each element.”
*Organization may be logical or physical
*A single METS file may contain multiple structural maps

==Within the StructMap==
*StructMap consists of organizational divisions, that may nest
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
...
</div>
</div>
</pre>
*The divisions contain pointers to the files, and areas of files, indexed in the fileSec
<pre>
<div LABEL="Genesis" ORDER="2">
<div LABEL="Folio 1v" ORDER="2">
<fptr FILEID="C-Clbiv-1v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="1v.32" END="1v.38"/>
</fptr>
</div>
</div>
</pre>

===Example (Basic)===
The first file pointer references the corresponding image file, while the second one references the corresponding line range (BEGIN and END) in the XML file (these are the values of, for example, @xml:id on <lb/>
<pre>
<div LABEL="Folio 69v" ORDER=“139">
<fptr FILEID="C-Clbiv-69v"/>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.12"/>
</fptr>
</div>
<div LABEL="Folio 70r" ORDER="140">
<fptr FILEID="C-Clbiv-70r"/>
<fptr>
<area FILEID="id-genesis" BEGIN="70r.1" END="70r.38"/>
</fptr>
</div>
</pre>

===Example (Advanced)===
*<area>: reference coordinates within an image file.
**especially useful for extensively illustrated manuscripts
*create links between text and image.
**@COORDS in <area> for image files
**@BEGIN and @END in <area> for XML/TEI files
*Simplifies encoding:
**no need to define @COORDS to clutter up the TEI;
**no need to find a place to store a linking section in the TEI file
**no need to use the SVG namespace
**separate the objects (image and XML files) from the indexing of their relationships with one another

[[Image:mets-fig1.gif|left|thumb|Advanced Example of using METS and TEI to link sections of text with sections of image]]

<pre>
<div LABEL="Folio 69v" ORDER="139">
<div LABEL="Annotation 1"
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="40,12,975,121"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.annot.1"/>
</fptr>
</div>
<div LABEL="Illustration 1">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="96,87979,572"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.illus.1"/>
</fptr>
</div>
<div LABEL="Text">
<fptr>
<area FILEID="C-Clbiv-69v" COORDS="71,531,978,859"/>
</fptr>
<fptr>
<area FILEID="id-genesis" BEGIN="69v.1" END="69v.9"/>
</fptr>
</div>
</div>
</pre>

=Conclusions=
*Draft Recommendations for TEI Digital Facsimiles
**Not robust
**No specific image/text linking
**Need to be updated for TEI P5
*Edition Production Technology (EPT)
**Designed for textual annotation, but can annotate illustrations as well
**Markup schema is not defined
**Complex
**Dependent on editing software
**Limited image file support
**No visualization outside of the editing environment
*UVic Image Annotation Tool
**Simple
**Annotates via description – no “text encoding” (i.e., cannot include in an electronic transcription)
**Based on accepted standards
**Markup schema is defined (extended TEI + SVG)
**Visualization through SVG-enabled browser
*METS
**Very complex
**Objects separate from indexes
**Flexible – can link many textual and image sections (Venetus A – link main text and several layers of annotations)
**No visualization (yet) for the more advanced image-text links

FacsimileMarkup

2006-02-24T10:44:45Z

Conal: SIG:Facsimile moved to FacsimileMarkup

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

Conal is going to produce some quick samples.

== Tasks ==

# collate [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# develop straw man facsimile modules:
## a [[StrawManFacsimileMarkup|high-end markup]]:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD equiv system to map low-end to the high-end markup?

[[Category:SIG]]

SIG:Facsimile

2006-02-24T10:44:45Z

Conal: SIG:Facsimile moved to FacsimileMarkup: Did not form a SIG

#redirect [[FacsimileMarkup]]

FacsimileMarkup

2006-02-24T10:37:02Z

Conal:

StrawManFacsimileMarkup

2006-02-24T10:14:55Z

Conal:

<pre>
<teiHeader>

<taxonomy id="facsimile-types">






<bibl>
<ref target="{pointer to a standard taxonomy of basic facsimile roles/relationships}"/>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
<category xml:id="very-small-thumbnail">
<catDesc>Extra small thumbnail</catDesc>
</category>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</bibl>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-02-24T10:01:22Z

Conal:

<pre>
<teiHeader>

<taxonomy>
<bibl>
<ref target="{pointer to a standard taxonomy of facsimile roles/relationships?}"/>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</bibl>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-02-24T09:59:25Z

Conal: quoted markup

<pre>
<teiHeader>

<taxonomy>
<bibl>
<ref target="{pointer to a standard taxonomy of facsimile roles/relationships?}"/>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</bibl>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>
</pre>

StrawManFacsimileMarkup

2006-02-24T09:57:40Z

Conal: scribbed down some straw man markup

<teiHeader>

<taxonomy>
<bibl>
<ref target="{pointer to a standard taxonomy of facsimile roles/relationships?}"/>
<category xml:id="text">
<catDesc>Textual form</catDesc>
</category>
<category xml:id="thumbnail">
<catDesc>Thumbnail image</catDesc>
</category>
<category xml:id="access">
<catDesc>Large image</catDesc>
</category>
<category xml:id="annotation">
<catDesc>Large annotated image</catDesc>
</category>
</bibl>
</taxonomy>

...
<facsimileStmt>
<facsimileList>
<graphic xml:id="thumb-p1" url="thumb-p1.jpg" mimeType="image/jpeg"/>
<graphic xml:id="access-p1" url="access-p1.jpg" mimeType="image/jpeg"/>
...
<svg:svg xml:id="detail-unclear-22" xmlns:svg="http://www.w3.org/2000/svg">

<svg:image id="svg1-access-p1-detail" x="0" y="0" width="100" height="100"
xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="access-p1.jpg"/>
</svg:svg>
...
</facsimileList>
<facsimileLinks>
<facsimileLink>
<ref type="text" target="#pb1"/>
<ref type="thumbnail" target="#thumb-p1"/>
<ref type="access" target="#access-p1"/>
<ref type="annotation" target="#annotation-p1"/>
</facsimileLink>
<facsimileLink>
<ref type="text" target="#unclear-22"/>
<ref type="access" target="#detail-unclear-22"/>
</facsimileLink>
...
</facsimileLinks>

</facsimileStmt>
...
</teiHeader>

FacsimileMarkup

2006-02-24T09:04:38Z

Conal:

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

Conal is going to produce some quick samples.

== Tasks ==

# collate [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# develop straw man facsimile modules:
## a [[StrawManFacsimileMarkup|high-end markup]]:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD filter system to map low-end to the high-end markup?

[[Category:SIG]]

FacsimileMarkup

2006-02-24T09:04:17Z

Conal:

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

Conal is going to produce some quick samples.

== Tasks ==

# collate [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# develop straw man facsimile modules:
## a [StrawManFacsimileMarkup|high-end markup]:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD filter system to map low-end to the high-end markup?

[[Category:SIG]]

FacsimileMarkup

2005-12-16T14:05:23Z

Conal: created a note about work on Facsimile markup for linking page images to text

== Introduction ==

The Facsimile task force / SIG is about markup of facsimile images with correspondence to parts of the text.

Conal is going to produce some quick samples.

== Tasks ==

# collate [[LegacyFacsimileMarkup|existing markup]], including simple pb/@url style markup at one extreme and METS at the other
# develop straw man facsimile modules:
## a high-end markup:
### list of facsimile images,
### each image linked to a locations in the text by a typed link (e.g. thumbnail, display...)
### see METS structure map
### link between text and fragments ''within'' an image? (e.g. svg region) Requires another indirection
## a low-end markup: <pb n="1" url="page-1.jpg"/>
## other widely-used style of markup?
### use ODD filter system to map low-end to the high-end markup?

[[Category:SIG]]