Syd Bauman has again rescued me from faulty encoding, an encoding issue that dates from the preparation of my dissertation edition. I used a workaround to resolve an issue of display, but it turns out that an alternate fix (a better one) is available.
The problem revolved around what I consider to be a necessary distinction between closing single quotes and apostrophes. The logical distinction between closing quotes and apostrophes (one closes quoted speech, one usually indicates missing letters) relies on a reader’s basic conceptual distinction between identical type characters.
One crux of the issue can be found in the UNICODE standards. The curly right single quotation mark (Unicode Character 2019) portion of standard states that “this is the preferred character to use for apostrophe.” Likewise, the straight apostrophe section states that Unicode Character 2019 is “preferred for apostrophe.” The standard is clear–and consistent. We will pass over our aggravation that apos as apos will remain straight and recognize that it’s an historical problem not solved by someone of my interest.
In my dissertation edition, I created two entity references in my DTD to handle these. The apos entity resolved to 2019. The rsquo entity also resolved to 2019. But the display never worked. While the rsquo always displayed as a curly quote, the apos always displayed as a straight quote.
My workaround included replacing apos entities with character code sequences within my document. That workaround fixed the problem of display, but a more simple issue is at work.
The apos entity is reserved in XML. So the parser always resolved to the default display (the straight quote) rather than my DTD definition for the apos (the curly quote). The solution is to NOT use the apos entity for curly apostrophes. Instead, I need to choose an entity that is not reserved. So I chose “apost”. Now the parser will resolve apost with 2019, the curly apostrophe that is identical to the closing single quote.