An important update of the manuscript viewer was released yesterday which was, however, almost impossible to be noticed by the users!
The HumaReC manuscript viewer has been using the EVT version 1.1.1 so far. Last month, however, EVT released version 1.2 and we have now migrated our viewer to the new version. This release adds support for new TEI elements:
* added support for integrations and editorial additions encoded with <supplied>, with particular attention to omissions (@reason="omitted") and illegible text (@reason="illegible");
* added support for columns breaks (<cb>) and tables (<table>);
* added support for <note>s that are not inline and are referenced in the text one or more times with the element <ptr/>;
* added support for <ref>s whose @target attribute refers to a web page;
* many bugs fixed!
For now, the optimisation for the HumaReC viewer concerns only the support for <note>, a big advantage of v. 1.2.
For now, the major difference regarding the HumaReC viewer encoding is the support of <note>, a big advantage of v. 1.2.
In fact, the encoding of the annotation used to be in the text body:
<lb/>ώθη <note type="Comment" xml:id="Note_1Cor_gr5">om. ἐν</note> ὑμῖν · ώστε ὑμᾶς μὴ
Now, the notes are gathered together in the <back> section of the <text>. This brings visibility to the encoding but not only, as explained in the EVT manual:
this is particularly useful when the same <note> may refer to more than one text segment in the document, to avoid redundancy.
The same note now looks like this:
<lb/>ώθη <ptr type="noteAnchor" target="#Note_1Cor_gr5"/> ὑμῖν · ώστε ὑμᾶς μὴ
<back> <note xml:id="Note_1Cor_gr5">om. ἐν</note> </back>
Our XML TEI files are now encoded this way.
We are also very happy about the new support of column breaks <cb>. It will be interesting to have the possibility of faithfully displaying the three columns of the manuscript. We're are currently doing some tests, e.g.:
The images of Marciana Gr. Z. 11 (379) are property of the Marciana Library, all rights reserved.
However, readability is our outmost priority. In our case, we would have to use very small fonts in order to avoid unwanted line breaks. For the time being, the option of toggling among languages seems better suited to our needs, but we are actively working on this question.
Do not hesitate to share your views on this matter!
⇒ Discuss on the forum the article From EVT 1.1.1 to EVT 1.2.
Comments powered by CComment