Balisage Paper: The Hard Edges of Soft Hyphens

Soft hyphens

In the modern post-Unicode era, a soft hyphen is typically defined as a spot where you, the word processor, may break this word across a line break, if needed^[1] But even as recently as ISO 8859 a soft hyphen was for use when a line break has been established within a word^[2] Although not called a soft hyphen back then, this use of the hyphen has been around for centuries. E.g., the OED cites NWEW as saying Hyphen … is used … when one part of a word concludes the former Line, and the one begins the next. It is this latter (older) definition with which we are concerned here: a computer character (or other XML construct) used in a transcription to indicate where an end-of-line hyphen was printed in the source text to indicate this word is continued on the next line.

The use of such characters (hyphen to indicate word continued on next line) is nearly ubiquitous in printed works (at least in English). For example, I searched Google Books for the word balisage, and looked at the first book listed.^[3] Even though I cannot read it because it is in French, there are obviously four soft hyphens on the first page of printed prose alone (i.e., ignoring the title page, etc.); that page has just over 200 words spread over 20 lines. In the first full chapter of Michael Kay’s book^[4] I counted 67 soft hyphens in roughly 17,760 words over roughly 1410 lines.

Recording lineation and end-of-line hyphens

The Text Encoding Initiative Guidelines for Electronic Text Encoding and Interchange contain a discussion of how to handle these extant typographic indicators.^[5] One common solution is to ignore the soft hyphens, and to simply transcribe the word that has been broken across a line break as a single word. Consider the following example.^[6]

      so far they’d been smart enough to keep quiet about it. I’d never seen any
      posts about the Tomb of Horrors on any gunter message boards. I realized,
      of course, that this might be because my theory about the old D&D
      module was completely lame and totally off base.</p>
    

      so far they’d been smart enough to keep quiet about it. I’d
      never seen any posts about the Tomb of Horrors on any
      gunter message boards. I realized, of course, that this might
      be because my theory about the old D&D module was
      completely lame and totally off base.</p>
    

      <lb/>so far they’d been smart enough to keep quiet about it. I’d never seen any
      <lb/>posts about the Tomb of Horrors on any gunter message boards. I realized,
      <lb/>of course, that this might be because my theory about the old D&amp;D
      <lb/>module was completely lame and totally off base.</p>
    

In all three of the above encodings, the word realized has been silently reconstituted from its constituent parts, the initial portion immediately prior to the soft hyphen, and the final portion shortly after the soft hyphen. In the first and third examples the soft hyphen is resolved by moving the final portion of the word up from the begining of its line to the end of the previous line (which I call finalUp). It could just as easily have been resolved by moving the initial portion of the word from the end of its line to the beginning of the next line (which I call initDown). For most of this paper I will discuss resolution in only the finalUp direction, but the issues generally apply equally well to both directions.

Personally, I do not like that third (last) encoding. It explicitly asserts there was a line break in the source document between realized, and of course, which is not true. But nonetheless, the practice is not uncommon. The first encoded example is not nearly so bad, as its implication that there was a line break at that spot is implicit, not explicit. The middle of the three encoding possibilities is not objectionable in assertion of line breaks at all, since it makes no such assertions. (One could infer them, but they are not implied.) However, many projects will find it a disadvantage to transcribe prose completely irrespective of original lineation. Keeping track of original lineation is very helpful when trying to align the source document with the transcription (or the output of processing the transcription). Even if a project does not think the users of its transcribed texts will appreciate this alignment, the project proofreaders will — a lot.

Another common approach is to explicitly record both the hyphen character and original lineation. Consider the following example.^[8]

         It turns out that the most important voice in the Su‐
      preme Court nomination battle is not the American peo‐
      ple’s, as Senate Republicans have insisted from the mo‐
      ment Justice Antonin Scalia died last month. It is not even
      that of the senators. It’s the National Rifle Association’s.
         That is what the majority leader, Mitch McConnell,
      said the other day when asked about the possibility of con‐
      sidering and confirming President Obama’s nominee,
      Judge Merrick Garland, after the November elections. “I
      can’t imagine that a Republican majority in the United
      States Senate would want to confirm, in a lame-duck ses‐
      sion, a nominee opposed by the National Rifle Associa‐
      tion,” he told “Fox News Sunday.”
    

      <p>It turns out that the most important voice in the Su<pc force="weak">-</pc>
      <lb break="no"/>preme Court nomination battle is not the American peo<pc force="weak">-</pc>
      <lb break="no"/>ple’s, as Senate Republicans have insisted from the mo<pc force="weak">-</pc>
      <lb break="no"/>ment Justice Antonin Scalia died last month. It is not even
      <lb/>that of the senators. It’s the National Rifle Association’s.</p>
      <p>That is what the majority leader, Mitch McConnell,
      <lb/>said the other day when asked about the possibility of con<pc force="weak">-</pc>
      <lb break="no"/>sidering and confirming President Obama’s nominee,
      <lb/>Judge Merrick Garland, after the November elections. “I
      <lb/>can’t imagine that a Republican majority in the United
      <lb/>States Senate would want to confirm, in a lame-duck ses<pc force="weak">-</pc>
      <lb break="no"/>sion, a nominee opposed by the National Rifle Associa<pc force="weak">-</pc>
      <lb break="no"/>tion,” he told “Fox News Sunday.”</p>
    

At my project^[9] we encode soft hyphens using the Unicode character SOFT HYPHEN (U+00AD). Given that this character is explicitly of the a word processor may insert a hyphen here if needed variety, in some sense it is technically incorrect to use it for this purpose. Furthermore, the TEI Guidelines do not recommend this use. In our defense, we chose this path back in the ISO 8859 days, and when ­ was an SGML SDATA reference that did not necessarily mean code-point 0xAD. But more importantly, the detail of which character is used to represent the this word is continued on the next line glyph that was on the source page does not matter, so long as it is not also used for some other purpose in the same file. So, given that we are encoding early modern printed books, we could just as well have used the EURO SIGN (U+20AC) for this purpose. In either case it is character abuse; however the abuse of SOFT HYPHEN seems much less dramatic than would be the abuse of EURO SIGN: this has something to do with hyphenation, and nothing to do with currency.

So our encoding of the excerpt from the New York Times editorial would be as follows.^[10]

        <p>It turns out that the most important voice in the Su&#xAD;
        <lb/>preme Court nomination battle is not the American peo&#xAD;
        <lb/>ple's, as Senate Republicans have insisted from the mo&#xAD;
        <lb/>ment Justice Antonin Scalia died last month. It is not even
        <lb/>that of the senators. It's the National Rifle Association's.</p>
        <p>That is what the majority leader, Mitch McConnell,
        <lb/>said the other day when asked about the possibility of con&#xAD;
        <lb/>sidering and confirming President Obama's nominee,
        <lb/>Judge Merrick Garland, after the November elections. <said>I
        <lb/>can't imagine that a Republican majority in the United
        <lb/>States Senate would want to confirm, in a lame-duck ses&#xAD;
        <lb/>sion, a nominee opposed by the National Rifle Associa&#xAD;
        <lb/>tion,</said> he told <title>Fox News Sunday.</title></p>
      

Desired output

Encoding texts serves little purpose unless some sort of analysis or output generation (or both) is undertaken. If all we wanted to do was read the text, scanned images of the pages would do.

Consider the following snippet of an encoded text:^[11]

        <p>Whatever has been ſaid 
        <lb n="14"/>by Men of more Wit than
        <lb n="15"/>Wiſdom, and perhaps of
        <lb n="16"/>more malice than either,
        <lb n="17"/>that Women are natural&#xAD;
        <lb n="18"/>ly Incapable of acting Pru&#xAD;
        <lb n="19"/>dently, or that they are
        <lb n="20"/>neceſſarily determined to
        <lb n="21"/>folly, …
      

As with analyses, for most purposes we would prefer to read the text with as few interruptions to words as possible. The obvious exception is when we want to align reading of the processed output with the physical source page or a facsimile thereof. This alignment makes proofreading much easier.

Thus for proofreading we might like to see something like the following.

        13: Whatever has been ſaid 
        14: by Men of more Wit than
        15: Wiſdom, and perhaps of
        16: more malice than either,
        17: that Women are natural-
        18: ly Incapable of acting Pru-
        19: dently, or that they are
        20: neceſſarily determined to
        21: folly, …
      

        Whatever has been said by Men of more Wit than Wisdom, and
        perhaps of more malice than either, that Women are naturally
        Incapable of acting Prudently, or that they are necessarily
        determined to folly, …
      

When I’m wrong, I can be really wrong

Like many people, I make good predictions and bad ones. But sometimes I make truly horrible predictions. E.g., in early 1995 or thereabouts I infamously said something like remember, the web is not our friend, it is our enemy. Hard to be more wrong than that. But when it came to soft hyphens, it may turn out I was. You see, sometime during the early days of the Women Writers Project I asserted that software could read our documents (in which soft hyphens were encoded using first the &shy. Waterloo Script set symbol (essentially a variable), and later the ­ SGML SDATA entity reference), and resolve the soft hyphen for creating full-text searchable word lists or reading output for undergraduates. I said this with a how hard can it be? attitude, I’m sure.^[12]

Well, as will be discussed in the rest of this paper, it has turned out to be quite hard.

Whitespace

That doesn’t sound too tough. Of course it is obviously a little harder than the diagrams above make it look, for they ignore the whitespace between the blue and red portions:

In order to handle that whitespace we need to

Of course we cannot just normalize whitespace using XPath’s built-in normalize-space() function, as in many cases leading and trailing space are important. E.g., given the following fragment,^[15]

    <p rend="first-indent(1)">How far the passages of scripture
    <lb/>she mentions were applicable to the
    <lb/>conduct of <persName>Mr B</persName> it is not our prov&#xAD;
    <lb/>ince to determine; but it is not 

’Twixt

First thing to keep in mind is that XML constructs other than just the <lb> element may come between the text node that ends in SOFT HYPHEN and the text node that contains the representation of the continued word. Besides the obvious (XML comments and XML processing instructions), first and foremost the feature that forced the typographer to break the word in the first place may have been a page break, not a line break. Page breaks usually have other information associated with them (page numbers, catch words, signature marks, running titles) that are generally encoded where they lie such that they further interrupt the word that has been split. E.g.^[18][19]

            <p>Whoever may come out in any society as Mis&#xAD;
            <pb n="247"/>
            <milestone unit="sig" n="M4r"/>
            <mw type="pageNum">247</mw>
            <lb/>sionaries or teachers, whether here or at <placeName>Sierra-
            <lb/>Leone</placeName>, had need to guard against assimilating too
            <lb/>much in habit or sentiment with other <rs type="properAdjective">European</rs>
            <lb/>residents, …
      

But sadly, it is not only the obvious and predictable (XML comments, XML processing instructions, line breaks, column breaks, and page breaks with their apparatuses) that may come between a soft hyphen and the final portion of a word. The most common culprits here are annotations and figures, but handwritten additions (either authorial or by a later hand) could also occur.

In the following example^[21] an entire tipped-in plate sits between the soft hyphen and the final portion of the word.

        <p>
          <label>I.</label> God spoke of Be-he-moth. What ani&#xAD;
          <pb n="facing 48"/>
          <pb n="facing 49"/>
          <figure>
            <figDesc>An engraving of a “behemoth” (resembles the
            elephant) standing on a grassy bank drinking from a body
            of water, vegitation in background</figDesc>
            <ab type="caption">To face page 49.</ab>
          </figure>
          <pb n="49"/>
          <milestone n="E5r" unit="sig"/>
          <mw rend="align(outside)" type="pageNum">49</mw>
          <lb/>mal is that?
      

Sibling of Overlap

In all of the examples so far, the initial and final portions of the word divided by a soft hyphen are at least at the same hierarchical level of encoding. That is (in XPath terms) from the text node that contains the soft hyphen, the final portion of the word is on the following-sibling:: axis, even if it is not the first text node, or even the first non-whitespace-only text node, on that axis.

However, we are not always so lucky. Here is a modern diplomatic transcription of a heading.^[22]

  <head rend="slant(italic)"><hi rend="slant(upright)">To all vertuous Ladies Honou&#xAD;</hi>
    <lb/>rable or Worſhipfull, and to all other
    <lb/>of <persName rend="slant(upright)">He<vuji>u</vuji>ahs</persName> ſex fearing God, and lo<vuji>u</vuji>ing their
    <lb/><vuji>i</vuji>uſt reputation, grace and peace through
    <lb/><persName>Chriſt</persName>, to eternall glory.
  </head>
      

It would be reasonable to think this phenomenon pernicious, not particularly important, and rare. But a different manifestation of the same hierarchical problem is anything but. When a book is damaged (e.g., by a coffee spill, or torn or mouse-eaten edges of pages), it is common for the damage to be on only one side of the page. Such damage will cause a problem reading either the initial portion (if it is on the right edge) or the final portion (if it is ontFIXME!! he left edge) of a word split across a line break.

In the following example,^[24] the encoder has indicated that she cannot read a few characters at the beginning of each of four lines due to damage, but that either from context alone or from looking at a different edition of the same book she has been able to surmise what must have been printed.

  <lb/>not your own. It is a miſe&#xAD;
  <lb/><supplied reason="damaged">ra</supplied>ble thing for any Wo&#xAD;
  <lb/><supplied reason="damaged">ma</supplied>n, though never ſo great,
  <lb/><supplied reason="damaged">not</supplied> to be able to teach her
  <lb/><supplied reason="damaged">ſerv</supplied>ants; …
        

Text that is not there

If the text that is damaged cannot be read at all, the TEI Guidelines recommend using the <gap> element. While the <gap> element may have content, if it does that content does not provide a transcription of the source text, but rather provides a description of or information about what was not transcribed from the source text; and more often than not <gap> is empty. In the following example,^[25] the encoder is asserting that she could not read a significant portion of the last line.

  <lb/>And alſo ge<vuji>u</vuji>eth them grace to <vuji>v</vuji>ſe in his
  <lb/>glorye, po<vuji>u</vuji>ertie, ignomine, infamie, in&#xAD;
  <lb/>firmitie, with all ad<vuji>u</vuji>erſitie, and the pri&#xAD;
  <lb/><gap extent="over one third of the line" reason="flawed-reproduction"/>tes,
     e<vuji>u</vuji>en to the death<unclear>,</unclear>
      

It is difficult to do so for two main reasons. First, because (unlike most other empty elements we would encounter after a soft hyphen: <cb>, <lb>, <milestone>, and <pb>) the <gap> represents content, it would have to be moved as if it were the first token of content. Second, because a <gap> may represent less than a single word, a single word, or more than a single word, the software will need to parse its attributes (and perhaps content) to determine whether or not the first token of an immediately following text node (that does not start with whitespace) needs to be moved along with the <gap>.

It is unimportant because under no circumstances can the soft hyphen resolution process meet the goal of reconstituting the entire word. Whether for spell checking, for indexing for search, or for generating an easy-to-read display, having pri<gap extent="rest of word"/><lb/><gap extent="roughly one third of the line minus roughly one half of the first word"/> is no better than what you had to begin with.

Choosing the shy

The TEI uses a parallel elements mechanism for recording a variety of editorial interventions. Here I will discuss the correction of apparent errors (<choice>, <sic>, and <corr>), but the same issues hold true for the simple expansion of abbreviations (<choice>, <abbr>, and <expan>), the substitution of one bit of text for another (<subst>, <del>, and <add>), the regularization of archaic or eccentric spelling or typography (<choice>, <orig>, and <reg>), and the simultaneous encoding of multiple variant witnesses (<app>, <rdg>, and <lem>).

The following example^[26] demonstrates two errors in one title, each of which is directly involved in the use of soft hyphens. I will discuss the second error here, and the first one in the next subsection.

If you look carefully at the end of the 3^rd line, you will see that the soft hyphen character is not a hyphen at all. In this reproduction you may find it hard to figure out what it is, but in other editions (I am told) it is more obvious that the character there is a period.

Presuming the encoding project would like to record both the error as it appears in the source text and a modern correction of it, there are two likely TEI encodings of this: letter-level and word-level.

<lb/>Bench</placeName>, for the releaſing of all pri<choice><sic>.</sic><corr>&#xAD;</corr></choice>
<lb/>ſoners for Debt, according to
      

<lb/>Bench</placeName>, for the releaſing of all pri<choice><sic>.</sic><corr>ſoners</corr></choice>
<lb/>for Debt, according to
      

In rare cases we might be interested in the uncorrected source text. In which case soft hyphen resolution software has to be smart enough to perform the resolution on the text in <sic> based on the content of <corr>. In theory a project may want to perform soft hyphen resolution in both the uncorrected source and the editorially corrected text. I do not address this particular situation here, as I have never even heard this idea entertained.

Word-level correction is a bit easier for soft hyphen resolution, as the simple algorithm yields a perfectly acceptable result.

<lb/>Bench</placeName>, for the releaſing of all <choice>
  <sic>pri.<lb/>ſoners</sic>
  <corr>pri&#xAD;<lb/>ſoners</corr>
</choice> for Debt, according to
      

Shy of the choice

Anything more than a cursory or rapid read of the first two lines reveals an egregious error, probably by the typesetter: the word commanders is spelled commanmanders, as the medial letters man are not only in the initial portion of the word, but are also repeated after the soft hyphen. Multiple possible encodings jump to mind. The editor may consider the man at the end of the first line as the correct one, and thus the man at the beginning of the second line as the one error; or vice-versa. And in each case the encoder may use letter-level or word-level encoding.

<titlePart type="second">Alſo a Petition of divers Comman&#xAD;
<lb/><choice><sic>man</sic><corr/></choice>ders, priſoners in the <placeName>Kings  
      

<titlePart type="second">Alſo a Petition of divers <choice>
  <sic>Comman&#xAD;<lb/>manders</sic>
  <corr>Comman&#xAD;<lb/>ders</corr>
</choice>, priſoners in the <placeName>Kings    
      

<titlePart type="second">Alſo a Petition of divers Com<choice><sic>man</sic><corr/></choice>&#xAD;
<lb/>manders, priſoners in the <placeName>Kings 
      

<titlePart type="second">Alſo a Petition of divers <choice>
  <sic>Comman&#xAD;<lb/>manders</sic>
  <corr>Com&#xAD;<lb/>manders</corr>
</choice>, priſoners in the <placeName>Kings    
      

<titlePart type="second">Alſo a Petition of divers <choice>
  <sic>Comman&#xAD;<lb/>manders</sic>
  <corr>Commanders</corr>
</choice>, priſoners in the <placeName>Kings    
      

Early Days

Roughly speaking, in the 1980s the WWP used Waterloo Script; in the early 1990s we used Waterloo GML; in the mid 1990s we used Waterloo GML using pointy brackets (< and >) instead of the default tag delimiters : and .; in the late 1990s we used SGML, but still did most processing with Waterloo Script; and in the early 21^st century we switched to XML.

In mid-1991 the WWP embarked on a collaboration with Oxford University Press to publish a series of books based on our textbase files. Thus I went to work on a program to generate camera-ready PostScript output from our pseudo-SGML input, using Waterloo Script. I believe this was the first time we actually wrote code to resolve our soft hyphens, which. The snippet of code below is from a subroutine of that program written in 1991-10. The &*txt0. set symbol contains a line of text with each SPACE (U+0020) converted to a COMMERCIAL AT (U+0040) character. In the input files at that time a soft hyphen was encoded just like a hard hyphen, i.e. using the HYPHEN-MINUS character (U+002D).

. .*
. .* check the first character; if it is a blank ("@") AND our "we
. .* chopped a hyphen off last time we appended" flag is set, chop off
. .* the blank.
. .*
. .if "&'substr( &*txt0., 1, 1 )" = "@" & &nw_shyl. = 1
.   .sr *txt1 = &'substr( &*txt0., 2 )
. .el .sr *txt1 = &*txt0.
. .*
. .*
. .* parse off the last character; if it is the CONTinuation character,
. .* chop it off.  (For some reason in this context Script treats it as
. .* a text character.)
. .*
. .sr *len = &'length( &*txt1. )
. .sr *last = &'substr( &*txt1., &*len., 1 )
. .*
. .if "&*last." = "&$cont." .sr *txt2 = "&'substr(&*txt1.,1,&*len.-1 )"
. .el                       .sr *txt2 = "&*txt1."
. .*
. .*
. .* if there are still characters left, check the last one; if it is a
. .* hyphen, chop it off (Script will not treat it as a soft hyphen
. .* here!), and set a flag
. .*
. .sr *len = &'length( &*txt2. )
. .if &*len. gt 0 .do begin
.   .sr *last = "&'substr( &*txt2., &*len., 1 )"
.   .*
.   .if "&*last." = "&shy." .th .do begin
.     .sr *txt3 = "&'substr(&*txt2., 1, &*len.-1 )"
.     .sr nw_shyl = 1
.     .do end
.   .el .do begin
.     .sr *txt3 = &*txt2.
.     .sr nw_shyl = 0
.     .do end
.   .do end
. .*
      

My vague recollection is that the above code worked reasonably well, but e-mail I sent in 1994-03 makes it clear it always had problems: hyphens [are] top prio[rity], so I will be tackling that … My thinknig rightg now is that I've spent years trying to figure out how to get SCRIPT to handle this w/o success. But it would be trivial to massage the original file w/ Perl (or maybe even BBEdit) in order to remove soft hyphens, at least in simple <lb> case, and probably others. I do not recall what the problems were. My vague recollection is this system had the capability to handle section “’Twixt” problems well, because this routine was not called on strings that were not part of the main text flow; i.e. it was not used for page apparatus, annotations, figure descriptions, etc.

 $in =~ s,&shy;\s*<lb[^>]*>(<anchor[^>]*>)([^ \t\r\n<]*),\2\1,igs;
 $in =~ s,&shy;\s*(<anchor[^>]*>)\s*<lb[^>]*>([^ \t\r\n<]*),\2\1,igs;
 $in =~ s,&shy;\s*<lb[^>]*>,,igs;
        

 /*
 ** Now do the real work in one big pipeline; it would be fast
 ** except that the SPILL stage is written in Rexx. Oh well.
 */
 'pipe (long endchar #) <' fn ft fm, /* read file in */
    '| nfind <pgbk',                 /* nuke page-break lines */
    '| join * /@/',                  /* now 1 line, remembering \n's  */
    '| split after string />/',      /* chop into reasonable size parts */
    '| change /-@<lb/<NUKEME/',      /* mark hyphen-EOL-<lb             */
    '| change /-@<cl>/<NUKEME>/',    /* mark hyphen-EOL-<cl>            */
    '| change /-@<cl /<NUKEME /',    /* mark hyphen-EOL-<cl_            */
    '| join *',                      /* back into 1 line                */
    '| split before string /</',     /* now chop up such as to separate */
    '| split after string />/',      /*   tags onto lines of their own  */
    '| nfind <NUKEME',               /* and kill marked records         */
    '| t: find <',                   /* take only the tags              */
    '| change / /%/',                /* and protect internal blanks     */
    '| a: faninany',                 /* get back non-tags               */
    '| join *',                      /* back into 1 line, again         */
    '| split before string /@/',     /* cut into pieces at orginal \n's */
    '| change /@//',                 /* nuke our \n markers */
    '| spill 153 sep|',              /* make sure not too long          */
    '  change /%/ /',                /* restore protected blanks-in-tags*/
    '| >' ofid,                      /* write to output file */
    '# t:',
    '| a:'
      

XSLT

And so it went — for years the WWP limped by on various hacks to resolve soft hyphens. Then in 2011 we began moving our publication to XTF, a XSLT system built almost entirely on XSLT.^[30] Thus we attempted to resolve soft hyphens in XSLT.

  <lb/>
  <pcdata xml:id="d2t6"
          endsInShy="true"
          multiWord="true"
          space1st="false"
          firstWord="procuring"
          restWords="a ſpeedy adminiſtration of Juſ&#xAD; ">procuring a ſpeedy adminiſtration of Juſ&#xAD;
  </pcdata>
  <lb/>
  <pcdata xml:id="d2t8"
          endsInShy="false"
          multiWord="true"
          space1st="false"
          firstWord="tice"
          restWords="for the impartiall puniſhment of all ">tice for the impartiall puniſhment of all
  </pcdata>
  <lb/>
  <pcdata xml:id="d2t10"
          endsInShy="false"
          multiWord="true"
          space1st="false"
          firstWord="offenders,"
          restWords="to the relief and comfort of the ">offenders, to the relief and comfort of the
  </pcdata>
      

 <lb/>
 <tmp:tok xml:id="d2t6.1" endsInShy="false" tmp:spaceBefore="false">procuring</tmp:tok>
 <tmp:tok xml:id="d2t6.2" endsInShy="false">a</tmp:tok>
 <tmp:tok xml:id="d2t6.3" endsInShy="false">ſpeedy</tmp:tok>
 <tmp:tok xml:id="d2t6.4" endsInShy="false">adminiſtration</tmp:tok>
 <tmp:tok xml:id="d2t6.5" endsInShy="false">of</tmp:tok>
 <tmp:tok xml:id="d2t6.6" endsInShy="true">Juſ</tmp:tok>
 <lb/>
 <tmp:tok xml:id="d2t8.1" endsInShy="false" tmp:spaceBefore="false">tice</tmp:tok>
 <tmp:tok xml:id="d2t8.2" endsInShy="false">for</tmp:tok>
 <tmp:tok xml:id="d2t8.3" endsInShy="false">the</tmp:tok>
 <tmp:tok xml:id="d2t8.4" endsInShy="false">impartiall</tmp:tok>
 <tmp:tok xml:id="d2t8.5" endsInShy="false">puniſhment</tmp:tok>
 <tmp:tok xml:id="d2t8.6" endsInShy="false">of</tmp:tok>
 <tmp:tok xml:id="d2t8.7" endsInShy="false">all</tmp:tok>
 <lb/>
 <tmp:tok xml:id="d2t10.1" endsInShy="false" tmp:spaceBefore="false">offenders,</tmp:tok>
 <tmp:tok xml:id="d2t10.2" endsInShy="false">to</tmp:tok>
 <tmp:tok xml:id="d2t10.3" endsInShy="false">the</tmp:tok>
 <tmp:tok xml:id="d2t10.4" endsInShy="false">relief</tmp:tok>
 <tmp:tok xml:id="d2t10.5" endsInShy="false">and</tmp:tok>
 <tmp:tok xml:id="d2t10.6" endsInShy="false">comfort</tmp:tok>
 <tmp:tok xml:id="d2t10.7" endsInShy="false">of</tmp:tok>
 <tmp:tok xml:id="d2t10.8" endsInShy="false">the</tmp:tok>