On Nov 10, 2019, at 7:20 AM, Michael Everson <everson@...> wrote:

On 8 Nov 2019, at 20:23, Nathan Galt <mailinglists@...> wrote:

• In 2007, Michael Everson proposes Shavian Quikscript extensions. He notes that there are some letters that look identical or at least fairly similar in both Quikscript and Shavian and proposes a two-row set of extensions, plus angled parentheses. You can view it at https://www.quikscript.net/proposals/2007.pdf.

I do not remember offhand what the pink bits were. Something for discussion? Or Shavian items not used in Quikscript?

The one up top on the left (𐑳) with no Quikscript counterpart looks like a Shavian letter not used in Quikscript. U+10478 through U+1047F look like pre-ligated Shavian letters that have no real Quikscript equivalent.

Incidentally, I oppose encoding pre-ligated Quikscript letters for the same reasons why encoding the “fi” ligature (U+FB01) was a bad idea. This sort of thing should be handled by fonts, not typists.

• In 2013, Michael Everson has a second proposal. This proposal shoves the angled parentheses into the Miscellaneous Punctuation block and uses only one block of 16 (with room to spare) for the Quikscript letters. You can view it at https://www.quikscript.net/proposals/2013.pdf.

“Shoves”? Please.

Maybe “flings”? U+2E00 is a long ways from U+104xx. At any rate, putting them in the Supplemental Punctuation block seems like a good idea to me.

• The 2013 proposal was controversial. Michael Everson seemed to think that reducing the block count would help it get accepted, especially since the Shavian proposal just squeaked in. I and other people thought that this was too unified and would make it difficult, if not impossible, to be able to develop good fonts that can display both Quikscript and Shavian at the same time.

There is in my view no chance that the UTC will accept a full disunification. Quikscript is a set of Shavian extensions, and a Quikscript font is essentially a handwriting font when compared to a more typographic Shavian font. Bi-scriptal documents written in both Shavian and Quikscript, or mixing them, would seem to be really rather rare.

I agree that mixed Shavian/Quikscript documents are likely to stay rare except for technical discussions like this one.

In fact it should be considered whether Quikscript could be considered an italic version of Shavian. In such a case it might still require extensions. (This is probably not a very good idea.)

I generally figure that italics have a 1:1 letter correspondence with an upright. However, this assumption doesn’t hold for Shavian:Quikscript. Kingsley Read…

- merged 𐑩/𐑳 (/ə/ and /ʌ/) into ·Utter (/ə/)
- split 𐑢 (/w/) into ·Way and ·Why (/w/ and /ʍ/)
- added letters for /ɬ/ and /x/
- added letters for /ks/ and /gz/ (·Ax and ·Exam, to be used sometimes)

• Another person here whose name I forget said something like “Did the Consortium not learn anything in the Greek/Coptic disunification mess?” While an inside-baseball reference, I later learned that this captured the problem (from my view) nicely. It’s a massive pain in the rear to users of somewhat-different scripts to have to share characters, especially for the minority users.

In fairness there is an ocean of both Greek and Coptic data spanning many centuries while there is barely a puddle of Shavian data and an even smaller puddle of Quikscript data.

Agreed.

While I’m not sure we’re a numerical minority compared to Shavianists, we’re Johnny-come-latelies and I expect most every-script font (Noto Sans, Segoe UI Historic, etc.), to cater to Shavian tastes in letterforms first, leaving Quikscript users unable to have letterforms they use. https://www.unicode.org/L2/L2002/02205-n2444-coptic.pdf goes into some of the hassles Coptic readers and fontmakers have; I’ve made similar arguments arguing that I shouldn’t have to read Shavian's ·𐑱 as Quikscript’s ·Eight.

Nothing written in Shavian or Quikscript has the same status as anything written in Coptic or Greek. Sorry but you have to be a realist.

Agreed.

• Between 2013 and now, I’ve developed better arguments in favor of maximally-disunified encodings, like “way more text sent/received these days isn’t sent with fonts under the sender’s or receiver’s control”. (I’ll go into this more for a later worm-can opening.)

Extensions to Shavian would require Shaw-style glyphs for the new Quikscript characters. If the shapes were faithful, you’d get used to reading a typographically rectified Quikscript if it turned up on your phone.

“If the shapes were faithful” is the main point of contention here. My biggest objection to the 2013 proposal is that omnifonts, which will be the fonts used for most display of most Quikscript text, will have confusing letters.

Specifically:

- 𐑱/𐑲 are difficult to properly map, while reading, to ·Eight/·I (although your explanation certainly helped)
- similarly, 𐑬/𐑶 are difficult to properly map to to ·Out/·Oy without screwing this up

I don’t have a major objection to “doesn’t look quite right”; I do to “easily confused with a similar letter”.

I have a number of Shavian fonts and styles (including italic) in my Shavian Alice. None of them are what were found in Androcles.

While I very much appreciate your assistance in toughening up our arguments in favor of standardization, do you realize you’ve entirely ignored my objection and substituted a straw-man one in its place?

If (e-)books, HTML+CSS pages, and Word documents were the only ways in which Quikscript were on the Internet, this wouldn’t be an issue. However,

Now then. What does it take make one font that can display Shavian properly and unligated Quikscript Junior (at the very least) properly? I can think of two main ways that will do this:

• Unify most letters, including ·𐑱/·Eight. Lobby text-layout vendors (Apple, Microsoft, Google, Adobe, etc.) to add “SHA ” and “QIK ” to their lists of supported language system tags, similar to the tags that are already on https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags already. Update omnifonts (Segoe UI Historic, Noto Sans, Apple Symbols, Everson Mono) to use Shavian glyphs by default and specify that Quikscript fonts are to be used if the OS can guess that the text shown is in Quikscript rather than Shavian. Update operating systems to guess whether a chunk of text is merely Shavian or Quikscript, and adjust glyphs used appropriately.

Neither Shavian nor Quikscript are languages. They are scripts.

Agreed, but not relevant. From the page:

Therefore, in several respects, language system tags do not correspond in a one-to-one manner with languages. Even so, many registered tags are intended to represent typographic conventions for a particular language. For cases in which a correlation exists between a tag and one or more languages, the language identities are documented here by reference to ISO 639-2 and ISO 639-3.

This seems like the proper mechanism to selectively enable proper-Quikscript letters in fonts that have both Shavian-style and Quikscript-style glyphs for the same code point. At the very least, the page’s authors seem to be open to adding not-quite-languages: they’ve already added ones for both Americanist and IPA phonetic transcriptions.

• Unify no letters. Not even ·𐑩/·utter (Shavian vowels tend to be written to be skinny for whatever reason). Update omnifonts to add Quikscript glyphs.

If you can’t convince me of this there’s little chance I could convince the UTC.

The 2013 proposal disunifies nine — not even a whole row. If I can pick out sixteen (or fewer!) of the most problematic characters, does that materially reduce the chances of convincing the UTC?

On Nov 11, 2019, at 9:30 AM, Michael Everson <everson@...> wrote:

The real problem are these four:

SHAVIAN LETTER THIGH looks just like QUIKSCRIPT LETTER FEE

This is fine, à la LATIN LETTER C.

Also fine: SHAVIAN LETTER THEY and the close-enough QUIKSCRIPT LETTER VIE.

SHAVIAN LETTER VOW looks just like QUIKSCRIPT LETTER HE

No, it doesn’t. 𐑝 goes below the baseline (is Deep); ·He goes above the x-height (is Tall).

Incidentally, Quikscript’s own ·They (Deep) and ·She (Tall) also only mostly differ by vertical placement (and therefore what they can ligate with). You’d have to have a particular kind of horrible, un-ligated handwriting to write something in Quikscript where someone else can’t tell whether you wrote “other” or “usher”.

SHAVIAN LETTER MIME looks just like QUIKSCRIPT LETTER AH

SHAVIAN LETTER NUN looks just like QUIKSCRIPT LETTER AWE

This is fine.

I don’t see us getting these three through as extensions. Rather, what I see is LATIN LETTER C, which may be used for /dʒ/, /ð/, /k/, /s/, /ts/, /tʃ/, /ʃ/, /θ/, /ʕ/, and /ǀ/.

Discuss.

That’s what I see, too, modulo 𐑝/·He.

Yes, fine, but that wasn’t the point.

Here you go. This includes QS VEE HE AH and AWE but they are identical to THIGH VOW MIME and NUN

The real problem are these four:

SHAVIAN LETTER THIGH looks just like QUIKSCRIPT LETTER FEE

SHAVIAN LETTER VOW looks just like QUIKSCRIPT LETTER HE

SHAVIAN LETTER MIME looks just like QUIKSCRIPT LETTER AH

SHAVIAN LETTER NUN looks just like QUIKSCRIPT LETTER AWE

I don’t see us getting these three through as extensions. Rather, what I see is LATIN LETTER C, which may be used for /dʒ/, /ð/, /k/, /s/, /ts/, /tʃ/, /ʃ/, /θ/, /ʕ/, and /ǀ/.

Discuss.

On 8 Nov 2019, at 20:23, Nathan Galt <mailinglists@...> wrote:

• In 2007, Michael Everson proposes Shavian Quikscript extensions. He notes that there are some letters that look identical or at least fairly similar in both Quikscript and Shavian and proposes a two-row set of extensions, plus angled parentheses. You can view it at https://www.quikscript.net/proposals/2007.pdf.

I do not remember offhand what the pink bits were. Something for discussion? Or Shavian items not used in Quikscript?

• In 2013, Michael Everson has a second proposal. This proposal shoves the angled parentheses into the Miscellaneous Punctuation block and uses only one block of 16 (with room to spare) for the Quikscript letters. You can view it at https://www.quikscript.net/proposals/2013.pdf.

“Shoves”? Please.

• The 2013 proposal was controversial. Michael Everson seemed to think that reducing the block count would help it get accepted, especially since the Shavian proposal just squeaked in. I and other people thought that this was too unified and would make it difficult, if not impossible, to be able to develop good fonts that can display both Quikscript and Shavian at the same time.

There is in my view no chance that the UTC will accept a full disunification. Quikscript is a set of Shavian extensions, and a Quikscript font is essentially a handwriting font when compared to a more typographic Shavian font. Bi-scriptal documents written in both Shavian and Quikscript, or mixing them, would seem to be really rather rare.

In fact it should be considered whether Quikscript could be considered an italic version of Shavian. In such a case it might still require extensions. (This is probably not a very good idea.)

• Another person here whose name I forget said something like “Did the Consortium not learn anything in the Greek/Coptic disunification mess?” While an inside-baseball reference, I later learned that this captured the problem (from my view) nicely. It’s a massive pain in the rear to users of somewhat-different scripts to have to share characters, especially for the minority users.

In fairness there is an ocean of both Greek and Coptic data spanning many centuries while there is barely a puddle of Shavian data and an even smaller puddle of Quikscript data.

While I’m not sure we’re a numerical minority compared to Shavianists, we’re Johnny-come-latelies and I expect most every-script font (Noto Sans, Segoe UI Historic, etc.), to cater to Shavian tastes in letterforms first, leaving Quikscript users unable to have letterforms they use. https://www.unicode.org/L2/L2002/02205-n2444-coptic.pdf goes into some of the hassles Coptic readers and fontmakers have; I’ve made similar arguments arguing that I shouldn’t have to read Shavian's ·𐑱 as Quikscript’s ·Eight.

Nothing written in Shavian or Quikscript has the same status as anything written in Coptic or Greek. Sorry but you have to be a realist.

• Between 2013 and now, I’ve developed better arguments in favor of maximally-disunified encodings, like “way more text sent/received these days isn’t sent with fonts under the sender’s or receiver’s control”. (I’ll go into this more for a later worm-can opening.)

Extensions to Shavian would require Shaw-style glyphs for the new Quikscript characters. If the shapes were faithful, you’d get used to reading a typographically rectified Quikscript if it turned up on your phone.

I have a number of Shavian fonts and styles (including italic) in my Shavian Alice. None of them are what were found in Androcles.

Now then. What does it take make one font that can display Shavian properly and unligated Quikscript Junior (at the very least) properly? I can think of two main ways that will do this:

• Unify most letters, including ·𐑱/·Eight. Lobby text-layout vendors (Apple, Microsoft, Google, Adobe, etc.) to add “SHA ” and “QIK ” to their lists of supported language system tags, similar to the tags that are already on https://docs.microsoft.com/en-us/typography/opentype/spec/languagetags already. Update omnifonts (Segoe UI Historic, Noto Sans, Apple Symbols, Everson Mono) to use Shavian glyphs by default and specify that Quikscript fonts are to be used if the OS can guess that the text shown is in Quikscript rather than Shavian. Update operating systems to guess whether a chunk of text is merely Shavian or Quikscript, and adjust glyphs used appropriately.

Neither Shavian nor Quikscript are languages. They are scripts. Or they are a single script, which already has an ISO 15924 code “Shaw”.

• Unify no letters. Not even ·𐑩/·utter (Shavian vowels tend to be written to be skinny for whatever reason). Update omnifonts to add Quikscript glyphs.

If you can’t convince me of this there’s little chance I could convince the UTC.

Michael

I have a handful of pre-publication standardization-advocacy web pages that use glyphs from both scripts. While I suspect the Consortium will be underwhelmed by this even if I do end up publishing them, I’d argue that the document doesn’t matter as much anymore.