Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 17:07, John H. Jenkins wrote: > This should teach me to double-check before posting. The research is a lot of fun. Can’t wait till I get Ken’s book next week. > Apparently, the earlier typeface *did* include all forty letters; it just > didn't use these

Re: Standaridized variation sequences for the Desert alphabet?

> On Mar 27, 2017, at 2:04 AM, James Kass wrote: > >> >> If we have any historic metal types, are there >> examples where a font contains both ligature >> variants? > > Apparently not. > > John H. Jenkins mentioned early in this thread that these ligatures > weren't

Encoding of old compatibility characters

I’ve recently developed an interest in old legacy text encodings and noticed that there are various characters in several sets that don’t have a Unicode equivalent. I had already started research into these encodings to eventually prepare a proposal until I realised I should probably ask on the

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 16:56, John H. Jenkins wrote: >> John H. Jenkins mentioned early in this thread that these ligatures weren't >> used in printed materials and were not part of the official Deseret set. >> They were only used in manuscript. > > This is correct. Neither of

Re: Encoding of old compatibility characters

On 27 Mar 2017, at 15:44, Charlotte Buff wrote: > > I’ve recently developed an interest in old legacy text encodings and noticed > that there are various characters in several sets that don’t have a Unicode > equivalent. I had already started research into

Re: Encoding of old compatibility characters

Apple IIs also had inverse-video letters, and some had "MouseText" pseudographics used to simulate a Mac-like GUI in text mode. I know that a couple of fonts from Kreative put these in the PUA and Nishiki-Teki follows their lead. On Mon, Mar 27, 2017 at 9:25 AM Charlotte Buff <

Re: Encoding of old compatibility characters

TI caculators are not antique tools, and when I see how most calculators for Android or Windows 10 are now, they are not as usable as the scientific calculators we had in the past. I know at least one excellent calculator that works with Android and Windows and finally has the real look and feel

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 15:04, Alastair Houghton wrote: > 1. Unicode has to be usable *today*; it’s no good designing for some kind of > hyper-intelligent AI-based font technology a thousand years hence, because we > don’t have that now. If it isn’t usable today for

Re: Encoding of old compatibility characters

I think the interest has been low because very few documents survive in these encodings, and even fewer documents using not-already-encoded symbols. In my opinion, this is a good use of the Private Use Area among a very small group of people. See also

Re: Encoding of old compatibility characters

On 3/27/2017 7:44 AM, Charlotte Buff wrote: Now, one of Unicode’s declared goals is to enable round-trip compatibility with legacy encodings. We’ve accumulated a lot of weird stuff over the years in the pursuit of this goal. So it would be natural to assume that the unencoded characters from

Re: Encoding of old compatibility characters

On 27 Mar 2017, at 17:49, Markus Scherer wrote: > > I think the interest has been low because very few documents survive in these > encodings, and even fewer documents using not-already-encoded symbols. That doesn’t mean that the few people who may need the characters now

Re: Encoding of old compatibility characters

On 27 Mar 2017, at 18:08, Garth Wallace wrote: > > Apple IIs also had inverse-video letters, and some had "MouseText" > pseudographics used to simulate a Mac-like GUI in text mode. > > I know that a couple of fonts from Kreative put these in the PUA and > Nishiki-Teki

Re: different version of common/annotations/ja.xml

I think he meant Kanji/Han ideographic by "committed string". 2017-03-27 19:04 GMT+09:00 Takao Fujiwara : > On 03/27/17 18:48, Mark Davis ☕️-san wrote: > >> By "committed strings", you mean the hiragana phonetic reading? >> > > Hiragana is used to the raw text of the

RE: Unicode Emoji 5.0 characters now final

announcements at Unicode dot org wrote: > — and new regional flags for England, Scotland, and Wales. It's not clear from this text, nor from the table in Section C.1.1 of the draft, what the status is of flag emoji tag sequences other than the three above. I read the relevant section a couple

Re: Unicode Emoji 5.0 characters now final

2017-03-27 21:17 GMT+02:00 Doug Ewell : > announcements at Unicode dot org wrote: > > > — and new regional flags for England, Scotland, and Wales. > > It's not clear from this text, nor from the table in Section C.1.1 of > the draft, what the status is of flag emoji tag

Re: Encoding of old compatibility characters

> It’s hard to say without knowing what the characters are. For the ZX80, the missing characters include five block elements (top and bottom halfs of MEDIUM SHADE, as well as their inverse counterparts), and inverse/negative squared variants of European digits and the following symbols: " £ $ : ?

Re: different version of common/annotations/ja.xml

By "committed strings", you mean the hiragana phonetic reading? Mark On Mon, Mar 27, 2017 at 11:00 AM, Takao Fujiwara wrote: > Hi, > > Do you have any chances to create a different version of ja.xml of the > Japanese emoji annotation? >

different version of common/annotations/ja.xml

Hi, Do you have any chances to create a different version of ja.xml of the Japanese emoji annotation? http://unicode.org/cldr/trac/browser/tags/latest/common/annotations/ja.xml That file includes Hiragana only but I'd need another file which has the committed strings, likes ja_convert.xml.

Re: Standaridized variation sequences for the Desert alphabet?

While I hesitate to dive in to this argument, Martin makes one comment where I think a point of principle arises: On 2017-03-27, =?UTF-8?Q?Martin_J._D=c3=bcrst?= wrote: [Michael wrote] >> You know, Martin, I *have* been doing this for the last two decades. I’m >> well

Re: different version of common/annotations/ja.xml

On 03/27/17 18:48, Mark Davis ☕️-san wrote: By "committed strings", you mean the hiragana phonetic reading? Hiragana is used to the raw text of the phonetic reading by the Japanese input method before the conversion. After users select one of the converted strings, the converted strings are

Re: Standaridized variation sequences for the Desert alphabet?

On 2017/03/24 23:37, Michael Everson wrote: On 24 Mar 2017, at 11:34, Martin J. Dürst wrote: On 2017/03/23 22:48, Michael Everson wrote: Indeed I would say to John Jenkins and Ken Beesley that the richness of the history of the Deseret alphabet would be impoverished

Re: Standaridized variation sequences for the Desert alphabet?

On 2017/03/27 01:20, Michael Everson wrote: On 26 Mar 2017, at 16:45, Asmus Freytag wrote: Consider 2EBC ⺼ CJK RADICAL MEAT and 2E9D ⺝ CJK RADICAL MOON which are apparently really supposed to have identical glyphs, though we use an old-fashioned style in the charts

Re: Standaridized variation sequences for the Desert alphabet?

Martin J. Dürst responded to Michael Everson, > Unfortunately, much of what you wrote gave me the > impression that you may think that historical origin > is the only criterion, or a criterion that trumps all > others. If you don't think so, it would be good if you > could confirm this. If you

Re: Standaridized variation sequences for the Desert alphabet?

Martin J. Dürst responded to Michael Everson, > Overall, we may have up to four variants, of which > three are currently explicitly supported in Unicode. Yes. > Are all of these used as spelling variants? Is there another possible use? > Is the choice of variant up to the author (for which >

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 05:58, James Kass wrote: > > Asmus Freytag wrote, > >> In the current case, you have the opposite, to wit, the text elements are >> unchanged, but you would like to add alternate code elements >> to represent what are, ultimately, the same text

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 06:42, Martin J. Dürst wrote: >> The default position is NOT “everything is encoded unified until disunified”. > > Neither it's "everything is encoded separately unless it's unified”. These Deseret letters aren’t encoded. For my part I wasn’t made

RE: Unicode Emoji 5.0 characters now final

Ken Whistler wrote: > As for how "users" are supposed to know the difference. Well, they > don't. What matters is that the data file that the "implementers" will > use has these 3 emoji tag sequences in it, so that is quite likely > what everybody will see added to their phones. The "users" will

Re: Unicode Emoji 5.0 characters now final

On 3/27/2017 1:39 PM, Philippe Verdy wrote: Note also that ISO3166-2 is far from being stable, and this could contradict Unicode encoding stability: it would then be required to ensure this stability by only allowing sequences that are effectively registered in

Re: Unicode Emoji 5.0 characters now final

On Mon, 27 Mar 2017 13:34:09 -0700 Ken Whistler wrote: > And if a flag of > California (or Pomerania or ...) then gets added to the list of emoji > tag sequences in a future version of the data, there is a good chance > that the "users" will then see the difference, because

Re: Encoding of old compatibility characters

An example of a legacy character successfully encoded recently is ⏨ U+23E8 DECIMAL EXPONENT SYMBOL, encoded in Unicode 5.2. It came from the Soviet standard GOST 10859-64 and the German standard ALCOR. And was proposed by Leo Broukhis in this proposal

Re: Unicode Emoji 5.0 characters now final

(this time from the correct account) Philippe and others, http://www.unicode.org/reports/tr51/tr51-11.html#valid-emoji-tag-sequences refers to CLDR data for the list of valid subregion sequences, see

Re: Unicode Emoji 5.0 characters now final

And the new region of Normandie still has no formal code, but it reuses a flag that was used by one of the two former regions. Technically I don't see that as a problem except that people may want to display that flag using the code for the former region and semantically this is different (and

Re: Unicode Emoji 5.0 characters now final

Note also that ISO3166-2 is far from being stable, and this could contradict Unicode encoding stability: it would then be required to ensure this stability by only allowing sequences that are effectively registered in http://www.unicode.org/Public/emoji/5.0/emoji-sequences.txt (independantly of

RE: Unicode Emoji 5.0 characters now final

Philippe Verdy wrote: > We still lack an encoding standard for vexillologists. And for now > only "Flags of the World" proposes some encoding (not based strictly > and only on ISO3166). I think that the UTC should try contacting > authors of Flags of the World and seek for advice there: we are >

Re: Encoding of old compatibility characters

Another example, about to be encoded, it the GOUP MARK, used on old IBM computers (proposal: ML threads: http://www.unicode.org/mail-arch/unicode-ml/y2015-m01/0040.html , and http://unicode.org/mail-arch/unicode-ml/y2007-m05/0367.html ) Le 27/03/2017 à 23:46, Frédéric Grosshans a écrit : An

Re: Unicode Emoji 5.0 characters now final

On 3/27/2017 12:17 PM, Doug Ewell wrote: announcements at Unicode dot org wrote: — and new regional flags for England, Scotland, and Wales. It's not clear from this text, nor from the table in Section C.1.1 of the draft, what the status is of flag emoji tag sequences other than the three

Re: Unicode Emoji 5.0 characters now final

So it's up to the UTC to create this encoding: this new relase is a start for a new vexillology registry (within encoded sequences) which creates a new standard for them. 2017-03-27 23:50 GMT+02:00 Doug Ewell : > Philippe Verdy wrote: > > > We still lack an encoding standard

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 14:49, Michael Everson wrote: >> 3) Font features (e.g. 1855 vs. 1859) to select shapes in the same font > > Font trickery. Not portable. Not supported by most apps. I wouldn’t describe it as “trickery” or “not portable”. Features like stylistic

Re: Standaridized variation sequences for the Desert alphabet?

> On Mar 27, 2017, at 9:56 AM, John H. Jenkins wrote: > > >> On Mar 27, 2017, at 2:04 AM, James Kass > > wrote: >> >>> >>> If we have any historic metal types, are there >>> examples where a font contains both

Re: Unicode Emoji 5.0 characters now final

I try to summarize the situation for France, There are some missing codes France métropolitaine (deprecated: [fx]): Départements métropolitains: [fr01~19 fr2a~b fr21~68 fr70-95] (unchanged) [fr6d] Rhône (département) (missing, included in [fr69]?) Statuts

RE: Unicode Emoji 5.0 characters now final

Philippe Verdy wrote: > So it's up to the UTC to create this encoding: this new relase is a > start for a new vexillology registry (within encoded sequences) which > creates a new standard for them. Fine. If you think you can persuade UTC that this is within their scope, go ahead. Let us know

Re: Unicode Emoji 5.0 characters now final

Also these yellow statements from the initial proposal are contradicting what is now published in TR51: "UN" and "EU" are accepted even if they are "macroregions", not satisfying the quoted condition 2 in the proposed update. 2017-03-28 1:58 GMT+02:00 Philippe Verdy : > This

RE: Encoding of old compatibility characters

GROUP MARK Best Regards, Jonathan Rosenne -Original Message- From: Unicode [mailto:unicode-boun...@unicode.org] On Behalf Of Fr?d?ric Grosshans Sent: Tuesday, March 28, 2017 1:05 AM To: unicode Subject: Re: Encoding of old compatibility characters Another example, about to be encoded,

Re: Unicode Emoji 5.0 characters now final

On Mon, Mar 27, 2017 at 1:39 PM, Philippe Verdy wrote: > Note also that ISO3166-2 is far from being stable, and this could > contradict Unicode encoding stability: it would then be required to ensure > this stability by only allowing sequences that are effectively registered

Re: Unicode Emoji 5.0 characters now final

This only describes the sequences encoded with 2 characters, not the newer longer sequences for flags of subnational regions. the unicode_region_subtag data does not contain anything about the flags for the first 3 regions in GB. 2017-03-28 1:35 GMT+02:00 Markus Scherer : >

Re: Standaridized variation sequences for the Desert alphabet?

On Mon, Mar 27, 2017 at 1:34 AM Martin J. Dürst wrote: > The qualification 'minor' is less important for an alphabet. In general, > the more established and well-known an alphabet is, the wider the > variations of glyph shapes that may be tolerated. > My problem with

Re: Unicode Emoji 5.0 characters now final

Ken Whistler wrote: > By the way, if anybody is looking, Pomerania is there: "plpm" among > the 4925 other valid unicode_subdivision_id values. So: > > Flag of Pomerania = 1F3F4 E0070 E006C E0070 E006D E007F > > But alas, that is not a *valid* emoji tag sequence (yet), so no soup > for you! This

Re: Unicode Emoji 5.0 characters now final

On Mon, Mar 27, 2017 at 1:34 PM, Ken Whistler wrote: > Anybody could *attempt* to convey a flag of Pomerania (a rather handsome > black gryphon on a yellow background, btw) with an emoji tag sequence right > now, I suppose. I suppose not. Since it's bound to ISO 3166

Re: Unicode Emoji 5.0 characters now final

On Mon, Mar 27, 2017 at 4:58 PM, Philippe Verdy wrote: > This only describes the sequences encoded with 2 characters, not the newer > longer sequences for flags of subnational regions. the > unicode_region_subtag data does not contain anything about the flags for > the first

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 09:04, James Kass wrote: > John H. Jenkins mentioned early in this thread that these ligatures weren't > used in printed materials and were not part of the official Deseret set. > They were only used in manuscript. Not quite true. Such detail will

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 08:05, Martin J. Dürst wrote: >> Consider 2EBC ⺼ CJK RADICAL MEAT and 2E9D ⺝ CJK RADICAL MOON which are >> apparently really supposed to have identical glyphs, though we use an >> old-fashioned style in the charts for the former. (Yes, I am of course

Re: Unicode Emoji 5.0 characters now final

I followed the links. Check your links, you are referencing the proposal, and this contradicts the published version 4.0 of TR51. Where is stability ? 2017-03-28 2:06 GMT+02:00 Markus Scherer : > On Mon, Mar 27, 2017 at 4:58 PM, Philippe Verdy > wrote:

Re: Standaridized variation sequences for the Desert alphabet?

I’ll look into whatever you’re on about the other ‘minor’ script, but with regard to what you’ve said below, I’m fairly sure I encoded the missing characters there. I believe it was A7AE and A7B0, capital letters turned K and T used in that orthography. There is a problem with turned P and p in

Re: Encoding of old compatibility characters

On 03/27/2017 05:46 PM, Frédéric Grosshans wrote: An example of a legacy character successfully encoded recently is ⏨ U+23E8 DECIMAL EXPONENT SYMBOL, encoded in Unicode 5.2. It came from the Soviet standard GOST 10859-64 and the German standard ALCOR. And was proposed by Leo Broukhis in this

Re: Unicode Emoji 5.0 characters now final

On Mon, Mar 27, 2017 at 5:09 PM, Philippe Verdy wrote: > I followed the links. Check your links, you are referencing the proposal, > and this contradicts the published version 4.0 of TR51. Where is stability ? > Of course I am pointing to the proposal. The version of TR 51

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 09:29, Martin J. Dürst wrote: >> He is. He transcribes texts into Deseret. I’ve published three of them >> (Alice, Looking-Glass, and Snark). > > Great to know. Given that, I'd assume that you'd take his input a bit more > serious. I’m discussing it

Re: Standaridized variation sequences for the Desert alphabet?

On 27 Mar 2017, at 10:14, Julian Bradfield wrote: > > I contend, therefore, that no decision about Unicode should take into > account any ephemeral considerations such as this year's electronic > font technology, and that therefore it's not even useful to mention >

Re: different version of common/annotations/ja.xml

It would be combinations of Hiragana, Katakana, Kanji. On 03/28/17 02:25, Koji Ishii-san wrote: I think he meant Kanji/Han ideographic by "committed string". 2017-03-27 19:04 GMT+09:00 Takao Fujiwara >: On 03/27/17 18:48, Mark Davis ☕️-san