Unicode, UTF8 und Multiybyte - etwas verwirrt.

.filmor

Pedobear schrieb:

UTF-32 (basic_string<uint32_t>) zum bearbeiten von Unicode, da man dann keine Probleme mit variabler Zeichenbreite hat.

Hehe. Was ein frommer Traum. Aber den musst du leider begraben (es sei denn, du treibst dich ausschließlich im 8859-Gebiet rum und brauchst deshalb sowieso kein Unicode ;)). http://en.wikipedia.org/wiki/Unicode_normalization

Gibt es eigentlich eine Library die mir einen Unicode String in ein bitmap* rendert?

* Nicht als Datei sondern im Speicher z.B. als struct bitmap { int width, height; char *data };

akari

Hallo

Ja jede beliebige Grafikbibliothek mit einer Text-Funktion. Zum Beispiel die WinAPI kann mit DrawText in ein temporäres HBITMAP zeichnen.

bis bald
akari

Damit man nicht an eine bestimmte Grafiklibrary gebunden ist empfehle ich eine reine Text-Render-Library wie FreeType zu verwenden.
Ich weiß allerdings nicht, ob FreeType mit zusammengesetzten Symbolen zurecht kommt. Weiß da jemand genaueres?

rüdiger

Pedobear schrieb:

Die sind für leagcy Programme gedacht, die noch mit alten Codierungen umgehen müssen. Nichts, was man in modernen Programmen verwenden sollte..

Nenne bitte eine Quelle. Ich halte deine Aussagen so einfach für totalen Blödsinn.

Interessierte schrieb:

Gibt es eigentlich eine Library die mir einen Unicode String in ein bitmap* rendert?

Freetype2 und ansonsten so gut wie jeder aktuelle Fontrenderer.

Artchi

Pedobear! Deine Meinung ist ziemlich irrelevant. Wenn etwas deprecated ist, dann hat das nur und nur alleine die ISO-C++-Norm zu bestimmen. Ob dir wchar_t persönlich gefällt oder missfällt, interessiert nicht die Bohne.

wchar_t ist jedenfalls nicht deprecated. Kann auch garnicht gehen, da es seit 1998 keinen neuen Standard gab (nur 2003 eine Korrektur).

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Meister "ich weiß alles" weiß wohl doch nicht alles und beendet deshalb mal lieber die Diskussion...

akari

Hallo

Pedobear schrieb:

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Ja was für eine Frechheit von den Entwicklern von wxWidgets. Bauen die doch ihre String-Klasse im Unicode-Modus auf wchar_t auf und behaupten dann das wäre portabel!

bis bald
akari

akari schrieb:

Hallo

Pedobear schrieb:

Es halt auch eine Frage des guten Stils, was man verwendet. Und wchar_t und Konsorten sind eher keine guter Stil. Aber macht es meinetwegen, wie ihr wollt. Kommt dann aber hinterher nicht angerannt, euer Programm sei nicht portabel.

Sinnlose Diskussion beendet**.**

Ja was für eine Frechheit von den Entwicklern von wxWidgets. Bauen die doch ihre String-Klasse im Unicode-Modus auf wchar_t auf und behaupten dann das wäre portabel!

bis bald
akari

lol, die verwenden nur die ersten 16 bits des wchar_t woduch auf zb linux (sizeof(wchar_t)=4) die hälfte des speichers verschwendet wird..

Artchi schrieb:

Deine Meinung ist ziemlich irrelevant.

lol, du meinst sie is für dich irrelevant. wenns dich net interessiert poste hat nich..

akari

Hallo

wxer schrieb:

lol, die verwenden nur die ersten 16 bits des wchar_t woduch auf zb linux (sizeof(wchar_t)=4) die hälfte des speichers verschwendet wird..

Dafür werden die Entwickler schon ihre Gründe haben. Zum Beispiel wchar_t genau das ist was ihren Zweck entspricht. Vermutlich verwendest du auch keinen bool-Typ, sondern arbeitest immer brav mit Bitoperationen um ja auch kein Bit zu verschwenden?

Aber trotzdem hast du uns noch immer keinen Grund genannt warum wchar_t veraltet und nicht portabel sei.
Portabilität bedeutet nun mal nicht das auf jedem System ein eigenes Süppchen gekocht wird, sondern das für alle System ein gemeinsamer Standard definiert wird. Was soll ich mit deiner Lösung wenn alle Betriebsystemfunktionen einen wchar_t*-Äquivalent erfordern?

bis bald
akari

.filmor

Hmm. Ein wenig Recht hat er ja schon. wchar_t ist nicht überall gleich groß und das ist nunmal nicht so praktisch für die Portabilität. Und bei Encodings ist es nunmal sinnvoll, /genau/ zu wissen, wie groß die Einheiten sind.
Bei char kann man sich zumindest auf vernünftigen Systemen darauf verlassen, dass es genau 8 Bit groß ist und somit wunderbar UTF-8 schlucken kann (und wxWidgets bietet das afaik auch für die nächste Version an).

Artchi

Lest doch mal was er geschrieben hat: wchar_t soll deprecated sein. Hallo??? Ob etwas deprecated ist, kann nur das C++-Komitee bestimmen und nicht er. Ob ihm der Typ wchar_t gefällt oder nicht, kann er gerne kund tun und meinet wegen eine Empfehlung aussprechen. Aber er kann nicht einfach behaupten, das wchar_t deprecated ist. Nachher kommt der nächste, und sagt std::wstring ist deprecated. Das wäre nämlich die logische Folge.

So, zum wchar_t: dieser Typ ist wie alle anderen C++-Typen, wie int, short und long, auf jeder Plattform oder Compiler potenziell nicht gleich groß. Und nu? Soll ich jetzt kein int mehr benutzen? Natürlich nicht! Ich benutze int, weil es mir erstmal generell auf groß genug ist. Auch wenn es auf einer anderen Plattform o. Compiler vielleicht doch 64 bit groß sein könnte.

Genau das gleiche für wchar_t, es ist erstmal generell groß genug. Und? Dann ist es halt unter GCC und Mingw 32 bit breit. Wenn eine Umcodierung stattfindet, muß und wird eine vernünftige Umcodierungs-Funktion die Breite von wchar_t beachten.

Und dann noch etwas: unter Java 1.4 ist ein String UTF-16 und ab Java 1.5 UTF-32 breit. Hem... jetzt möchte ich mal in einem Java-Forum die Diskussion erleben, das von java.lang.String in Java 1.5 abgeraten wird, weil die Strings zu viel Speicher verbraten. Da wird so ebend mal von einer Java-Version auf die nächste die Bitbreite eines Zeichens im String verdoppelt.

Übrigen, auch MacOS X benutzt intern wchar_t in 32 bit. Keiner würde auf die Idee kommen, und Apple anschreiben und denen empfehlen, von wchar_t abzukehren.

Hier gibts mal wieder ein paar Bit-Schubser, die von der Abstraktionsebene auf die Low-Level-Ebene krieschen und von deprecated reden, obwohl die wichtigsten Plattformen auf diesem Planeten (Win32, Apples Darvin und sicherlich ein paar andere Unixe) auf wchar_t setzen. C++ hält sich im Grunde genommen nur an den C-Standard bzgl. Zeichensystem. Und natürlich machen die alles falsch.

Artchi

.filmor schrieb:

Hmm. Ein wenig Recht hat er ja schon. wchar_t ist nicht überall gleich groß und das ist nunmal nicht so praktisch für die Portabilität. Und bei Encodings ist es nunmal sinnvoll, /genau/ zu wissen, wie groß die Einheiten sind.

Und das kann man nicht programmatisch, evtl. sogar schon mit Templates (und somit ohne Performanceverlust für eine Prüfung), feststellen? Natürlich kann man das. Im einfachsten Fall knallt man ein sizeof() rein.

Bei char kann man sich zumindest auf vernünftigen Systemen darauf verlassen, dass es genau 8 Bit groß ist und somit wunderbar UTF-8 schlucken kann (und wxWidgets bietet das afaik auch für die nächste Version an).

Öhm, aber char ist auch nicht auf jeder Plattform/Compiler gleich. Ganz im Gegenteil: char kann sogar signed sein!
Übrigens ist UTF-8 zwar für Latin-Locales speichersparend, aber dafür langsamer im Gegensatz zu festen Breiten. Und nur weil wxWidgets auf UTF-8 zur Runtime umsteigt, muß das nicht heißen, das es die goldene Lösung ist. Es ist lediglich eine Designentscheidung von vielen möglichen.

Artchi schrieb:

Ganz im Gegenteil: char kann sogar signed sein!

'char' ist sogar meistens signed. aber obwohl 'char' eigentlich nur den 7-bit ascii-zeichensatz speichern können muss, ist CHAR_BIT nie kleiner als 8 (weil z.b. SCHAR_MIN mindestens -127 und SCHAR_MAX mindestens +127 sein müssen, und für -127..+127 braucht man nun mal 8 bits).

.filmor

Artchi schrieb:

Lest doch mal was er geschrieben hat: wchar_t soll deprecated sein. Hallo??? Ob etwas deprecated ist, kann nur das C++-Komitee bestimmen und nicht er.

Nun häng dich doch nicht so an dem einen Formulierungsfehler auf …

Artchi schrieb:

So, zum wchar_t: dieser Typ ist wie alle anderen C++-Typen, wie int, short und long, auf jeder Plattform oder Compiler potenziell nicht gleich groß. Und nu? Soll ich jetzt kein int mehr benutzen? Natürlich nicht! Ich benutze int, weil es mir erstmal generell auf groß genug ist.

Das hat doch nun wirklich wenig miteinander zu tun. Die Kodierung von Ganzzahlen ist fast immer 2er-Komplement. Man muss sich höchstens mal mit Endianness auseinandersetzen, aber da ist das Muster auch recht klar.

Artchi schrieb:

Und dann noch etwas: unter Java 1.4 ist ein String UTF-16 und ab Java 1.5 UTF-32 breit. Hem... jetzt möchte ich mal in einem Java-Forum die Diskussion erleben, das von java.lang.String in Java 1.5 abgeraten wird, weil die Strings zu viel Speicher verbraten. Da wird so ebend mal von einer Java-Version auf die nächste die Bitbreite eines Zeichens im String verdoppelt.

Was interessiert hier denn Java? Dort ist ein String überall gleich dargestellt, von daher interessierts mich überhaupt nicht, wie viel das gerade ist (auch wenn ich UTF-32 generell für Unsinn halte, wenns nicht gerade um Spezialaufgaben geht).

Artchi schrieb:

Übrigen, auch MacOS X benutzt intern wchar_t in 32 bit. Keiner würde auf die Idee kommen, und Apple anschreiben und denen empfehlen, von wchar_t abzukehren.

Die Apfelmännchen können in ihrer eigenen Umgebung (vor allem bestimmt durch die eigene libc und die Betriebssystemfunktionen) doch Tun und Lassen, was sie wollen. Sie wissen ja, dass sich ihre eigenen Programme untereinander verstehen.

Nochmal, die Größe von wchar_t ist völlig irrelevant. Allein die Tatsache, dass zwei nicht trivial ineinander überführbare Kodierungen(!) verwendet werden, namentlich UTF-16 und UTF-32, macht das plattformübergreifende Einsetzen von wchar_t zumindest problematischer als es sein sollte. Davon ist selbstverständlich das interne Arbeiten nicht betroffen, aber ab und zu muss ein Programm sich auch sozial betätigen. Und dabei musst du genau wissen, was du sagst oder hören wirst (was bei Integern nun wirklich kaum ein Problem ist).

Artchi schrieb:

Öhm, aber char ist auch nicht auf jeder Plattform/Compiler gleich. Ganz im Gegenteil: char kann sogar signed sein!

Und? Hier kams mir auf die Größe an. Und direkt kann man bei UTF-8 sowieso nur mit Zahlen <0x80 rumspielen und die haben bei signed und unsigned die selbe Darstellung. Zumindest auf allen mir bekannten Systemen.

Artchi schrieb:

Übrigens ist UTF-8 zwar für Latin-Locales speichersparend, aber dafür langsamer im Gegensatz zu festen Breiten.

Wie kommst du darauf? Auch bei UTF-32 ist die Rechnung „eine Einheit entspricht einem Glyph“ schlichtweg falsch (guckstu den Link, den ich oben mal gepostet habe). Damit ist der Vorteil für Längenbestimmung und Direktzugriff schon mal futsch. Hast du noch einen?

Das mit der variablen Breite eines Glyphs ist irgendwie nicht so schön. Ich mein bei 32Bit (über 4Mrd Werte) hätte man doch auch jeder Kombination von Buchstabe und Anhängsel einen eigenen code point geben können, oder?
Naja, leider ist dem nicht so, deshalb meine Frage: Gibt es eine Unicode string Klasse, die auf der Basis von Glyphs arbeitet? Also: str[5] = 5. Glyph.

.filmor

Optimist schrieb:

Das mit der variablen Breite eines Glyphs ist irgendwie nicht so schön. Ich mein bei 32Bit (über 4Mrd Werte) hätte man doch auch jeder Kombination von Buchstabe und Anhängsel einen eigenen code point geben können, oder?

Es sind nur Dank des glorreichen UTF-16 keine 4 Milliarden sondern nur etwas über 1,1 Millionen. Und da wirds mit allen Kombinationen von Buchstaben und deren Dekorationen vielleicht doch etwas knapper. Es würde aber wohl auch das entwickeln von Schriften ungleich komplizierter machen, denke ich.

Optimist schrieb:

Naja, leider ist dem nicht so, deshalb meine Frage: Gibt es eine Unicode string Klasse, die auf der Basis von Glyphs arbeitet? Also: str[5] = 5. Glyph.

Nicht, dass ich wüsste. Aber wieso sollte man das wollen? Mir fällt auf Anhieb kein Fall ein, in dem man wahlfreien Zugriff auf ein Glyph bräuchte.

mathik

Artchi schrieb:

Und dann noch etwas: unter Java 1.4 ist ein String UTF-16 und ab Java 1.5 UTF-32 breit. Hem... jetzt möchte ich mal in einem Java-Forum die Diskussion erleben, das von java.lang.String in Java 1.5 abgeraten wird, weil die Strings zu viel Speicher verbraten. Da wird so ebend mal von einer Java-Version auf die nächste die Bitbreite eines Zeichens im String verdoppelt.

woher hast du das denn?
In Java 1.5 ist ein char immer noch 16-Bit breit....