Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.text.misc > #47

Re: Unicode 15 (draft)

Show all headers | View raw

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).

Back to de.comp.text.misc | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Unicode 15 (draft) (was: Ein schoenes "D" gedreht ... - do not ignore) Marcel Logen <333200007110-0201@ybtra.de> - 2022-07-29 18:39 +0200
  Re: Unicode 15 (draft) Michael Bäuerle <michael.baeuerle@gmx.net> - 2022-07-30 07:26 +0000
    Re: Unicode 15 (draft) Marcel Logen <333200007110-0201@ybtra.de> - 2022-07-31 00:38 +0200
      Re: Unicode 15 (draft) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2022-08-01 11:23 +0200
        Re: Unicode 15 (draft) Marcel Logen <333200007110-0201@ybtra.de> - 2022-08-08 22:31 +0200
          Re: Unicode 15 (draft) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2022-08-10 11:13 +0200
            Re: Unicode 15 (draft) Marcel Logen <333200007110-0201@ybtra.de> - 2022-08-10 13:10 +0200
              Re: Unicode 15 (draft) Michael Bäuerle <michael.baeuerle@stz-e.de> - 2022-08-10 14:48 +0200
                Re: Unicode 15 (draft) Marcel Logen <333200007110-0201@ybtra.de> - 2022-08-10 17:35 +0200

csiph-web