FPC Unicode support

[mschnell]

Ob die Probleme beim ersten 'ä' oder erst beim Entwickeln komplexer Programme zur Editierung und rendern von Unicode Textdateien auftreten, ist meiner Meinung nach ein Unterschied.

Das sehe ich auch so.

Komplexere Anforderungen benötigen natürlich komplexere Lösungen. Ein Programmiersystem, dass den Anspruch erhebt, für komplexere Probleme geeignet zu sein, benötigt dafür die nicht nur die entsprechenden Möglichkeiten sondern auch die entsprechende Doku (Hilfe, etc.)

Ein Programmiersystem, dass den Anspruch erhebt, für Einsteiger geeignet zu sein, benötigt die Fähigkeit für die typische Einsteiger-Aufgaben intuitive Lösungswege anzubieten und keine Fallen aufzustellen.

Basic ist mehr so tot, Java-Script will hauptsächlich einfache Anforderungen, C++ oder SQL ist wohl mehr was für Profis.

Java und Python will beides, Performance ist aber eher nachranging.

Alle Object-Pascal Produkte (Delphi, Lazarus, mse) wollen beides sein, und dabei auch noch gute Performance und (momentan nur bei den FPC-basierten) Portierbarkeit bieten. (Und damit ist die Lebensberechtigung für diese Produkte bewiesen.)

Die nicht-Unicode-Varianten von Delphi und Lazarus waren da sehr gut.

Unicode-Delphi auf Windows ist in dieser Hinsicht nicht allzu schlecht (aber: siehe oben). Die momentane Lazarus-Version fällt da meiner Ansicht nach sehr ab (Beispiel siehe oben) ('mal sehen, ob sich da bis Version 1.x noch was tut).

Auch der Einwand von Marcov bezieht sich auf komplexere Probleme,die - natürlich - die entsprechend komplexe Beschäftigung mit dem Thema benötigen. Trotzdem finde ich es nicht einsehbar, wenn simple Sachen einfach mehr mit den ursprünglich dokumentierten einfachen Methoden lösbar sind, nur weil nach einem Update das Programmiersystem auf einmal Unicode-Texte bearbeiten kann. Es sollte also - wenn das wirklich nicht anders geht - defaultmäßig eben nicht mit Unicode arbeiten und für Anwendungen, die Unicode benötigen, zusätzlich die entsprechenden Möglichkeiten zur Verfügung stellen. Wenn daraus eine Performance-Einschränkung resultiert (z.B. weil die Betirebssystem-API Unicode erwartet) ist das - finde ich - nicht schlimm. High-Performance-Anwendungen fallen - nach meiner Definition - unter die Kategorie "komplex" und brauchen eben mehr Gehirnschmalz zur Optimierung.

-Michael

[mschnell]

./,

[mschnell]

Ob die Probleme beim ersten 'ä' oder erst beim Entwickeln komplexer Programme zur Editierung und rendern von Unicode Textdateien auftreten, ist meiner Meinung nach ein Unterschied.

Das sehe ich auch so.

Komplexere Anforderungen benötigen natürlich komplexere Lösungen. Ein Programmiersystem, dass den Anspruch erhebt, für komplexere Probleme geeignet zu sein, benötigt dafür die nicht nur die entsprechenden Möglichkeiten sondern auch die entsprechende Doku (Hilfe, etc.)

Ein Programmiersystem, dass den Anspruch erhebt, für Einsteiger geeignet zu sein, benötigt die Fähigkeit für die typische Einsteiger-Aufgaben intuitive Lösungswege anzubieten und keine Fallen aufzustellen.

Basic ist mehr so tot, Java-Script will hauptsächlich einfache Anforderungen, C++ oder SQL ist wohl mehr was für Profis.

Java und Python will beides, Performance ist aber eher nachranging.

Alle Object-Pascal Produkte (Delphi, Lazarus, mse) wollen beides sein, und dabei auch noch gute Performance und (momentan nur bei den FPC-basierten) Portierbarkeit bieten. (Und damit ist die Lebensberechtigung für diese Produkte bewiesen.)

Die nicht-Unicode-Varianten von Delphi und Lazarus waren da sehr gut.

Unicode-Delphi auf Windows ist in dieser Hinsicht nicht allzu schlecht (aber: siehe oben). Die momentane Lazarus-Version fällt da meiner Ansicht nach sehr ab (Beispiel siehe oben) ('mal sehen, ob sich da bis Version 1.x noch was tut).

Auch der Einwand von Marcov bezieht sich auf komplexere Probleme,die - natürlich - die entsprechend komplexe Beschäftigung mit dem Thema benötigen. Trotzdem finde ich es nicht einsehbar, wenn simple Sachen einfach mehr mit den ursprünglich dokumentierten einfachen Methoden lösbar sind, nur weil nach einem Update das Programmiersystem auf einmal Unicode-Texte bearbeiten kann. Es sollte also - wenn das wirklich nicht anders geht - defaultmäßig eben nicht mit Unicode arbeiten und für Anwendungen, die Unicode benötigen, zusätzlich die entsprechenden Möglichkeiten zur Verfügung stellen. Wenn daraus eine Performance-Einschränkung resultiert (z.B. weil die Betriebssystem-API Unicode erwartet) ist das - finde ich - nicht schlimm. High-Performance-Anwendungen fallen - nach meiner Definition - unter die Kategorie "komplex" und brauchen eben mehr Gehirnschmalz zur Optimierung.

-Michael

[marcov]

[

Auch der Einwand von Marcov bezieht sich auf komplexere Probleme,die - natürlich - die entsprechend komplexe Beschäftigung mit dem Thema benötigen. Trotzdem finde ich es nicht einsehbar, wenn simple Sachen einfach mehr mit den ursprünglich dokumentierten einfachen Methoden lösbar sind, nur weil nach einem Update das Programmiersystem auf einmal Unicode-Texte bearbeiten kann. Es sollte also - wenn das wirklich nicht anders geht - defaultmäßig eben nicht mit Unicode arbeiten und für Anwendungen, die Unicode benötigen, zusätzlich die entsprechenden Möglichkeiten zur Verfügung stellen. Wenn daraus eine Performance-Einschränkung resultiert (z.B. weil die Betirebssystem-API Unicode erwartet) ist das - finde ich - nicht schlimm. High-Performance-Anwendungen fallen - nach meiner Definition - unter die Kategorie "komplex" und brauchen eben mehr Gehirnschmalz zur Optimierung.

Das ist IMHO alles totaler Quatsch. Die Anfaenger versuchen etwas, stoßen auf die Limitierungen, und willen eine Loesung.

Aber eben Anfaenger willen dann nicht die ganze Applikation rearchitecten, und alle mühsam gemachten Business kode zu herschreiben um den erste nicht Deutsche (oder West Europäische) unterstützten zu können.

Solcher Politik was du vorstellt schickt Anfänger in einer Engpass wo sie nimmer mehr rauskommen. Und fuer was? Ein bisschen Scheinsicherheit. Leute die das nicht haben können, sollen nach mehr Spezialisierten Umgebungen mit "halt-den-hand" Support optionen umsehen, und nicht nach ein Open Source General Purpose tool.

[theo]

P.s. nach 3 Jahre auf alles zu reagieren mit encoding oder Unicode darin, sollst du unbedingt einfach weg mal etwas darüber lesen. Zb das Introduktion Hauptstucks der Unicode Standard.

[mschnell]

Das ist IMHO alles totaler Quatsch.

Technisch sind wir uns ja einig, dass man mit dem aktuellen Lazarus das dritte Zeichen aus einem deutschsprachigen String nur dann extrahieren kann, wenn man sich vorher mit technischen Details von Unicode auseinandersetzt, obwohl man eigentlich gar nicht weiß, das es Unicode überhaupt gibt.

Der Unterschied ist nur, dass ich das schlecht finde und Du nicht. Darüber brauchen wir nicht zu streiten. Das ist eben Ansichts-Sache.

Dass ich mit meiner Meinung nicht allein stehe, sieht man daran dass die beiden anderen relevanten Pascal Programmier-System, die ich kenne, (Delphi und mse) das Problem zu umgehen versuchen, indem grundsätzlich mit UTF-16 Codierung gearbeitet wird. Ob das wirklich was eine sinnvolle Methode ist, kann diskutiert werden, aber offensichtlich ist, dass der Versuch unternommen wird.

-Michael

[theo]

@mschnell: Wieso postest du in letzter Zeit alles doppelt?

[mschnell]

@mschnell: Wieso postest du in letzter Zeit alles doppelt?

Keine Ahnung

[marcov]

Das ist IMHO alles totaler Quatsch.

Technisch sind wir uns ja einig, dass man mit dem aktuellen Lazarus das dritte Zeichen aus einem deutschsprachigen String nur dann extrahieren kann, wenn man sich vorher mit technischen Details von Unicode auseinandersetzt,

Nein, das Problem gilt für jeder Font System. Der Unterschied ist nur das Unicode es nennt und modelliert. Aber das ist nicht nur Unicode, sonder jedes modernes System. (Browser,GUI, alles was auf Text arbeiten). Es ist nicht für nichts das heutige (NT) Windows Versionen, schon seit dem Start auf Unicode setzen.

Der Unterschied ist nur, dass ich das schlecht finde und Du nicht.

Ich habe keine Interessen auf lange Diskussionen in Deutsch, dafür ist das für mich zu mühsam.

Der Grund unterschied ist nur das ich glaube das die seit für Workarounds und Kopf-im-Sand Politik schon zehn Jahre her sind. (und Delphi war schon relativ spät, und FPC/Lazarus werden noch später sein).

Das gilt aber nur für die hernutzbare teile von Applikationen. Aber das ist alles von FPC und Lazarus.

Was Anwender in ihre eigene Applikationen machen (zb wenn sie nur für die Deutschen Markt sind) müssen sie selber wissen.

Darüber brauchen wir nicht zu streiten. Das ist eben Ansichts-Sache.

Aber das war nicht was ich Quatsch nannte. Was ich Quatsch nannte war der Punkt das es Anwender nicht interessieren würde und/oder das es für sie langfristig besser wäre auf Unicode zu verzichten.

Dass ich mit meiner Meinung nicht allein stehe, sieht man daran dass die beiden anderen relevanten Pascal Programmier-System, die ich kenne, (Delphi und mse) das Problem zu umgehen versuchen, indem grundsätzlich mit UTF-16 Codierung gearbeitet wird. Ob das wirklich was eine sinnvolle Methode ist, kann diskutiert werden, aber offensichtlich ist, dass der Versuch unternommen wird.

Wie schon gesagt, hat UTF16 die gleiche Problem. UTF8 und UTF16 sind nur Kodierungen.

[mschnell]

Wie schon gesagt, hat UTF16 die gleiche Problem. UTF8 und UTF16 sind nur Kodierungen.

Da habe ich Dir ja soeben zugestimmt. Die Probleme fallen bei Delphi und mse eben nur nicht so schnell auf .

Ein System, dass diese Probleme - mindestens großenteils - beseitigen könnte, würde sicherlich einen ziemlichen Aufwand (Entwicklung und Laufzeit) der RTL erfordern.

Ein ordentlicher "Next Printable Character" Iterator für Strings, mit dem man sich in einer Schleife ein sichtbares Zeichen nach dem andern in einen sinnvollen Ergebnis-Typ holen kann, den man dann in einer "case" Anweisung abprüfen kann, wobei das Prüfen gleich aussehende Zeichen unterschiedlicher Codierung als identisch betrachtet, wäre meiner Ansicht nach aber sehr von Vorteil, auch wenn die Syntax eben nicht "case myString...", sondern ein neues Konstrukt ist.

Eine Frage ist dabei: wo bekommt man eine sinnvolle Tabelle der "(de)composed character" her ?

-Michael

[theo]

Hab ich so ähnlich schon vor Jahren hier hochgeladen: http://wiki.freepascal.org/Theodp" onclick="window.open(this.href);return false;

Normalisieren geht damit so:

Code: Alles auswählen

Memo1.Text:= TCharacter.Normalize_NFKC(Memo1.text);

[mschnell]

Mit "Iterator" meine ich etwas, das man formalisiert in einer Schleife verwenden kann, und das mit jedem Durchlauf das nächste Element (hier: Zeichen, nach dem beim Anzeigen ein Vorschub - z.B. nächstes TTF-Zeichen steht auf einer anderen Position - produziert wird, unabhängig von der Codierung) zur Verfügung stellt. (In FPC kann das mit einer "for in" - Schleife realisiert werden.)

siehe http://de.wikipedia.org/wiki/Iterator" onclick="window.open(this.href);return false; und http://wiki.freepascal.org/for-in_loop" onclick="window.open(this.href);return false;

Mit der Beschreibung der "case" Funktionalität meinte ich, dass alle Zeichen-Kombinationen, die dasselbe (z.B.durch TTF-Überlagerung) anzuzeigende Zeichen ergeben, gefunden werden. Dabei wäre meiner Ansicht nach die kombination "a", dann "e" nicht identisch mit "ä", es gibt aber - wenn ich das richtig verstanden habe eine Kombination "Pünkte ohne Vorschub " und "a", die bei der Anzeige zu einen "ä" führt. (Theoretisch wäre es tatsächlich möglich die Zeichen mit TTF auf ein Bitmap zu malen und die Pixel zu vergleichen .)

Wie gesagt. Keine Ahnung wo man die Kombinations-Tabelle herbekommt. Diese ist vermutlich riesig, so dass man sich vermutlich auf eine Teil-Tabelle für eine Anzahl Sprachen (z.B. West-Europa" beschränken muss.

-Michael

[theo]

@mschnell: Hast du dir die utf8tools denn einmal angeschaut, oder bevorzugst du weiterhin das planlose rummeckern?

Bau dir doch mal diesen Code mit utf8tools zusammen und schau dir an, was er tut:

Code: Alles auswählen

procedure TForm1.Button1Click(Sender: TObject);
var i:integer;
begin
  Edit1.Text:=TCharacter.Normalize_NFKD('öäü');
  ListBox1.Items.Clear;
  for i:=1 to length(Edit1.Text) do ListBox1.Items.Add('$'+HexStr(Byte(Edit1.Text[i]),2)+' '+Edit1.Text[i]);
  Edit2.Text:=TCharacter.Normalize_NFKC(Edit1.Text);
  ListBox2.Items.Clear;
  for i:=1 to length(Edit2.Text) do ListBox2.Items.Add('$'+HexStr(Byte(Edit2.Text[i]),2)+' '+Edit2.Text[i]);
end;

Kleiner Tipp: Wenn dir die Bedeutung der Bytes nicht klar ist: Ich habe mal der IDE eine Unicode Tabelle spendiert:
Bearbeiten -> Aus der Zeichentabelle einfügen -> Unicode
dort kannst du nachschauen. (siehe Anhang).

[mschnell]

Sorry, ich verstehe nicht, was Dein Vorschlag mit dem Thema zu tun hat.

Ein Iterator holt das nächste Element (hier die nächste vollständige auf einer Postion anzuzeigende Codierung).

Dafür darf natürlich nicht der komplette String umcodiert werden (das kann schließlich ein ganzes Buch sein) sondern es wird intern ein Zeiger gehalten mit Hilfe dessen im nächsten Schritt das jeweils nächste Element gefunden wird. Bei eine Unicode String wird der interne Zeiger vermutlich die Nummer des Codewortes (UTF8=Byte, UTF16=Word) sein. Das braucht (darf) man von außen aber nicht zu sehen.

Zu diesem Zweck wurden Iteratoren erfunden: Bearbeitung einer geordneten Folge von Element ohne dass ein (von außen sichtbarer, also irgendwie extern nutzbar definierter) Index existiert.

TCharacter.Normalize_NFKD kodiert den gesamten String um (also auch das 1 Millionste Element, auch wenn nur drei gebraucht werden). Das hilft also nicht bei dem was der Iterator machen soll.

Wenn TCharacter.Normalize_NFKD hilft zwei (de)composed Zeichen zu verglichen: gut. Aber soweit ich weiß, kann man das nicht in einer "case" - Anweisung verwenden (das war die Aufgabenstellung). (Oder kann "case of String" auch nicht-Konstanten ? )

Klar kann man das auch ohne case mit einer Folge von 100 "if" Anweisung machen. Aber das Ziel sollte doch sein, dass der Code nicht viel komplizierter wird als das alte

for i := 1 to length(str)
case str of
'a': ...
"ä': ...

-Michael
(Ich meckere überhaupt nicht. Es ist toll dass es Lazarus gibt und es das kann, was es kann. Wenn man Verbesserungsmöglichkeiten aber totschweigt, gibt es keinen Fortschritt.)

[marcov]

Wie schon gesagt, hat UTF16 die gleiche Problem. UTF8 und UTF16 sind nur Kodierungen.

Da habe ich Dir ja soeben zugestimmt. Die Probleme fallen bei Delphi und mse eben nur nicht so schnell auf .

Delphi/unicode unterstutzt unicode voellig, und nimmt keine Shortcuts. Das ist gleich was ich für FPC rate wurde. Was Applikation machen wollen sollen sie selber einschätzen.

Ein System, dass diese Probleme - mindestens großenteils - beseitigen könnte, würde sicherlich einen ziemlichen Aufwand (Entwicklung und Laufzeit) der RTL erfordern.

Es ist nicht deutlich welche "Probleme" du hier meinst.

Ein ordentlicher "Next Printable Character" Iterator für Strings, mit dem man sich in einer Schleife ein sichtbares Zeichen nach dem andern in einen sinnvollen Ergebnis-Typ holen kann, den man dann in einer "case" Anweisung abprüfen kann, wobei das Prüfen gleich aussehende Zeichen unterschiedlicher Codierung

Identisch zu Delphi's was ?

Eine Frage ist dabei: wo bekommt man eine sinnvolle Tabelle der "(de)composed character" her ?

Jedes Charakter hat auch Attribute. Alle Tabellen sind von die Unicode seit zu bekommen. Ich nutze aber .

Nicht (zu) embedded OSes haben solchen Tabellen typisch schon.