You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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>.
The text was updated successfully, but these errors were encountered:
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>
.The text was updated successfully, but these errors were encountered: