FPC Unicode support

[mschnell]

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

Du hast "Problem" gesagt: >>>Wie schon gesagt, hat UTF16 die gleiche Problem. UTF8 und UTF16 sind nur Kodierungen.<<<

Identisch zu Delphi's was ?

Natürlich nicht. Habe ich auch nie verlangt. Du hast gesagt das UTF16 (also Delphi) das Problem nicht löst.

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

OK, also könnte so ein "Iterator / case" System die Tabellen aus dem Betriebssystem verwenden. Macht die RTL in dieser Beziehung kleiner und vermutlich flexibler.

Ich nutze aber ...

Und ich möchte verhindern, dass jeder, der das dritte darstellbare Zeichen aus einem deutschen Text extrahieren will dieses Buch erst lesen muss

-Michael

[theo]

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

Du hast nach den "Kombinations-Tabellen" gefragt. Da sind sie.

Durch den UTF8String eiern geht damit auch:

Code: Alles auswählen

var ch: UCS4Char;
begin
  s := TUTF8Scanner.Create(Memo1.text);
  repeat
    ch := s.Next;
    tuwasmit(ch);
  until s.Done;

Da du aber nie an Lösungen interessiert bist, sondern lieber jahrelang die gleichen Probleme beschwörst, wird dir das wohl tatsächlich nichts nützen.

[mschnell]

Bitte schreib mir doch endlich 'mal den Code auf, der das berühmte nicht Unicode-Konstrukt:

Code: Alles auswählen

counta  := 0;
countae;= 0;
 
for i := 1 to 10
  case myString[i] of
  'a': inc(counta);
  'ä': inc(countae);
end;

In einem Unicode-System ersetzt. (wie gesagt, ohne den ganzen String umuzucodieren.)

Dann teste ich das 'mal. Auch bezüglich der Mac-typischen (de-)composed character ) Ich werde dann sicher auch herausfinden wie die codiert sind und sei binär eingeben.

Meine Idee, es benutzerfreundlich anzubieten wäre

Code: Alles auswählen

myString.LocateFirstPrintable;
for myPrintableChar in myString.NextPrintable
  case myPrintableChar of
  'a': inc(counta);
  'ä': inc(countae);
end;

oder so ähnlich.

(myPrintableChar ist natürlich auch ein String, damit er auch (de-)composed character aufnehmen kann.)

-Michael

[theo]

wie gesagt, ohne den ganzen String umuzucodieren.)

Diese Einschränkung verstehe ich nicht. Warum soll man nicht den ganzen String, oder die ganze Textzeile (man kann ja zeilenweise vorgehen) umcodieren?
Warum soll man mit einem Decomposed String arbeiten wollen?
Abgesehen davon liesse sich das auch lösen, wäre aber weniger performant.

Der Rest ist in der case demo hier beschrieben: http://wiki.freepascal.org/Theodp" onclick="window.open(this.href);return false;
Könnte man vllt. jetzt noch vereinfachen, da es String-Case gibt, sowie advanced Records etc.

[marcov]

Ich nutze aber ...

Und ich möchte verhindern, dass jeder, der das dritte darstellbare Zeichen aus einem deutschen Text extrahieren will dieses Buch erst lesen muss

Dann muss du ein eigen OS + API und Sprache programmieren. OS garantieren nie das alle Fonts alle Zeichen unterstützen. Also Darstellbarheit ist kein lösbares Problem in generell Fall. Shortcuts nur für bestimmten Gruppen sind nicht realisitisch

[mschnell]

Diese Einschränkung verstehe ich nicht. Warum soll man nicht den ganzen String, oder die ganze Textzeile (man kann ja zeilenweise vorgehen) umcodieren?

Dazu muss man die Zeilen-Trenner ja erstmal finden. Die findet man aber nur, wenn man die Codes sequentiell durcharbeitet, was einer Umkodierung ja schon nahe kommt.

Warum soll man mit einem Decomposed String arbeiten wollen?

Frag Marcov. der hat dieses Thema aufgebracht. Sonst wäre ja alles viel einfacher, es scheint aber wichtig zu sein.

Abgesehen davon liesse sich das auch lösen, wäre aber weniger performant.

Klar lässt sich das lösen. Habe ich nie bezweifelt. Mir wird ja nur vorgeworfen, dass ich überhaupt ein Interesse an einer solchen Lösung (Funktionalität in der RTL, intuitive Benutzer-Programmierung) zeige.

-Michael

[mschnell]

Dann muss du ein eigen OS + API und Sprache programmieren. OS garantieren nie das alle Fonts alle Zeichen unterstützen. Also Darstellbarheit ist kein lösbares Problem in generell Fall. Shortcuts nur für bestimmten Gruppen sind nicht realisitisch

Das ist aber extrem traurig. Ich gebe auf und schreibe lieber mit dem Bleistift.

-Michael

[theo]

Diese Einschränkung verstehe ich nicht. Warum soll man nicht den ganzen String, oder die ganze Textzeile (man kann ja zeilenweise vorgehen) umcodieren?

Dazu muss man die Zeilen-Trenner ja erstmal finden. Die findet man aber nur, wenn man die Codes sequentiell durcharbeitet, was einer Umkodierung ja schon nahe kommt.

Liefert das gute alte ReadLn nicht genau das?
TStrings auch, kann also nicht so eine unmögliche Anforderung sein.

Das Zeug entsteht ja nicht einfach so, sonder kommt durch File/Stream oder schlimmstenfalls Keypress rein. Da kann man es abfangen und umcodieren.

[mschnell]

Das Zeug entsteht ja nicht einfach so

Doch. Das Zeug könnte eine Datei sein, die den Text eines Buchs enthält. Die Datei ist in irgendeiner Unicode-Codierung. Wir sprechen ja nicht über irgendeinen bestimmten Einsatzfall, sondern über eine Methodik, die man allgemein zur String-Verarbeitung einsetzen / empfehlen kann.

-Michael

[theo]

Das Zeug entsteht ja nicht einfach so

Doch. Das Zeug könnte eine Datei sein, die den Text eines Buchs enthält. Die Datei ist in irgendeiner Unicode-Codierung. Wir sprechen ja nicht über irgendeinen bestimmten Einsatzfall, sondern über eine Methodik, die man allgemein zur String-Verarbeitung einsetzen / empfehlen kann.

Ja und? Hab ich ja gesagt von File/Stream.
Wenn die Datei decomposed sein soll (warum auch immer), kann man nach Bearbeitung wieder umcodieren.

Ich sage es gerne nochmal: Du bringst immer theoretische Fälle, aber auch nur andeutungsweise, die du dann aber gar nicht lösen willst.

Bring mal ein echtes Problem das du in der Arbeit oder im Hobby hast, dann versuchen wir eine Lösung zu finden.

[mschnell]

Zum Lösungen Finden brauche ich keine Hilfe. Das schaffe ich schon alleine.

Mir geht es darum, zu helfen das Programmiersystem zu verbessern.

Und für mich steht da vor der vor der praktischen Arbeit zunächst eine für möglichst viele Einsatzfälle tragfähige Definition dessen an, was eigentlich erreicht werden soll.
Als nächstes braucht man eine genaue, eindeutige Definition.
Parallel ist es natürlich sinnvoll, die Realisierbarkeit und den Aufwand abzuschätzen.
Erst dann kann man mit der Praxis loslegen.

-Michael

[theo]

Zum Lösungen Finden brauche ich keine Hilfe. Das schaffe ich schon alleine.

Sicher?

Mir geht es darum, zu helfen das Programmiersystem zu verbessern.

Und für mich steht da vor der vor der praktischen Arbeit zunächst eine für möglichst viele Einsatzfälle tragfähige Definition dessen an, was eigentlich erreicht werden soll.
Als nächstes braucht man eine genaue, eindeutige Definition.
Parallel ist es natürlich sinnvoll, die Realisierbarkeit und den Aufwand abzuschätzen.
Erst dann kann man mit der Praxis loslegen.

Dann definiere doch mal. Ich hab nichts dagegen. Alles ist besser als rummeckern.

[mschnell]

Dann definiere doch mal. Ich hab nichts dagegen. Alles ist besser als rummeckern.

Ich verstehe wirklich nicht, was Du als "meckern" empfindet. Ich habe doch genau das gemacht: eine vorläufige Definition von dem gegeben, was ich als sinnvolle Erweiterung zum Umgang mit Unicode (und auch anders codierte) Strings vrschlagen würde:

Zusammengefasst Im Klartext:

Es gibt einen Basis-Typ der einen String beliebiger Codierung enthalten kann (nennen wir ihn provisorisch BaseString). Er hat eine dynamische Kennung für Codierung und Byte_pro_Codewort. (Wie bei Delphi.)

Es gibt einen Type, der (im allgemeinen) genau ein "druckbares Zeichen" enthalten sollte (BaseChar, vermutlich ist das auch einfach nur ein BaseString, kann also statisch ( "Basechar[CodeNummer]" ) oder voll dynamisch (z.B. "BaseChar[$FFFE]" ) codiert sein).

Es gibt einen Type, der Code-Elemente (8, 16 oder 32 Bit) aufnehmen kann.

Man kann beim Programmieren String-Typen mit vorgegebener Codierung verwenden (Delphi-Notation String[CodeNummer]). Dadurch kann zur Compile-Zeit bereits über notwendige Umcodierungen entschieden werden was Rechenzeit spart (wie bei Delphi).

Dabei gibt es außer den festgelegten Codenummern (Länderspezifisches ANSI, verschiedene Unicode Varianten, (und neu:) die Codierung, die bei HTML-Texten verwendet wird) die Codenummer "0" (Durch das System festgelegter Default) und "$FFFF" (kein Code, wird nie konvertiert). Bei derart festgelegten statischen Typen ist die dynamisch in der String Variale gespeicherte Codierung (i.A.) gleich der statischen des Typs (bei "0": ???). (Alles wie bei Delphi.)

Zusätzlich gibt es noch eine Type-Nummer (z.B. "$FFFE") für "dynamische Codierung". Bei diesem Type (statische Festlegung im Quellcode) entschiedet die dynamische Codierung im String selbst über die Konvertierung:
- Bei Zuordnung auf so einen Type durch ":=" wird die Codierung übernommen.
- Bei Zuordnung von diesem Type auf einen statisch definierten Typ wird entsprechend umcodiert.
- bei Vergleichen wird (virtuell) entsprechend umcodiert. Technisch ist es natürlich sinnvoll, in der RTL einen Vergleich unterschiedlich codierter Strings auszuprogrammieren und nicht die kompletten Strings vorher zu konvertieren und dann zu vergleichen. (Delphi beachtet - soweit ich weiß, keine Unicode (de-)composed character, richtigerweise sollte das aber bei Umcodieren und Vergleich immer gemacht werden.)
- Bei Übergabe an ein Unterprogramm (der Formal-Parameter hat diesen Tpy) wird die Codierung übernommen.
- Var und out - Parameter: Vermutlich ist klar, was zu machen ist, da könnte es aber einige Haken und Ösen geben.

Standard - Funktionen wie Copy(), Pos, Length(), ... arbeiten virtuell mit diesem Typ, Compiler-Magic sogt dafür, dass statische definierte Typen entsprechend beachtet werden. (Wie in Delphi, außer es wird der voll dynamisch codierte Type als AktualParameter verwendet.

Mit dem dynamichen Typ ist es möglich, Funktionen zu schreiben, die allgemein verwendbar sind und keine Umcodierungen allein durch die Parameter-Übergabe erzwingen. (Ich weiß bis heute nicht, ob das bei Delphi geht.)

String ergibt ein Code-Element im entsprechenden Typ (also kein komplettes Unicode-Zeichen, weder normal noch (de-)composed) (wie in Delphi, muss entsprechend dokumentiert werden, weil Legacy-Code dadurch unbrauchbar wird).

Copy, Length, Pos, ... arbeiten in Code-Elementen (wie in Delphi, muss entsprechend dokumentiert werden, weil Legacy-Code dadurch unbrauchbar werden kann)

Es gibt einen Iterator, nennen wir ihn "BaseString.NextPrintableChar", der das nächste komplette Zeichen abgibt (neu) (viele Haken und Ösen bei (de)composed Caractern, wenn die Tabelle aus dem Betriebssystem verwendet wird, liegt die Verantwortung da.)

Es gibt eine Compiler-Magic für "case" und Vergleich (mit "="), wenn als Entscheidungs-Type ein BaseChar verwendet wird. Hier wird (virtuell oder dynamisch) entsprechend umcodiert (inclusive Behandling der (de-)composed Character). Konstanten werden natürlich schon zur Compile-Zeit so angelegt, dass sie - wenn der Vergleichs-Typ statisch kodiert ist - nicht umcodiert werden müssen. (ansonsten haben sie die System-Default-Codierung "0").

Durch die (de-)composed character wird das Umcodieren aufwendiger als bei Delphi. Da aber meist statisch codierte Strings verwendet werden ist Umcodieren nur selten nötig.

Probleme machen die (de-)composed Character bei allen Vergleichen. Da muss die Laufzeit-Erhöhung hingenommen werden, um den Comfort zu habe, diese überhaupt sinnvoll verarbeiten zu können. Vielleicht sollte man das irgendwie abschaltbar machen.

(Ist natürlich alles nur ein erster Vorschlag, der im Detail ausgefeilt und auf realisierbarkeut untersucht werden müsste, was natürlich nie passieren wird.)

-Michael

[theo]

@mschnell: Ich lese deinem Text später genauer, muss gleich weg.
Was meinen denn die FPC-Entwickler zu deinen Vorschlägen?
Ich hab die diesbezüglichen ermüdenden Mailinglist Diskussionen nicht mehr genau verfolgt.

[theo]

(Ist natürlich alles nur ein erster Vorschlag, der im Detail ausgefeilt und auf realisierbarkeut untersucht werden müsste, was natürlich nie passieren wird.)

Ja, das ist ein Wunschkonzert. Ohne jetzt ins Detail gehen zu wollen, sind deine Vorschläge sicherlich grösstenteils wünschenswert.
Nur sollte man die Rechnung nicht ohne den Wirt machen, d.h.Kompatibilität und Performance spielen beim FPC Team eine grosse Rolle.
Deshalb auch die Frage: "Was meinen denn die FPC-Entwickler zu deinen Vorschlägen?"