first-stage collation processing in the Frankenstein Variorum Project. For post processing and Variorum development, see our GitHub organization: https://github.com/FrankensteinVariorum
Here is a list of things that @Yuying-Jin and I have decided are best handled in post-processing of collation files with XSLT.
Ampersand and other special characters generated by nodeToXML() output of longTokens, adds, dels (inlineVariationEvent): & or "
ONLY if in fact these do prove to be a problem. (They may turn out just as & after all in the edition output!)
For inlineVariation events where we have constructed "long tokens": we now output these as a complete unit from start to end in only one <rdgGrp> and <rdg>. This means that sometimes the other witnesses split around them awkwardly. We should smooth out the awkwardness with this algorithm:
If the contents of a "long token" contains() a string from the very next <app> element following::app[1], then move the contents of that very next <app> up into the current app of the long token, and remove the very next <app>.
Here is a list of things that @Yuying-Jin and I have decided are best handled in post-processing of collation files with XSLT.
Ampersand and other special characters generated by nodeToXML() output of longTokens, adds, dels (inlineVariationEvent):
&amp;
or&quot;
&
after all in the edition output!)For inlineVariation events where we have constructed "long tokens": we now output these as a complete unit from start to end in only one
<rdgGrp>
and<rdg>
. This means that sometimes the other witnesses split around them awkwardly. We should smooth out the awkwardness with this algorithm:contains()
a string from the very next<app>
elementfollowing::app[1]
, then move the contents of that very next<app>
up into the current app of the long token, and remove the very next<app>
.