From pgcon6 at msn.com  Wed Jul 19 02:12:38 2023
From: pgcon6 at msn.com (Peter Constable)
Date: Wed, 19 Jul 2023 07:12:38 +0000
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
Message-ID: <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>

Latin script is not used for only Latin. We shouldn?t get too hung up on the names.


Peter

From: Unicode <unicode-bounces at corp.unicode.org> on behalf of Kov?cs Viktor via Unicode <unicode at corp.unicode.org>
Date: Thursday, June 8, 2023 at 7:31 AM
To: unicode at corp.unicode.org <unicode at corp.unicode.org>
Subject: Old Hungarian closed e and naming of Old Hungarian standard


Dear members of Unicode comitte,

There are a problematic symbol form 10C8A (capital) and 10CCA (small) letters ?closed E?.

Critics start from the misconception that the sound of these letters is closed. Unfortunately, this interpretation has been included in the standard under the alias of the letter ?.
In the Rudimenta example texts (prayers) there are words that contain the closed form of the letter e, the reading of which is perfectly clear to native Hungarian readers.
I propose to add the alias "Rudimenta e with closed form" to the upper and lower case "closed e" at 10C8A and 10CCA.
The shape of these letters should not be changed.

If necessary, I will present a submission with pictures to prove my point.

In any form, the use of the adjective "Szekler-Hungarian rovas script" is incorrect, as it was not used only in Szeklerland.

It is also politically critical, as Szeklerland (or Sz?kelyland) is the easternmost part of Transylvania, Transylvania being part of Romania since 1919.

Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/1b439474/attachment.htm>

From kovacs.h.viktor at gmail.com  Wed Jul 19 02:38:37 2023
From: kovacs.h.viktor at gmail.com (kovacs.h.viktor)
Date: Wed, 19 Jul 2023 09:38:37 +0200
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
Message-ID: <604d609d-83ff-4371-92c1-41312316356d@edison>

  
  
  
Peter, I don't think that I understand, what you want to write in this message.
  

  

  

  
  
  
  
  
>   
> On 2023. j?l. 19. at 9:12, Peter Constable  <pgcon6 at msn.com>  wrote:
>   
>       
>   
>
> Latin script is not used for only Latin. We shouldn?t get too hung up on the names.
>
>   
>
>   
>
>   
>
>   
>
>   
>
> Peter
>
>   
>
>   
>
>   
>   
>   
>   
>
> From:   Unicode  <unicode-bounces at corp.unicode.org>  on behalf of Kov?cs Viktor via Unicode  <unicode at corp.unicode.org>
>   Date:  Thursday, June 8, 2023 at 7:31 AM
>   To:  unicode at corp.unicode.org  <unicode at corp.unicode.org>
>   Subject:  Old Hungarian closed e and naming of Old Hungarian standard
>
>   
>   
>   
>   
>
> Dear members of Unicode comitte,
>   
>   There are a problematic symbol form 10C8A (capital) and 10CCA (small) letters ?closed E?.
>   
>   Critics start from the misconception that the sound of these letters is closed. Unfortunately, this interpretation has been included in the standard under the alias of the letter ?.
>   In the Rudimenta example texts (prayers) there are words that contain the closed form of the letter e, the reading of which is perfectly clear to native Hungarian readers.
>   I propose to add the alias "Rudimenta e with closed form" to the upper and lower case "closed e" at 10C8A and 10CCA.
>   The shape of these letters should not be changed.
>   
>   If necessary, I will present a submission with pictures to prove my point.
>
>   
>
> In any form, the use of the adjective "Szekler-Hungarian rovas script" is incorrect, as it was not used only in Szeklerland.
>
>   
>
> It is also politically critical, as Szeklerland (or Sz?kelyland) is the easternmost part of Transylvania, Transylvania being part of Romania since 1919.
>
>   
>
> Thanks
>
>   
>   
>   
>   
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/2aa15001/attachment.htm>

From kovacs.h.viktor at gmail.com  Wed Jul 19 07:26:48 2023
From: kovacs.h.viktor at gmail.com (kovacs.h.viktor)
Date: Wed, 19 Jul 2023 14:26:48 +0200
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <CALSon-dMbeBaMVZ3VmPsOfVPNJTHKA31F+RMLq9PzWRGZ0F1XA@mail.gmail.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
References: <CALSon-dMbeBaMVZ3VmPsOfVPNJTHKA31F+RMLq9PzWRGZ0F1XA@mail.gmail.com>
 <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
Message-ID: <cf386533-f650-4e8e-bd68-4bf55b262211@edison>

  

  
  
Latin script is not used for only Latin, but Old Hungarian script is used only native-speakers of Hungarian language. The Szeklers (or: Sz?kelys) are only a small etnic group, who speak Hungarian language. The Old Hungarian script's finds were found, for example, in Highland, (today it is the Slovak Republic's area) and in Hungarian Republic.
  
Not I were, who asked "Sz?kely/Szekler-Hungarian" expression as required    preferred name alias for the Old Hungarian script.
  
In other words: this alias might to be ignored.
  
This debute must to be stoppoed now, I think.
  

  

  

  
  
  
  
>   
> On 2023. j?l. 19. at 9:47, Adam Bittlingmayer  <adam at modelfront.com>  wrote:
>   
>   
> He is saying that naming doesn't really matter, and gives an example.
>   
>   
>   
> On Wed, 19 Jul 2023 at 09:45, kovacs.h.viktor via Unicode  <unicode at corp.unicode.org>  wrote:
>   
> >   
> >   
> >   
> > Peter, I don't think that I understand, what you want to write in this message.
> >   
> >
> >   
> >
> >   
> >
> >   
> >   
> >   
> >   
> >   
> > >   
> > > On 2023. j?l. 19. at 9:12, Peter Constable  <pgcon6 at msn.com>  wrote:
> > >   
> > >   
> > >   
> > >
> > > Latin script is not used for only Latin. We shouldn?t get too hung up on the names.
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >
> > > Peter
> > >
> > >   
> > >
> > >   
> > >
> > >   
> > >   
> > >   
> > >   
> > >
> > > From:   Unicode  <unicode-bounces at corp.unicode.org>  on behalf of Kov?cs Viktor via Unicode  <unicode at corp.unicode.org>
> > >   Date:  Thursday, June 8, 2023 at 7:31 AM
> > >   To:   unicode at corp.unicode.org   <unicode at corp.unicode.org>
> > >   Subject:  Old Hungarian closed e and naming of Old Hungarian standard
> > >
> > >   
> > >   
> > >   
> > >   
> > >
> > > Dear members of Unicode comitte,
> > >   
> > >   There are a problematic symbol form 10C8A (capital) and 10CCA (small) letters ?closed E?.
> > >   
> > >   Critics start from the misconception that the sound of these letters is closed. Unfortunately, this interpretation has been included in the standard under the alias of the letter ?.
> > >   In the Rudimenta example texts (prayers) there are words that contain the closed form of the letter e, the reading of which is perfectly clear to native Hungarian readers.
> > >   I propose to add the alias "Rudimenta e with closed form" to the upper and lower case "closed e" at 10C8A and 10CCA.
> > >   The shape of these letters should not be changed.
> > >   
> > >   If necessary, I will present a submission with pictures to prove my point.
> > >
> > >   
> > >
> > > In any form, the use of the adjective "Szekler-Hungarian rovas script" is incorrect, as it was not used only in Szeklerland.
> > >
> > >   
> > >
> > > It is also politically critical, as Szeklerland (or Sz?kelyland) is the easternmost part of Transylvania, Transylvania being part of Romania since 1919.
> > >
> > >   
> > >
> > > Thanks
> > >
> > >   
> > >   
> > >   
> > >   
> >           
>   
>
>   --
>   
>   
>   
> Adam Bittlingmayer
>   
> CEO
>   
> ModelFront
>   
> Translation quality prediction
>   
>
>       
     
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/0e3e458a/attachment.htm>

From asmusf at ix.netcom.com  Wed Jul 19 08:57:18 2023
From: asmusf at ix.netcom.com (Asmus Freytag)
Date: Wed, 19 Jul 2023 06:57:18 -0700
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <604d609d-83ff-4371-92c1-41312316356d@edison>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
Message-ID: <dba7aff3-2e2a-f3f6-0769-398a4d3c397c@ix.netcom.com>

This Unicode list is for general discussions of people interested in 
Unicode. It is not a way to reach "Unicode members". There's a firm 
policy of not treating anything discussed here as "official" in any way.

That said, the list is often used to get an informal read on some issue. 
Not excluding getting an idea whether a proposal or suggestion has a 
chance of succeeding (and also, what is the best way to describe the issue).

As to the latter: very few people will know offhand whether 10C8A is 
already encoded, is in the process of being encoded or merely proposed. 
So it's always useful to provide that information in discussion or 
document submissions.

Character or normative script names can't be changed after the fact (and 
changes are also increasingly restricted in the latest stages of the 
process, to make sure things converge). And that's why, ultimately, 
names are not guaranteed to be "correct" from a linguistic perspective.

I find the original mail hard to parse, and have difficulties 
understanding what is being asked (and why). It seems to include adding 
an annotation, which is fine, but one that I find hard to understand. 
Phonetically, "closed" has a certain meaning and usually in character 
names, that's the meaning we would attribute to the term "closed". If, 
in this case, the term "closed" is based on something else, like a 
typographical feature, then an annotation that says that would be 
helpful. If that is not the issue, it would be just more evidence that 
the presentation of the issue is impenetrable.

As for describing the script. At some point, the formal name ends up not 
being perfect for some scripts. However, if the problem is in the 
discussion, or in an annotation in the nameslist, we are not constrained 
by stability concerns and should accommodate a more precise/more 
agreeable description. However, the original e-mail fails to make an 
actual suggestion for language, and fails to identify precisely where 
such language should be used.

An actual submission will have more success if it is clearer in all the 
aspects mentioned and separates proposed changes clearly from the 
background discussions / rationale.

A./


On 7/19/2023 12:38 AM, kovacs.h.viktor via Unicode wrote:
> Peter, I don't think that I understand, what you want to write in this 
> message.
>
>
>> On 2023. j?l. 19. at 9:12, Peter Constable <pgcon6 at msn.com> wrote:
>>
>> Latin script is not used for only Latin. We shouldn?t get too hung up 
>> on the names.
>>
>> Peter
>>
>> *From: *Unicode <unicode-bounces at corp.unicode.org> on behalf of 
>> Kov?cs Viktor via Unicode <unicode at corp.unicode.org>
>> *Date: *Thursday, June 8, 2023 at 7:31 AM
>> *To: *unicode at corp.unicode.org <unicode at corp.unicode.org>
>> *Subject: *Old Hungarian closed e and naming of Old Hungarian standard
>>
>> Dear members of Unicode comitte,
>>
>> There are a problematic symbol form 10C8A (capital) and 10CCA (small) 
>> letters ?closed E?.
>>
>> Critics start from the misconception that the sound of these letters 
>> is closed. Unfortunately, this interpretation has been included in 
>> the standard under the alias of the letter ?.
>> In the Rudimenta example texts (prayers) there are words that contain 
>> the closed form of the letter e, the reading of which is perfectly 
>> clear to native Hungarian readers.
>> I propose to add the alias "Rudimenta e with closed form" to the 
>> upper and lower case "closed e" at 10C8A and 10CCA.
>> The shape of these letters should not be changed.
>>
>> If necessary, I will present a submission with pictures to prove my 
>> point.
>>
>> In any form, the use of the adjective "Szekler-Hungarian rovas 
>> script" is incorrect, as it was not used only in Szeklerland.
>>
>> It is also politically critical, as Szeklerland (or Sz?kelyland) is 
>> the easternmost part of Transylvania, Transylvania being part of 
>> Romania since 1919.
>>
>> Thanks
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/df2e9b90/attachment.htm>

From kenwhistler at sonic.net  Wed Jul 19 11:17:24 2023
From: kenwhistler at sonic.net (Ken Whistler)
Date: Wed, 19 Jul 2023 09:17:24 -0700
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <dba7aff3-2e2a-f3f6-0769-398a4d3c397c@ix.netcom.com>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
 <dba7aff3-2e2a-f3f6-0769-398a4d3c397c@ix.netcom.com>
Message-ID: <8c249a43-6784-aff4-bbb9-b45959115e69@sonic.net>

Asmus,

In Unicode character naming, "CLOSED", when used with letter names, 
always refers to aspects of the shape of the typical glyph for the 
character. Example for the Latin script:

0277 LATIN SMALL LETTER *CLOSED *OMEGA

Other instances of this convention for the Latin script: 025E, 029A, 
A7D0, A7D1, 1078F, 107A4

Example for the Cyrillic script:

1658 CYRILLIC CAPITAL LETTER *CLOSED *LITTLE YUS

Other instances of this convention for the Cyrillic script: A659, A65C, A65D

The *only* used of "CLOSE" in the context of a /letter /name is for 
these two Old Hungarian letters:

10C8A OLD HUNGARIAN CAPITAL LETTER *CLOSE E*
10CCA OLD HUNGARIAN SMALL LETTER *CLOSE E*

In these instances (and *only* in these instances) "CLOSE E" refers to 
the close (or "high") mid front vowel, IPA [e], as distinct from the 
open (or "low") mid front vowel, IPA [?].

Note that the IPA distinction in vowel height is "close" versus "open", 
not "closed" versus "open":

https://en.wikipedia.org/wiki/Vowel#Height

The situation is confusing to some because standard Hungarian writes "e" 
for [?] and "?" for [e:], but there is also the convention, in dialect 
forms, to write "?" for [e], i.e., the short close-mid front vowel.

--Ken

On 7/19/2023 6:57 AM, Asmus Freytag via Unicode wrote:
> Phonetically, "closed" has a certain meaning and usually in character 
> names, that's the meaning we would attribute to the term "closed". If, 
> in this case, the term "closed" is based on something else, like a 
> typographical feature, then an annotation that says that would be 
> helpful. If that is not the issue, it would be just more evidence that 
> the presentation of the issue is impenetrable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/9f84a462/attachment.htm>

From asmusf at ix.netcom.com  Wed Jul 19 17:25:21 2023
From: asmusf at ix.netcom.com (Asmus Freytag)
Date: Wed, 19 Jul 2023 15:25:21 -0700
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <8c249a43-6784-aff4-bbb9-b45959115e69@sonic.net>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
 <dba7aff3-2e2a-f3f6-0769-398a4d3c397c@ix.netcom.com>
 <8c249a43-6784-aff4-bbb9-b45959115e69@sonic.net>
Message-ID: <a1532b31-cd81-bfe2-55cd-082ca12073c2@ix.netcom.com>

So, ample reason for an annotation, if things are that level confusing.
A./

On 7/19/2023 9:17 AM, Ken Whistler via Unicode wrote:
>
> Asmus,
>
> In Unicode character naming, "CLOSED", when used with letter names, 
> always refers to aspects of the shape of the typical glyph for the 
> character. Example for the Latin script:
>
> 0277 LATIN SMALL LETTER *CLOSED *OMEGA
>
> Other instances of this convention for the Latin script: 025E, 029A, 
> A7D0, A7D1, 1078F, 107A4
>
> Example for the Cyrillic script:
>
> 1658 CYRILLIC CAPITAL LETTER *CLOSED *LITTLE YUS
>
> Other instances of this convention for the Cyrillic script: A659, 
> A65C, A65D
>
> The *only* used of "CLOSE" in the context of a /letter /name is for 
> these two Old Hungarian letters:
>
> 10C8A OLD HUNGARIAN CAPITAL LETTER *CLOSE E*
> 10CCA OLD HUNGARIAN SMALL LETTER *CLOSE E*
>
> In these instances (and *only* in these instances) "CLOSE E" refers to 
> the close (or "high") mid front vowel, IPA [e], as distinct from the 
> open (or "low") mid front vowel, IPA [?].
>
> Note that the IPA distinction in vowel height is "close" versus 
> "open", not "closed" versus "open":
>
> https://en.wikipedia.org/wiki/Vowel#Height
>
> The situation is confusing to some because standard Hungarian writes 
> "e" for [?] and "?" for [e:], but there is also the convention, in 
> dialect forms, to write "?" for [e], i.e., the short close-mid front 
> vowel.
>
> --Ken
>
> On 7/19/2023 6:57 AM, Asmus Freytag via Unicode wrote:
>> Phonetically, "closed" has a certain meaning and usually in character 
>> names, that's the meaning we would attribute to the term "closed". 
>> If, in this case, the term "closed" is based on something else, like 
>> a typographical feature, then an annotation that says that would be 
>> helpful. If that is not the issue, it would be just more evidence 
>> that the presentation of the issue is impenetrable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/0b6f2b69/attachment.htm>

From kent.b.karlsson at bahnhof.se  Sun Jul 23 07:03:04 2023
From: kent.b.karlsson at bahnhof.se (Kent Karlsson)
Date: Sun, 23 Jul 2023 14:03:04 +0200
Subject: ECMA-48 (a.k.a. ISO/IEC 6429) "update" proposal update, plus "math
 anywhere" proposal update
References: <MM0P280MB0053E9F9FA74DC2E1CFDAA00ED3CA@MM0P280MB0053.SWEP280.PROD.OUTLOOK.COM>
Message-ID: <A1704F59-5C5E-49D7-A00B-17913C088EE4@bahnhof.se>


Hi!


Just a note about that I have updated two documents related to Unicode. I have posted about (earlier
versions of) them before.


?????????????????????????????

 
I have done some updates to my "proposed update" (I have actually no hope that the standard
itself will be updated) to ECMA-48 (ISO/IEC 6429) regarding text styling. You find them in
https://github.com/kent-karlsson/control/blob/main/ecma-48-style-modernisation-2023B.pdf <https://github.com/kent-karlsson/control/blob/main/ecma-48-style-modernisation-2023B.pdf>.
 
As I have mentioned before, ECMA-48 provides some styling mechanisms (more than you might
think) via so-called control sequences. They are designed to be what Unicode calls "default
ignorable", though they are character sequences, not singular characters, but they do start
with a "control" character.
 
Even though these styling (and a few structuring) mechansims are more powerful than first
meets the eye, it is noticable thet the standard (latest version) is more than 30 years old.
But it is still used, and indeed still useful. But in the "proposed update" I pick up some
additions done elsewhere, as well as add other styling "kinds" that are often found in modern
stylable text contexts, plus nailing down the semantics more tightly, like "exactly" (modulo
colour correction, which is out of scope) which colour is "blue", "green", etc. similar
to what is done in CSS.
 
The new version has been adapted to cater for some comments I got on an earlier version.
I hereby thank for those comments, without mentioning any particular names. For instance,
I have updated the text on bidi handling and how the Unicode bidi algorithm is tied in
(or not tied in in some cases). But there are many other updates since the last version,
most of them based on comments I got.
 
Some functionality:
                          - Bold, italic, underline, strike-through, font selection (from a small palette).
                          - Font size setting.
                          - Paragraph indents setting.
                          - "Bullet" (and numbered) lists (though the "bullet"/number character(s) must
                            be given explicitly as they are to be displayed, it is not automatic).
                          - Tab position setting (not new, of course).
                          - Tables, or actually table rows (though cell framing and background colour
                            must be given explicitly for each cell) (not new, though an improved PTX).
                          - Colours for text, background, and more.
                          - Text direction control (including (new) bidi setting; but otherwise not new).
                          - Page or table cell rotation (and that is not at all new).
 
It is not a full-fledged document formatting specification. Way too much functionality
is missing for that. But it does provide for a "middle ground" between "pure plain text"
and "full-fledged document formatting". There is a way to big gap between "pure plain
text" and a (high-end) document formatting system. As I may have mentioned earlier,
there is no need to try to invent something from scratch for putting something useful
in that gap. Instead ECMA-48 is a good and viable basis. Implementers can use the
specified functionalities as a sm?rg?sbord, from which to pick functionality that
the implementors, together with their clients, choose to support (as ECMA-48 always
has been, and like Unicode is today as well).
 
All of this of course bypasses the question whether ECMA-48 control sequences were
ever intended to be used for styled text document storage. Perhaps they were not,
but that is moot, especially now when we have "graphical" text editors that manage
the file storage representation in the background.
 
I think Unicode/10646 have treated ECMA-48/ISO6429 waaaay too step-motherly, a
treatment it does not deserve.
 
(I think also the keyboard input part of ECMA-48 also needs a bit of updating, but
that will be the subject of another, separate, proposal. But I only have a draft so far,
si I?m to giving a link here.)
 
 
 
????????????????????
 
 
 
I have also updated the math expression representations proposals. You find them in
https://github.com/kent-karlsson/control/blob/main/math-layout-controls-2023-B.pdf <https://github.com/kent-karlsson/control/blob/main/math-layout-controls-2023-B.pdf>.
The updates from the last version here are smaller. Mainly that I have integrated the
mirroring pair data for arrows (and more) in an appendix (since I don't yet see any
progress  in including that data file in the Unicode database, which I have proposed).
 
Note that the math expression representation proposals are separate from the ECMA-48
update proposal, even though one of the three variants is compatible with ECMA-48.
 
The three different representations (1. compatible with control codes, using SCI
control sequences; 2. compatible with HTML/SVG, and maybe other XML based schemes;
3. markdown style) are fully interequivalent. (No claim of equivalence to other
math expression representations.)
 
They also:
                          - are the only math expression represntations I know of that handle combining
                            characters correctly,
                          - are almost the only math expression represntations I know of that I am sure,
                            handle multiletter variables correctly (TeX has \mathit{...} for handling
                            multiletter variables),
                          - are the only math expression representations I know of that handle bidi for
                            math expressions correctly and reliably, including handling arrows in math
                            expression and (explicit) mirroring of (potential math) symbols that have
                            no mirror character allocated,
                          - avoid the verbosity of MathML and OMML, but still has an HTML/SVG 
                            compatible variant representation type,
                          - forbid the use of "MATHEMATICAL" characters, which were a bad idea from 
                            the very beginning; these formats have a more general and more flexible 
                            mechanism for math style for letters/digits, and that mechanism is 
                            incompatible with"MATHEMATICAL" characters,
                          - are simple and straightforward representations.
 
As for which letters/digits/symbols to support (and for which math styles), that is up to
implementers and their clients. But one would expect at least A-Z, a-z to be supported for
most styles, 0-9 and common Greek letters (and two Hebrew letters) for some styles, plus
common math symbols (selected subset of Sm union So).
 
These math expression representations fits for anything from pure plain text to
ECMA-48 styled text to HTML and various document formats, including having math
expressions in graphs/diagrams (HP-GL, SVG, ...).
 
I don't have a catchy name for these math expression representations. I realise that
that is a flaw in marketing... "KISS-math"? (https://en.wikipedia.org/wiki/KISS_principle <https://en.wikipedia.org/wiki/KISS_principle>),
with my preferred reading: "keep it small and simple" (which is the design principle,
despite the more than 70 pages). The design is simple, and the math expression 
representations are small (compared to several other proposals). I would also say it
is ?straightforward" (but "KISSS", naa).
 
 

??????????????????????


/Kent K

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230723/bc8d4b1c/attachment.htm>

From adam at modelfront.com  Wed Jul 19 02:47:44 2023
From: adam at modelfront.com (Adam Bittlingmayer)
Date: Wed, 19 Jul 2023 07:47:44 -0000
Subject: Old Hungarian closed e and naming of Old Hungarian standard
In-Reply-To: <604d609d-83ff-4371-92c1-41312316356d@edison>
References: <93ca910c-a924-3ba9-04af-31f51ff4ff09@gmail.com>
 <DS0PR12MB7535EAE0493F68DEAAFD31AE8639A@DS0PR12MB7535.namprd12.prod.outlook.com>
 <604d609d-83ff-4371-92c1-41312316356d@edison>
Message-ID: <CALSon-dMbeBaMVZ3VmPsOfVPNJTHKA31F+RMLq9PzWRGZ0F1XA@mail.gmail.com>

He is saying that naming doesn't really matter, and gives an example.

On Wed, 19 Jul 2023 at 09:45, kovacs.h.viktor via Unicode <
unicode at corp.unicode.org> wrote:

> Peter, I don't think that I understand, what you want to write in this
> message.
>
>
> On 2023. j?l. 19. at 9:12, Peter Constable <pgcon6 at msn.com> wrote:
>
> Latin script is not used for only Latin. We shouldn?t get too hung up on
> the names.
>
>
>
>
>
> Peter
>
>
>
> *From: *Unicode <unicode-bounces at corp.unicode.org> on behalf of Kov?cs
> Viktor via Unicode <unicode at corp.unicode.org>
> *Date: *Thursday, June 8, 2023 at 7:31 AM
> *To: *unicode at corp.unicode.org <unicode at corp.unicode.org>
> *Subject: *Old Hungarian closed e and naming of Old Hungarian standard
>
>
>
> Dear members of Unicode comitte,
>
> There are a problematic symbol form 10C8A (capital) and 10CCA (small)
> letters ?closed E?.
>
> Critics start from the misconception that the sound of these letters is
> closed. Unfortunately, this interpretation has been included in the
> standard under the alias of the letter ?.
> In the Rudimenta example texts (prayers) there are words that contain the
> closed form of the letter e, the reading of which is perfectly clear to
> native Hungarian readers.
> I propose to add the alias "Rudimenta e with closed form" to the upper and
> lower case "closed e" at 10C8A and 10CCA.
> The shape of these letters should not be changed.
>
> If necessary, I will present a submission with pictures to prove my point.
>
> In any form, the use of the adjective "Szekler-Hungarian rovas script" is
> incorrect, as it was not used only in Szeklerland.
>
> It is also politically critical, as Szeklerland (or Sz?kelyland) is the
> easternmost part of Transylvania, Transylvania being part of Romania since
> 1919.
>
> Thanks
>
>

-- 
Adam Bittlingmayer
CEO
*ModelFront*
Translation quality prediction
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://corp.unicode.org/pipermail/unicode/attachments/20230719/1f94c849/attachment.htm>