Another take on the English Apostrophe in Unicode

On Fri, Jun 5, 2015, David Starner
wrote:

> On Fri, Jun 5, 2015 at 12:16 AM Leo Broukhis wrote:

>> I agree that conflating apostrophes and quotes is a source of
>> problems, however, existence of the MODIFIER LETTER [same glyph as
>> used for English contractions] in Unicode is a coincidence which
>> should not have an effect on usage of apostrophes in English.

> Coincidence or not, the Unicode Consortium is not going to allocate a new code-point for the English apostrophe as long as MODIFIER LETTER APOSTROPHE exists. Any change is pretty unlikely, but changing to an existing character is vastly more likely then creating a new one.

In fact this would be a return to the state until version 2.0.0.
http://www.unicode.org/Public/2.0-Update/NamesList-1.txt
Since version 3.0.0 (or more precisely, since update 2.1), U+2019 is preferred for apostrophe, not U+02BC any longer. http://www.unicode.org/Public/3.0-Update/NamesList-3.0.0.txt

Prior to this discovery, I supposed it could have been later ISO prescriptions which triggered it the wrong way, but now it's impossible ISO initiated the move of preferred apostrophe from U+02BC to U+2019. This change took place not sooner than in update 2.1, whereas the merger was at 1.1 and ISO stands for stability. So ISO could never agree that the preferred character for English apostrophe stopped to be U+02BC and started to be U+2019, against the Stability Policy, and presumably using a gap in this policy which possibly don’t cover usage recommendations...

I must do some more research in the Archives to find out more about why the apostrophe and the single close quote were ambiguated—a process that needs even a new word to put on it, as ordinarily everybody works for disambiguation...

However, the 1999 Mail Archive already shows it was for simplification's sake, in word processing software.

Could anybody tell us more about this issue?

IMHO, the mischievous apostrophe that we use today, is due to a shortcut, narrowed design, and uncomplete check-ups. Briefly, the disconnect was between Unicode whose global approach lead to complete solutions including all you need for text handling and word processing, and Microsoft whose industrial approach prioritized the ready make-up of output appearance, letting out of scope the subsequent lifestages of text. The Windows code page 1252 apostrophe-close-quote looks nice on screen and in the documents, but as soon as you need to convert quotes from British to American or from free to nested, the only way to prevent your text from becoming unusable is to hand-process the quotes one by one. The money you saved when purchasing the software, is lost thousandfold at use. Microsoft’s choice of mashing up apostrophe and close-quote to end up with an unprocessable hybrid was wrong. Very wrong.

Marcel Schneider
Received on Sat Jun 13 2015 - 09:14:09 CDT