Unicode 15 (draft) (was: Ein schoenes "D" gedreht ... - do not ignore)

[Marcel Logen]

Marcel Logen in de.test:

[UnicodeData.txt]
>BTW: Die Tabelle stammt von September 2021. Es sollte also
>vermutlich bald eine neue erscheinen.

Ich sehe gerade:

Es gibt schon einen Draft für Unicode 15.0.

<https://www.unicode.org/versions/Unicode15.0.0/>
<https://www.unicode.org/Public/15.0.0/> bzw.
<https://www.unicode.org/Public/15.0.0/ucd/>.

Marcel

f'up2 de.comp.text.misc
--
─╮ ╭───╮ ╭──╮ ╭─────╮ ╭─╮ ..67..
│ │ ╰────╮ │ ╰──╮ ╭──╮ ╭────╮ ..46..╰─╮ ╰─╮ │ ╰─╮
╰─╯ ╭───╯ ╭─╯ ╭──╯ │ ╰───╮ │ ╭─╯ ╭─╮ │ ╭──╯ │ │ ╭───
╰─────╯ ╰─────╯..27..╰─────╯ ╰─────╯ ╰───╯ ╰─────╯ ╰─╯

[Michael Bäuerle]

Marcel Logen wrote:
> Marcel Logen in de.test:
> >
> [UnicodeData.txt]
> > BTW: Die Tabelle stammt von September 2021. Es sollte also
> > vermutlich bald eine neue erscheinen.
>
> Ich sehe gerade:
>
> Es gibt schon einen Draft für Unicode 15.0.
>
> <https://www.unicode.org/versions/Unicode15.0.0/>
> <https://www.unicode.org/Public/15.0.0/> bzw.
> <https://www.unicode.org/Public/15.0.0/ucd/>.

Soll im September freigegeben werden, wenn ich das richtig sehe.

[Marcel Logen]

Michael Bäuerle in de.comp.text.misc:

>Marcel Logen wrote:

>> Es gibt schon einen Draft für Unicode 15.0.
>>
>> <https://www.unicode.org/versions/Unicode15.0.0/>
>> <https://www.unicode.org/Public/15.0.0/> bzw.
>> <https://www.unicode.org/Public/15.0.0/ucd/>.
>
>Soll im September freigegeben werden, wenn ich das richtig sehe.

Ich habe mir mal die neuen Emojis angeschaut:
<https://unicode.org/emoji/charts-15.0/emoji-released.html>.

Am besten davon gefällt mir das "wireless"-Zeichen
<https://unicode.org/emoji/charts-15.0/emoji-released.html#1f6dc>.

Mal sehen, was passiert, wenn ich das Zeichen hier
schon mal zu senden versuche (zusammen mit der Brezel):

🛜 U+1F6DC WIRELESS
🥨 U+1F968 PRETZEL

Marcel
--
╭──╮ ╭───╮ ..49..╭────╮ ╭─────╮
╭──╮ ╭────────╮ ╭────╯ ╰──╮ │ ╰─╮ ..45..╭─╮ │ ╰─╯ ╭──╯
╯ ╰─╯ ...9..│ ╰──╮ ╭───╯ │ ╰────╮ ╭─╮ ╭─╯ ╰─╯ ╭──────╯ ╭────
╰─────╯ ╰──────╯ ╰─╯ ╰─╯ ..52..╰─────────╯

[Michael Bäuerle]

Marcel Logen wrote:
> Michael Bäuerle in de.comp.text.misc:
> > Marcel Logen wrote:
> > >
> > > Es gibt schon einen Draft für Unicode 15.0.
> > >
> > > <https://www.unicode.org/versions/Unicode15.0.0/>
> > > <https://www.unicode.org/Public/15.0.0/> bzw.
> > > <https://www.unicode.org/Public/15.0.0/ucd/>.
> >
> > Soll im September freigegeben werden, wenn ich das richtig sehe.
>
> Ich habe mir mal die neuen Emojis angeschaut:
> <https://unicode.org/emoji/charts-15.0/emoji-released.html>.
>
> Am besten davon gefällt mir das "wireless"-Zeichen
> <https://unicode.org/emoji/charts-15.0/emoji-released.html#1f6dc>.
>
> Mal sehen, was passiert, wenn ich das Zeichen hier
> schon mal zu senden versuche (zusammen mit der Brezel):
>
> 🛜 U+1F6DC WIRELESS

Ergibt hier ein Replacement-Symbol (wie zu erwarten).

> 🥨 U+1F968 PRETZEL

Für die Brezel wurde eine Glyphe gefunden.

flnews zitiert unbelegte Unicode-Codepoints¹ ohne spezielle Behandlung.
In diesem Fall ist das kein Problem. Wäre aber z.B. ccc != 0 für
den neuen Codepoint definiert, dann könnte die Normalisierung gemäß
der neuen Norm falsch sein (falls auch eine canonical decomposition mit
einem anderen Codepoint definiert ist, d.h. ein Zusammenbau für die
Normalization Form C möglich ist).


______________
¹ Ein solcher liegt hier vor, bei Verwendung der Unicode 14 Datenbank

[Marcel Logen]

Michael Bäuerle in de.comp.text.misc:

>Marcel Logen wrote:

[ein Codepoint, der in Unicode 14 noch nicht vorhanden ist]

>> Mal sehen, was passiert, wenn ich das Zeichen hier
>> schon mal zu senden versuche (zusammen mit der Brezel):
>>
>> 🛜 U+1F6DC WIRELESS
>
>Ergibt hier ein Replacement-Symbol (wie zu erwarten).

Ich sehe hier eh nur Kästchen (auch bei der Brezel).

Ist das bei Dir "U+FFFD REPLACEMENT CHARACTER" oder auch ein
Kästchen?

(Von dem Kästchen BTW kenne ich den Codepoint nicht (wenn es über-
haupt einen dafür gibt).)

[...]

>flnews zitiert unbelegte Unicode-Codepoints¹ ohne spezielle Behandlung.

OK.

>In diesem Fall ist das kein Problem. Wäre aber z.B. ccc != 0 für
>den neuen Codepoint definiert, dann könnte die Normalisierung gemäß
>der neuen Norm falsch sein (falls auch eine canonical decomposition mit
>einem anderen Codepoint definiert ist, d.h. ein Zusammenbau für die
>Normalization Form C möglich ist).

Danke. An so etwas hatte ich natürlich nicht gedacht.

Marcel gkl4 (545444)
--
╭─────╮ ╭────╮ ╭─────────╮ ╭──╮ ╭─────╮ ╭──╮ ╭─╮ ╭─────
╰───╮ ╰──╯ │ ╰────╮ ╭─╯ ╭──╯ ╰─╮ ╰─╮ ╰─╯ ╰──╮ │ ╰───╯
─────╯ ╭──╯ ╭─╮ ╭─╯ │ ╭─╯ ╭───╯ ╭─╯ ╰─╯
╰──────╯ ╰─╯ ╰──╯ ╰──────╯ 3d50bc

[Michael Bäuerle]

Marcel Logen wrote:
> Michael Bäuerle in de.comp.text.misc:
> > Marcel Logen wrote:
> > >
> [ein Codepoint, der in Unicode 14 noch nicht vorhanden ist]
> > > Mal sehen, was passiert, wenn ich das Zeichen hier
> > > schon mal zu senden versuche (zusammen mit der Brezel):
> > >
> > > 🛜 U+1F6DC WIRELESS
> >
> > Ergibt hier ein Replacement-Symbol (wie zu erwarten).
>
> Ich sehe hier eh nur Kästchen (auch bei der Brezel).
>
> Ist das bei Dir "U+FFFD REPLACEMENT CHARACTER" oder auch ein
> Kästchen?

Es ist ein Kästchen mit "01F" und "6DC" drin. Das sieht mit anderen
Fonts dann ggf. wieder anders aus.

Also ein Ersatzsymbol für den richtigen Codepoint, nicht das allgemeine
Ersatzsymbol (U+FFFD enthält oft "?").

[Marcel Logen]

Michael Bäuerle in de.comp.text.misc:

>Marcel Logen wrote:
>> Michael Bäuerle in de.comp.text.misc:
>> > Marcel Logen wrote:

>> [ein Codepoint, der in Unicode 14 noch nicht vorhanden ist]
>> > > Mal sehen, was passiert, wenn ich das Zeichen hier
>> > > schon mal zu senden versuche (zusammen mit der Brezel):
>> > >
>> > > 🛜 U+1F6DC WIRELESS
>> >
>> > Ergibt hier ein Replacement-Symbol (wie zu erwarten).
>>
>> Ich sehe hier eh nur Kästchen (auch bei der Brezel).
>>
>> Ist das bei Dir "U+FFFD REPLACEMENT CHARACTER" oder auch ein
>> Kästchen?
>
>Es ist ein Kästchen mit "01F" und "6DC" drin. Das sieht mit anderen
>Fonts dann ggf. wieder anders aus.

Ah, ja. Das gibt es ja auch noch (sehe ich manchmal im Thunderbird
oder im Browser).

Hier in flnews hahe ich nur ein hochkant stehendes Kästchen ohne
irgend etwas darin.

Wenn ich dieses Kästchen aber aus dem flnews-Fenster herauskopiere,
dann wird die richtige Codepoint-Information dabei berücksichtigt.
Das *eine* Kästchen kann also für *verschiedene* Codepoints stehen.

Jetzt frage ich mich natürlich, ob dieses Kästchen auch einen ei-
genen Codepoint hat (oder wie dieses Verhalten erzeugt wird).

>Also ein Ersatzsymbol für den richtigen Codepoint, nicht das allgemeine
>Ersatzsymbol (U+FFFD enthält oft "?").

<https://www.fileformat.info/info/unicode/char/fffd/replacement_character.png>

Den REPLACEMENT CHARACTER kenne ich nur so. Ein weißes Frage-
zeichen in einer schwarzen Raute.

Marcel jsfa (651754)
--
╭────╮ ╭──╮ ╭───╮ ╭────╮ ╭───╮ ╭────╮
│ ╰────╯ ╰─╮ ╭─╮ ╰─╮ ╰─╮ │ ╭─╯ │ ╰─╮ ╭──╯ ╭─╯ ╭────────
╰───────╮ ╭───╯ │ ╰─╮ │ │ │ ╰───╯ ╰─╯ ╰─╮ ╭─╮ ╰─╮
╭────────╯ ╰─────╯ ╰──╯ ╰──╯ ╰──╯ ╰────╯a2fbf2

[Michael Bäuerle]

Marcel Logen wrote:
> Michael Bäuerle in de.comp.text.misc:
> > Marcel Logen wrote:
> > > Michael Bäuerle in de.comp.text.misc:
> > > > Marcel Logen wrote:
> > > > >
> > > [ein Codepoint, der in Unicode 14 noch nicht vorhanden ist]
> > > > > Mal sehen, was passiert, wenn ich das Zeichen hier
> > > > > schon mal zu senden versuche (zusammen mit der Brezel):
> > > > >
> > > > > 🛜 U+1F6DC WIRELESS
> > > >
> > > > Ergibt hier ein Replacement-Symbol (wie zu erwarten).
> > >
> > > Ich sehe hier eh nur Kästchen (auch bei der Brezel).
> > >
> > > Ist das bei Dir "U+FFFD REPLACEMENT CHARACTER" oder auch ein
> > > Kästchen?
> >
> > Es ist ein Kästchen mit "01F" und "6DC" drin. Das sieht mit anderen
> > Fonts dann ggf. wieder anders aus.
>
> Ah, ja. Das gibt es ja auch noch (sehe ich manchmal im Thunderbird
> oder im Browser).
>
> Hier in flnews hahe ich nur ein hochkant stehendes Kästchen ohne
> irgend etwas darin.
>
> Wenn ich dieses Kästchen aber aus dem flnews-Fenster herauskopiere,
> dann wird die richtige Codepoint-Information dabei berücksichtigt.

Du kopiert die Codepoints in die Zwischenablage, die flnews an FLTK
bzw. dessen Font-Renderer übergeben hat.

flnews kann mit U+1F6DC prinzipiell umgehen, ersetzt diesen Codepoint
also intern nicht mit U+FFFD (er würde sonst auch so zitiert werden,
da flnews keine separate Kodierung für die Anzeige erzeugt).

> Das *eine* Kästchen kann also für *verschiedene* Codepoints stehen.

Der Font-Renderer möchte normalerweise irgendwas anzeigen, wenn er
keine Glyphe im Font (bzw. den Fonts) findet.

Im Fall U+FFFD wäre das Fragezeichen im Kästchen die regulär zu
diesem Codepoint gehörende Glyphe (also nicht dieser Fall).

Bei U+1F6DC und fehlender Glyphe muss nicht unbedingt die Glyphe
für U+FFFD verwendet werden. Die Darstellung wie bei mir zeigt
einem zumindest die Codepoint-Nummer, das ist IMHO sinnvoller als
ein Fragezeichen oder ein leeres Kästchen.

> Jetzt frage ich mich natürlich, ob dieses Kästchen auch einen ei-
> genen Codepoint hat (oder wie dieses Verhalten erzeugt wird).

Irgendeinen Codepoint für "Kästchen" wird sich in der sechsstelligen
Anzahl von belegten Unicode-Codepoints sicher finden ;-)

Prinzipiell braucht dieses Symbol aber gar keinen Codepoint.
Es dient ja nur dem Font-Renderer intern als Ersatz-Glyphe.
Es könnte auch fest eincompiliert sein, oder intern erzeugt
(nicht aus einem Font geladen) werden.

> > Also ein Ersatzsymbol für den richtigen Codepoint, nicht das allgemeine
> > Ersatzsymbol (U+FFFD enthält oft "?").
>
> <https://www.fileformat.info/info/unicode/char/fffd/replacement_character.png>
>
> Den REPLACEMENT CHARACTER kenne ich nur so. Ein weißes Frage-
> zeichen in einer schwarzen Raute.

Das habe ich definitiv auch schon anders gesehen, z.B. um 45° gedreht.
(d.h. als Kästchen mit zwei Seiten parallel zur Zeile, das Fragezeichen
nicht mitgedreht).

[Marcel Logen]

Michael Bäuerle in de.comp.text.misc:

>Marcel Logen wrote:
>> Michael Bäuerle in de.comp.text.misc:
>> > Marcel Logen wrote:

[...]

>> > > Ist das bei Dir "U+FFFD REPLACEMENT CHARACTER" oder auch ein
>> > > Kästchen?
>> >
>> > Es ist ein Kästchen mit "01F" und "6DC" drin. Das sieht mit anderen
>> > Fonts dann ggf. wieder anders aus.
>>
>> Ah, ja. Das gibt es ja auch noch (sehe ich manchmal im Thunderbird
>> oder im Browser).
>>
>> Hier in flnews hahe ich nur ein hochkant stehendes Kästchen ohne
>> irgend etwas darin.
>>
>> Wenn ich dieses Kästchen aber aus dem flnews-Fenster herauskopiere,
>> dann wird die richtige Codepoint-Information dabei berücksichtigt.
>
>Du kopiert die Codepoints in die Zwischenablage, die flnews an FLTK
>bzw. dessen Font-Renderer übergeben hat.

Ja. Ich kann sie dann mit meinem Script weiterverarbeiten.

>flnews kann mit U+1F6DC prinzipiell umgehen, ersetzt diesen Codepoint
>also intern nicht mit U+FFFD (er würde sonst auch so zitiert werden,
>da flnews keine separate Kodierung für die Anzeige erzeugt).

OK, klar.

>> Das *eine* Kästchen kann also für *verschiedene* Codepoints stehen.
>
>Der Font-Renderer möchte normalerweise irgendwas anzeigen, wenn er
>keine Glyphe im Font (bzw. den Fonts) findet.
>
>Im Fall U+FFFD wäre das Fragezeichen im Kästchen die regulär zu
>diesem Codepoint gehörende Glyphe (also nicht dieser Fall).
>
>Bei U+1F6DC und fehlender Glyphe muss nicht unbedingt die Glyphe
>für U+FFFD verwendet werden. Die Darstellung wie bei mir zeigt
>einem zumindest die Codepoint-Nummer, das ist IMHO sinnvoller als
>ein Fragezeichen oder ein leeres Kästchen.

Das Problem dabei ist, daß die Codepoint-Nummer im Kästchen dann
immer extrem klein ist, so daß man sie eigentlich nicht lesen kann.

Deshalb bevorzuge ich da doch lieber das leere Kästchen. Vor al-
len Dingen hat das auch keine Überbreite.

>> Jetzt frage ich mich natürlich, ob dieses Kästchen auch einen ei-
>> genen Codepoint hat (oder wie dieses Verhalten erzeugt wird).
>
>Irgendeinen Codepoint für "Kästchen" wird sich in der sechsstelligen
>Anzahl von belegten Unicode-Codepoints sicher finden ;-)

U+25AF WHITE VERTICAL RECTANGLE kommt dem, was hier angezeigt
wird, schon mal recht nahe.

<https://www.fileformat.info/info/unicode/char/25af/white_vertical_rectangle.png>

>Prinzipiell braucht dieses Symbol aber gar keinen Codepoint.
>Es dient ja nur dem Font-Renderer intern als Ersatz-Glyphe.
>Es könnte auch fest eincompiliert sein, oder intern erzeugt
>(nicht aus einem Font geladen) werden.

Ja, das ist die Lösung.

>> > Also ein Ersatzsymbol für den richtigen Codepoint, nicht das allgemeine
>> > Ersatzsymbol (U+FFFD enthält oft "?").
>>
>> <https://www.fileformat.info/info/unicode/char/fffd/replacement_character.png>
>>
>> Den REPLACEMENT CHARACTER kenne ich nur so. Ein weißes Frage-
>> zeichen in einer schwarzen Raute.
>
>Das habe ich definitiv auch schon anders gesehen, z.B. um 45° gedreht.
>(d.h. als Kästchen mit zwei Seiten parallel zur Zeile, das Fragezeichen
>nicht mitgedreht).

Hm, ist mir IIRC noch nicht untergekommen; aber interessant. Danke.

Vielleicht habe ich aber schon mal das hier gesehen (aber ob als
REPLACEMENT CHARACTER, weiß ich jetzt nicht mehr): U+2370 [1],

<https://www.fileformat.info/info/unicode/char/2370/apl_functional_symbol_quad_question.png>

[1] Nach "APL" habe ich in der Wikipedia gesucht - und u. a. das
hier gefunden:

<https://en.wikipedia.org/wiki/Digital_encoding_of_APL_symbols>

U+2370 kommt da allerdings nicht vor.

Marcel jdr7 (636775)
--
╭────╮ ╭───╮ ╭─╮ ╭──────╮ ╭──╮ ╭─╮ ╭──╮
╭─╯ ╭─╯ │ ╰────╯ ╰──╮ ╰──╮ ╰──╮ │ ╰─╯ │ ╭──╯ ╰─
╯ ╭─╯ ╰──────╮ ╭───╯ ╭─╮ ╰───╮ ╰──────╮ ╭─╯ ╭───╯ ╰─╮
╰────────────╯ ╰─────╯ ╰────────────╯ efb5ca ╰─╯ ╰────────╯