Re: Encoding of old compatibility characters

I have got MS Word 2002 and MS Excel 2000. Maybe, later versions bring an amended version of Arial Unicode MS. Maybe. A./

Re: Encoding of old compatibility characters

Helo, Am 31.03.2017 um 09:57 schrieb Eli Zaretskii: Arial Unicode MS supports that character [U+23E8], FWIW. From: Otto Stolz Date: Tue, 4 Apr 2017 15:21:02 +0200 Not on my good ole Wndows XP SP3 system. On 4/4/2017 7:58 AM, Eli Zaretskii wrote: This here is

Re: Encoding of old compatibility characters

On 4/4/2017 7:58 AM, Eli Zaretskii wrote: From: Otto Stolz Date: Tue, 4 Apr 2017 15:21:02 +0200 Am 31.03.2017 um 09:57 schrieb Eli Zaretskii: Arial Unicode MS supports that character [U+23E8], FWIW.

Re: Encoding of old compatibility characters

> From: Otto Stolz > Date: Tue, 4 Apr 2017 15:21:02 +0200 > > Am 31.03.2017 um 09:57 schrieb Eli Zaretskii: > > Arial Unicode MS supports that character [U+23E8], FWIW. > > Not on my good ole Wndows XP SP3 system. This here is also XP SP3. Maybe some package I have

Re: Encoding of old compatibility characters

Am 31.03.2017 um 09:57 schrieb Eli Zaretskii: Arial Unicode MS supports that character [U+23E8], FWIW. Not on my good ole Wndows XP SP3 system. Best wishes, Otto

Re: Encoding of old compatibility characters

Probably you've installed the Noto collection on your Windows XP, or installed some software that added fonts to the system (pmossibly with updates to the Uniscribe library, suc has an old version of Office). Anyway I would no longer trust XP for doing correct rendering for many scripts, even with

Re: Encoding of old compatibility characters

On 2017.03.29 05:41, Leo Broukhis asked: Are you still using Windows 7 or RedHat 5, or something equally old? Newer systems have ⏨ out of the box. I’m using Windows XP and "⏨" renders perfectly as "₁₀". Maybe fonts can be installed without “upgrading” the whole operating system? Who knew?!

Re: Encoding of old compatibility characters

On Tue, Mar 28, 2017 at 6:09 AM, Asmus Freytag wrote: > On 3/28/2017 4:00 AM, Ian Clifton wrote: > > I’ve used ⏨ a couple of times, without explanation, in my own > emails—without, as far as I’m aware, causing any misunderstanding. > > Works especially well, whenever it

Re: Encoding of old compatibility characters

On 03/28/2017 09:09 AM, Asmus Freytag wrote: On 3/28/2017 4:00 AM, Ian Clifton wrote: I’ve used ⏨ a couple of times, without explanation, in my own emails—without, as far as I’m aware, causing any misunderstanding. Works especially well, whenever it renders as a box with 23E8 inscribed! A./

Re: Encoding of old compatibility characters

I don't think I want my text renderer to be *that* smart. If I want ⏨, I'll put ⏨. If I want a multiplication sign or something, I'll put that. Without the multiplication sign, it's still quite understandable, more so than just "e". It is valid for a text rendering engine to render "g"

Re: Encoding of old compatibility characters

On 3/28/2017 4:00 AM, Ian Clifton wrote: I’ve used ⏨ a couple of times, without explanation, in my own emails—without, as far as I’m aware, causing any misunderstanding. Works especially well, whenever it renders as a box with 23E8 inscribed!

Re: Encoding of old compatibility characters

Philippe Verdy writes: > Ideally a smart text renderer could as well display that glyph with a > leading multiplication sign (a mathematical middle dot) and implicitly > convert the following digits (and sign) as real superscript/exponent > (using contextual

Re: Encoding of old compatibility characters

Ideally a smart text renderer could as well display that glyph with a leading multiplication sign (a mathematical middle dot) and implicitly convert the following digits (and sign) as real superscript/exponent (using contextual substitution/positioning like for Eastern Arabic/Urdu), without

Re: Encoding of old compatibility characters

Le 28/03/2017 à 02:22, Mark E. Shoulson a écrit : Aw, but ⏨ is awesome! It's much cooler-looking and more visually understandable than "e" for exponent notation. In some code I've been playing around with I support it as a valid alternative to "e". I Agree 1⏨3 times with you on this !

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: 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: 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: 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: 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: 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 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 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: 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

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

> 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: 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