amiga-news ENGLISH VERSION
.
Links| Forum| Kommentare| News melden
.
Chat| Umfragen| Newsticker| Archiv
.

amiga-news.de Forum > Programmierung > Unicode auf OS3.x [ - Suche - Neue Beiträge - Registrieren - Login - ]

1 -2- 3 [ - Beitrag schreiben - ]

14.05.2009, 20:59 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Sieht doch schon gar nicht mal so schlecht aus, auch die non-spacing Marks sind korrekt gerendert.
Sollte nun einfach sein, Unicode support in TuiTED einzubauen.

Bild: http://www.hd-rec.de/pics/ttengine.png
--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
14.05.2009, 22:45 Uhr

Bjoern
Posts: 1730
Nutzer 		@Der_Wanderer:
Daumen hoch, muss man ja sagen!

Gruß,
Björn

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 08:29 Uhr

Thore
Posts: 2266
Nutzer 		Das Rendern eines Strings mit TTEngine ist einfach, doch für einen Editor müssen viele weitere Dinge vorhanden sein, wie Copy n Paste, Zeilenumbruch, Scrollmöglichkeit, dann noch in diesem Fall ein Umschalten des Codepages, Proportional und Nicht-Proportional, TTF und andere Fonts (TTEngine kann nur TTF), und alles Ein- und MultiByte-Konform.
Aber ich denke, daß "Der_Wanderer" das schon hinbekommt =)

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 10:07 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Das Rendern eines Strings mit TTEngine ist einfach, doch für einen Editor müssen viele weitere Dinge vorhanden sein, wie Copy n Paste, Zeilenumbruch, Scrollmöglichkeit, dann noch in diesem Fall ein Umschalten des Codepages, Proportional und Nicht-Proportional, TTF und andere Fonts (TTEngine kann nur TTF), und alles Ein- und MultiByte-Konform.
Nicht zu vergessen sind einfache Funktionen wie "Springe zum nächsten Wort", bzw. selbst schon "Gehe zum nächsten Zeichen", oder Suchen unabhängig von der Groß-/Kleinschreibung (oder auch Ändern der Groß-/Kleinschreibung.

Die erscheinen mir wichtiger als z.B. Proportional-Schriften.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:17 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		So schwierig ist das nicht. Ausserdem habe ich die ganzen Texteditor Funktionen schon, fehlt nur das Handling von Mehrbyte Zeichen, bzw. erstmal 16bit chars.

Ich werde das allerdings wohl nicht in TuiTED einbauen, sondern in NTUI (mein neues GUI Toolkit). Später gibts dann einen NTuiTED ;-)
--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:23 Uhr

Thore
Posts: 2266
Nutzer 		Keine schlechte Idee. Wenn der Editor allgemein nur 2 Byte Zeichen editieren kann.
Dann muss lediglich die Lade- und Speicherroutine den Text konvertieren, sowie das Clipboard.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:24 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
So schwierig ist das nicht. Ausserdem habe ich die ganzen Texteditor Funktionen schon, fehlt nur das Handling von Mehrbyte Zeichen, bzw. erstmal 16bit chars.
Ich bin mir nicht sicher, ob Dir klar ist, worauf das eigentlich hinausläuft. Wo ein Wort anfängt oder aufhört hängt davon ab, ob die aufeinanderfolgenden Zeichen Buchstaben, Zahlen, Satzzeichen oder Leerzeichen sind. Und um eine Zeichenfolge case-insensitive zu suchen, musst Du für jedes Zeichen wissen, ob es ein großes oder kleines Gegenstück besitzt. Die oftmals hardkodierten Regeln für 8Bit-Zeichen sind damit hinfällig...

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:34 Uhr

Thore
Posts: 2266
Nutzer 		@Holger:
Wenn der Suchstring auch nach 16Bit konvertiert wird, und bei der Suchfindung auf gerade Adressen geprüft wird, ist die Suche ohne Probleme möglich, wenn der Editor intern auch nur 16Bit Text verwaltet.
Allerdings muss dann auch in der Suchoption Unicode-Eingaben möglich sein, wenn ich z.B. im Text nach "我寻你" suchen will =)

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:41 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		In NTUI ist ein String-Gadget eine einzeilige Textbox mit etwas geänderten Farben und Bordern. Daher kann es automatisch auch Unicode.

Den Editor würde ich generell nicht auf 16bit umstellen, da sonst schnelles Laden nicht mehr gehen würde, bzw. man hätte grossen Speicherbedarf bei grossen Files. (Ja, bei der Abreit habe ich durchaus mal 1GB grosse Text-Files...).
Aber jede Zeile kann ein Flag besitzen, in welchem Encoding sie vorliegt, und erst beim Speichern wird, nach Bedarf, konvertiert.
Da würde ich 8bit und 16bit unterstützen, später vielleicht UTF-8.
Das ist nicht so schwierig, weil alle Positionsbestimmungen in einer Funktion zusammenlaufen, sodass gar nicht viel geändert werden muss.


--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 11:42 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Upper-Lowercase sind tatsächlich problematisch, wenn es nicht gerade um die ersten 127 Zeichen geht.
Da gibt es aber sicher irgendwo Tabellen im Netz.
--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:06 Uhr

Thore
Posts: 2266
Nutzer 		Für UTF-8 wär vielleicht das hier was:
http://mail.nl.linux.org/linux-utf8/2005-01/msg00000.html

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:16 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
@Holger:
Wenn der Suchstring auch nach 16Bit konvertiert wird, und bei der Suchfindung auf gerade Adressen geprüft wird, ist die Suche ohne Probleme möglich, wenn der Editor intern auch nur 16Bit Text verwaltet.
Ja, wenn der String exakt so wie eingegeben gesucht werden soll. Wenn Optionen wie "Groß-/Kleinschreibung egal" oder "Nur ganzes Wort" unterstützt werden sollen, ist es schon schwieriger.
Zitat:
Allerdings muss dann auch in der Suchoption Unicode-Eingaben möglich sein, wenn ich z.B. im Text nach "我寻你" suchen will =)
Es sei denn, ich kopiere es aus dem Text, um weitere Vorkommen zu finden.

Noch besser wäre es, wenn bestimmte Zeichen gleiche Kategorien finden könnten, z.B.

' findet auch ‘ ’ ‚ ‛
" findet auch “ ” „ ‟
- findet auch ﹣ -­ ‑ ‒ – — ―
? findet auch ¿ ⁇ ⁈ ⁉
A findet auch AÀÁÂÃÄÅĀĂĄǍǞǠǺȀ
usw.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:21 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Upper-Lowercase sind tatsächlich problematisch, wenn es nicht gerade um die ersten 127 Zeichen geht.
Da gibt es aber sicher irgendwo Tabellen im Netz.
Ja logisch. Unter http://unicode.org/
Man muss sie sich nur noch in ein handliches Format konvertieren, bzw. Algorithmen überlegen, um die häufiger vorkommenden Fälle effizienter abzuhandeln und nur in Ausnahmefällen die großen Tabellen in den Speicher zu laden.

Oder man greift auf die in diesem Thread schon verlinkte UniLibDev zurück, die genau das macht. Die ist im Gegensatz zu den anderen hier besprochenen Bibliotheken keine Rendering-Lösung, sondern dreht sich um die ganze Logik. Getestet habe ich sie allerdings auch noch nicht.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:36 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Ich mache mich ungerne von externen Libs abhängig, da das immer zu Problemen führt, z.B. wenn der Support eingestellt wird oder die User zu faul sind oder unfähig sie im Aminet zu finden. (siehe ZLib)

Deshalb nehme ich da nur das, was nötig ist und auch einigermassen "offiziell" rüberkommt.
Für das Casing gibt es unter Unicode.org Listen, die man verwenden kann. Sollte kein Problem sein, so gross sind die Listen nicht, was sind schon ein paar 1000 Einträge?


--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:39 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		Ein "fuzzy" Match wäre nett, aber für einen Informatiker eher ungeeigent, denn wenn ich ein Zeichen ersetzen will, dann meine ich meistens auch dieses Zeichen und kein anderes.
Zumal man sich nicht drauf verlassen kann, dass die "fuzzyness" erschöpfend ist.
Interessant wäre aber eine Character Spectrum Analyse, um zu sehen ob sich irgendwo noch ein paar Teufelchen verstecken.


--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 12:41 Uhr

Thore
Posts: 2266
Nutzer 		Großbuchstabe + 0x20 = Kleinbuchstabe. Das ist auch bei den Unicode-Zeichen so. Allerdings muss man die Grenzen wissen, da die meisten Zeichen keine Groß-/Kleinschreibung haben.
Am besten suchst Du in unicode.org nach JOHAB.TXT, da hats ziemlich viele drin.
Da ich die unicode Dateien habe könnte ich mich aber auch mal dransetzen und die Grenzen abschreiben. Wenn dann allerdings erst heute abend.

Character Spektrum Analyse? Nimm doch Soundex ;) Dann kannst auch nach ähnlich klingenden Wörtern suchen.

[ Dieser Beitrag wurde von Thore am 15.05.2009 um 12:43 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 14:45 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@Thore
Danke, aber ich denke bei unicode.org habe ich alles bekommen.
Aber wenn dich das Thema interessiert, kann du den Texteditor dann gerne testen, auch programmieren ist erlaub, alles OpenSource.

Es fehlen aber noch ein paar Kleinigkeiten, deshalb habe ich NTUI noch nicht öffentlich "promoted".
--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 16:13 Uhr

Thore
Posts: 2266
Nutzer 		Gerne wäre ich bereit den Editor zu testen. Und da ich Programmierer bin, würde mich auch das "dahinter" interessieren =)
Aufgrund meiner Arbeit musste ich mich auch in das Unicode-Zeugs einarbeiten, ich hab daher auch schon Konverter geschrieben, nebenbei lerne ich privat etwas chinesisch, wo ein Unicode-Editor mir sehr gelegen kommen würde =)

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 17:07 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
Großbuchstabe + 0x20 = Kleinbuchstabe. Das ist auch bei den Unicode-Zeichen so.
Erstes Gegenbeispiel, gefunden in 0,1s:
Ā ā
Groß: U+0100 Klein: U+0101
Und natürlich folgen da noch mehr.
Zitat:
Allerdings muss man die Grenzen wissen, da die meisten Zeichen keine Groß-/Kleinschreibung haben.
Womit diese Regel, selbst wenn sie stimmen würde, nicht viel hilft. Es gilt weiterhin, Schritt 1: Regel bestimmen, Schritt 2: Regel anwenden.
Von der türkischen Ausnahme wollen wir gar nicht erst reden...

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 17:17 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
Ich mache mich ungerne von externen Libs abhängig, da das immer zu Problemen führt, z.B. wenn der Support eingestellt wird oder die User zu faul sind oder unfähig sie im Aminet zu finden.
Ich würde verstehen, wenn man es davon abhängig machen würde, ob man die Erlaubnis bekommt, die Bibliothek seiner Anwendung beizulegen. Das mit dem Support kann ich dagegen nicht nachvollziehen. Du hast die Wahl zwischen jetzt selber implementieren oder dann selbst implementieren, wenn der Support der externen Bibliothek eingestellt wird.
Wo da beim jetzt selber Implementieren der Vorteil liegen soll, kann ich nicht erkennen. Ja, wenn das API dieser Bibliothek grottenschlecht wäre...aber für mich sieht es auf den ersten Blick ziemlich vernünftig aus.
Zitat:
Für das Casing gibt es unter Unicode.org Listen, die man verwenden kann. Sollte kein Problem sein, so gross sind die Listen nicht, was sind schon ein paar 1000 Einträge?
Sind über 100.000 Zeichen ein "paar tausend"?

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 18:19 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		> Sind über 100.000 Zeichen ein "paar tausend"?
Wie Thor schon geschrieben hat, haben die meisten Zeichen keine verschiednene Casings. Deshalb ist die Liste viel kleiner.

Wegen den Libs:

je nach lib, muss man sich fast so lange damit rumschlagen bis es läuft, als wenn man es selbst implementiert. Deshalb mache ich das eben nur dann, wenn es aufwendig wäre oder auf den ersten Blick relativ leicht geht. Viele Libraries sind auch nicht besonders gut gemacht, um man kommt irgendwann in ein Dead-End, z.b. bei der zlib.
Sie erlaubt z.B. nicht in mehreren Chunks zu packen. Deshalb würde
ich das gerne mal selbst coden (bzw. vom C-Code übernehmen).

--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 15.05.2009 um 18:30 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
15.05.2009, 19:35 Uhr

Thore
Posts: 2266
Nutzer 		Die Ausnahmen von 0x20-Sprung sind nicht so viele wie Du annimmst, man findet sie in ISO-8859-10.
Mit Sicherheit sind es keine tausende Zeichen, eher hunderte, wenn nicht gerade mal 150, die Caps haben (grober Schätzwert).
Es sind auch keine 100000 Zeichen im 2 Byte Unicode sondern nur 65536 (die nicht darstellbaren mitgerechnet).
Selbst die Unicode-Spalte des JOHAB Codepages das extrem viele Zeichen hat, umfasst gerademal 120 Capital-Zeichen, das ISO-8850-10 nur 70.
Ist alles überschaubar und realisierbar, ich sehe keinen Grund das Thema kompliziertzureden.

Anmerkung: Mit Capital Zeichen meine ich "große Buchstaben, zu denen ein Kleinbuchstabe gehört", also die Zahlen doppelt nehmen, also schätzungsweise 300 Groß + Kleinzeichen

Nachtrag:
Soll Dein ß auch als Großbuchstabe verfügbar sein, musst Du seinen "großen Bruder" mit U+1E9E angeben. Das ist ebenfalls eine Ausnahme des 0x20-Sprungs.

[ Dieser Beitrag wurde von Thore am 15.05.2009 um 19:38 Uhr geändert. ]

[ Dieser Beitrag wurde von Thore am 15.05.2009 um 19:47 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
17.05.2009, 17:17 Uhr

jolo
Posts: 110
Nutzer 		Aua, aua, aua - das zu lesen wird dauern...


@Thore
Zitat:
Unter MorphOS wird auf den BOM auch verzichtet beim Copy n Paste.

Dateien ohne BOM sollten der Regelfall sein und mit BOM nur Ausnahmen, ansonsten zerstört man nämlich Systemdateien die in ASCII erstellt worden sind aber als UTF-8 gespeichert werden. Ohne BOM unterscheiden sich beide Dateien nicht.

Zitat:
In diesem Fall ist es ein patch für das input.device.

Patch and burn! :)
Oder anders: Watschen fürs Patchen... :)
Ich hoffe, nachdem ich jetzt alle Beiträge gelesen habe, dass ihr nichts mehr patchen wollt?


Zitat:
NoWinEd interpretiert UTF-8 Codes und konvertiert diese zu ISO-8859-x (ich glaub 1), allerdings sind damit z.B. chinesische Zeichen verloren (durch ? ersetzt).

Unter OS3 (ISO-8859-1), ja, unter MorphOS/AmigaOS4/AROS immer entsprechend der IANA-ID (Locale-Bibliothek) (Amiga-1251, ISO-8859-x, TIS-620, UTF-x). Da weder MorphOS/AmigaOS4/AROS Unterstützung für die chinesische Zeichenausgabe und Eingabe anbieten, kann hier nichts abgebildet werden, daher die vielen '?'.
Da aber die MUI TextEditor MCC Klasse neu geschrieben werden müsste um UTF-Konformität zu erzielen ist UTF-x Unterstützung nur theoretisch vorhanden, also verbleiben noch Amiga-1251, ISO-8859-x und TIS-620 im Rennen wobei TIS-620 wiederum ausfällt, da es keine Einzelbyte-Kodierung ist, sondern ein Zeichen aus bis zu drei Bytes (drei Oktetts) besteht und die MUI TextEditor MCC Klasse dies nicht unterstützt.


@Wanderer
Zitat:
Was mir noch einfällt, man könnte durchaus UTF-8 auch tippen, denn man kann ja eine KeyMap machen, die gleich zwei oder drei Zeichen produziert.

Bloß nicht. UTF-8 ist ein Datenformat und nicht ein Wert irgendeiner Taste Deiner Tastatur.
UTF - Datenformat (im RAM, Harddisk oder generelles Speichermedium)
Unicode - Zeichensatz (im Gegensatz zu ASCII aber ein wenig umfangreicher)
Code Point - Wert eines Zeichens
Bitte nicht durcheinander bringen.


Zitat:
Also wenn TTEngline.library 7.2 gescheit funktioniert, scheint mir das der gangbarste Weg zu sein, einen Texteditor mit Unicode-Fähighkeit auszustatten.

Das mag stimmen. Leider, wenn ich das noch recht in Erinnerung habe, hat aber TTEngine unter OS4 arge Probleme bereitet. Ist allerdings schon Jahre her. Um das Ganze zu verifizieren müsste ich die entsprechenden Emails heraus kramen und lesen. Alternativ könnest Du ein paar Beispiele erstellen und OS4 Benutzer zum Testen bereitstellen bevor Du Dir die Mühe machst, alles auf TTEngine zuzuschneiden. Meine Beispiele, die TTEngine verwandten, dürften mit dem letzten Head-Crash einer Festplatte verloren gegangen sein... Muss mal schauen, vielleicht haben einige doch überlebt.


Zitat:
Ausserdem habe ich die ganzen Texteditor Funktionen schon, fehlt nur das Handling von Mehrbyte Zeichen, bzw. erstmal 16bit chars.

Leider unterscheiden sich Ein-Byte-Zeichenfunktionen (die Du derzeit in TuiTED verwendest) grundlegend von Unicode Funktionen. Du wirst diese nicht verwenden können.
Zudem ist die Limitierung auf 16-Bit sehr zeitraubend bedingt durch die Tests auf Surrogate-Code-Points, sofern Du nicht als Basis Unicode 3 verwendest, die allerdings veraltet ist.

Du könntest wie in OS4 für jede unterstützte Sprache die entsprechenden Funktionen (StrCmp/ToLower/ToUpper) als eigenständiges Modul schreiben, was allerdings mit erheblichen Aufwand verbunden ist.
Ich persönlich finde diesen Ansatz in Zeiten von Unicode aber nicht sehr elegant, jedoch immer noch besser als gar keine Funktionen anzubieten.


@Thore
Zitat:
Keine schlechte Idee. Wenn der Editor allgemein nur 2 Byte Zeichen editieren kann.

Wie, was? Das verstehe ich nicht.
16-Bit Code Points sind keine 2-Byte Zeichen. Oder verstehe ich hier etwas nicht richtig?
Erklärung bitte!


@Wanderer
Zitat:
In NTUI ist ein String-Gadget eine einzeilige Textbox mit etwas geänderten Farben und Bordern. Daher kann es automatisch auch Unicode.

Nee, kann es nicht. Unicode ist ein Zeichensatz, kein Datenformat wie IFF, PNG, UTF usw. .
Der Unicode-Zeichensatz enthält eine viel größere Menge an Informationen bereit als der ASCII-Zeichensatz, auf die bei korrekter Implementierung eingegangen werden sollte. Ein Latin-1 oder ASCII-Texteditor kennt gar nicht alle Attribute aus die der Unicode-Zeichensatz besteht. Hier muss dann nachgebessert werden.


@Wanderer
Zitat:
Den Editor würde ich generell nicht auf 16bit umstellen, da sonst schnelles Laden nicht mehr gehen würde, bzw. man hätte grossen Speicherbedarf bei grossen Files. (Ja, bei der Abreit habe ich durchaus mal 1GB grosse Text-Files...).
Aber jede Zeile kann ein Flag besitzen, in welchem Encoding sie vorliegt, und erst beim Speichern wird, nach Bedarf, konvertiert.
Da würde ich 8bit und 16bit unterstützen, später vielleicht UTF-8.

Das ist meinem Erachten nach kein günstiger Ansatz da alle Zeichenoperatoren dann für dieses spezielle Format nochmals vorliegen müssen. Einmal als Byte, dann als Wide-Char (16 Bits). Wäre mir persönlich nicht transparent genug.
Zudem denke ich dass bei halbwegs korrekter Implementierung deinerseits Du sowieso nicht um volle 32-Bit Unterstützung herumkommen wirst. Ist aber nur Spekulation meinerseits. :)


@Thore
Zitat:
Wenn der Suchstring auch nach 16Bit konvertiert wird, und bei der Suchfindung auf gerade Adressen geprüft wird, ist die Suche ohne Probleme möglich, wenn der Editor intern auch nur 16Bit Text verwaltet.

Pweeh, ich hoffe ich schmeiße nicht alle Beiträge durcheinander - eurer Thread ist ein wenig lang und ich hatte keine Zeit in den letzten Tagen zu antworten.

Was erwartest Du auf ungeraden Adressen zu finden wenn das Format als 16-Bit ausgelegt ist?
Alle Code Points sind bei einem 16-Bit Format 'Words', d.h. sie sollten sowieso auf geraden Adressen liegen. 16-Bit ('Words') bedeutet aber nicht, das ein Zeichen aus einem einzelnen 'Word' besteht, es sei denn man beschränkt sich auf Unicode 3.
Habe ich hier was nicht verstanden? Aufklärung bitte! :)


@Wanderer
Zitat:
Für das Casing gibt es unter Unicode.org Listen, die man verwenden kann. Sollte kein Problem sein, so gross sind die Listen nicht, was sind schon ein paar 1000 Einträge?

Autsch. :)
Die Basis-Datei für Unicode 5.1 ist eine Textdatei die schon mal 1 Mbyte groß ist. Alle Basisinformationen, die durch diese Datei beschrieben werden, in ein maschinenlesbares Format umzusetzen ohne irgendwelche Kniffe anzuwenden, wird in einer Tabelle zwischen 3 und 4 Mbytes resultieren, je nachdem welche Informationen abgedeckt werden sollen.


@Thore
Zitat:
Großbuchstabe + 0x20 = Kleinbuchstabe. Das ist auch bei den Unicode-Zeichen so. Allerdings muss man die Grenzen wissen, da die meisten Zeichen keine Groß-/Kleinschreibung haben.

Wie kommst Du an diese Information?
Der Unicode-Zeichensatz (Zeichensalat) gibt keine vordefinierten oder festen Distanzen zur Bestimmung einer Information vor. Groß/Kleinbuchstaben können beliebig weit auseinander liegen - und das tun sie auch!


Zitat:
Am besten suchst Du in unicode.org nach JOHAB.TXT, da hats ziemlich viele drin.

Nee, nix da. UnicodeData.txt ist euer Freund. :)


@Wanderer
Zitat:
Wie Thor schon geschrieben hat, haben die meisten Zeichen keine verschiednene Casings. Deshalb ist die Liste viel kleiner.

Du missachtest aber die Tatsache, dass Du erst einmal überprüfen musst, ob der betreffende Wert eines Zeichens (Code Point) in Deiner privaten Liste aufgeführt ist. Bei einem Spektrum von 1114109 Werten kommt dann Freude auf...
Ich hab' zwar keine Ahnung wie Du vorgehen willst, aber mit einfachen Vergleichsoperationen (ist Code Point in meiner Liste oder nicht) wirst Du nicht weit kommen. Es dauert viel zu lange die betreffende Information einzuholen.


Zitat:
je nach lib, muss man sich fast so lange damit rumschlagen bis es läuft, als wenn man es selbst implementiert.

Da gebe ich Dir recht. Nur in diesem speziellen Fall glaube ich, dass Du sehr viel mehr Zeit aufwenden wirst, um eine halbwegs passable funktionierende ToLower/ToUpper Funktion zu schaffen, ganz zu schweigen um Code Point Attribute abzufragen.


@Thore
Zitat:
Die Ausnahmen von 0x20-Sprung sind nicht so viele wie Du annimmst, man findet sie in ISO-8859-10.

Es gibt keine Ausnahmen. Der Unicode Zeichensatz ist nicht für eine einfache Indexierung geschaffen worden. Alles wäre einfacher falls dass Unicode Konsortium die Maschinen (CPU) in Mittelpunkt gestellt hätten und nicht den Menschen.
Haben sie aber nicht.
Anbei, ISO 8859-10 ist eine leicht geänderte Latin-1 Zeichenkodierung für nordeuropäischen Sprachen, demnach hat ISO 8859-10 nicht das Geringste mit dem Unicode-Zeichensatz zu tun.


Zitat:
Es sind auch keine 100000 Zeichen im 2 Byte Unicode sondern nur 65536 (die nicht darstellbaren mitgerechnet).

Das ist so nicht richtig.
Ersten gibt es kein '2 Byte Unicode' sondern Unicode 3 dass in 16 Bit Code-Units passt und Unicode 5.1 dass deren 32 (aktuell 21) benötigt. Zudem kann man auch Unicode 5.1 mittels 16 Bit Code-Units darstellen (Surrogate Code Points).
100000 Zeichen stimmt fast, es sind etwas mehr als 99000 definierte Zeichen vorhanden.
Aber, Du verwechselst, falls ich das richtig interpretiere, definierte Zeichen mit Werten. Der Wertbereich in Unicode geht von 0 bis 1'114'109 (1.1 Millionen) wobei ca. 99'000 Zeichen eine Bedeutung haben, ob als grafisches Symbol oder als Kontrollcode spielt dabei keine Rolle.


Zitat:
Mit Capital Zeichen meine ich "große Buchstaben, zu denen ein Kleinbuchstabe gehört", also die Zahlen doppelt nehmen, also schätzungsweise 300 Groß + Kleinzeichen

Selbst wenn Deine Aussage stimmen würde (tut sie nicht) ist das Problem nicht Groß- zu Kleinbuchstaben zu wandeln sondern herauszufinden, ob ein Wert ein bestimmtes Attribut hat und es erlaubt ist, eine Aktion basierend auf den Wert bzw. dessen Attribut, auszuführen. Es gibt in Unicode keine feste Bindung zwischen einem Wert und seinen Attributen.
Dein Fehler ist, dass Du zu sehr im Rahmen des griechischen Alphabets denkst. Unicode unterstützt das griechische Alphabet, ist aber nicht beschränkt auf seine Eigenheiten, ansonsten wäre Unicode nämlich unnütz.


Thilo/Thore

Ich will euch nicht vorschreiben, was ihr zu tun oder zu lassen habt, dazu habe ich auch keine Veranlassung.
Ich möchte euch aber verdeutlichen, dass ihr es euch zu einfach macht.
Unicode ist komplex. Selbst um nur eine kleine Teilmenge des Unicode-Standards zu implementieren wird schon sehr viel Zeit verschlingen. Ich spreche hier aus eigener Erfahrung.
Demnach solltet ihr auch das was ich geschrieben haben, als Anregung auslegen und nicht als Bevormundung, was ich wirklich nicht beabsichtige.
Zudem, ich bin kein Unicode-Spezialist und verfüge nur über allgemeines Wissen, nicht viel mehr als ihr beide auch habt.


In diesem Sinne,

viel Glück mit euren Unicode-Projekten,


Grüße


[ - Antworten - Zitieren - Direktlink - ]
17.05.2009, 19:51 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@Jolo
Ein weiser Mann hat mal gesagt, die Geschichte wurde nicht von den Kritikern geschrieben.

Im Gunde hast du recht, aber ein paar Anmerkungen muss ich anbringen:

1. Die "CaseFolding" Liste auf unicode.org hat etwa ~1100 Einträge. Das sind die Zeichen, die man bei einem Case-Insensitiven Vergleich berücksichtigen muss. Per Hashmap bekommt man den Zugriff auf beinahe O(1), da braucht ich noch nicht mal Binärsuche bemühen, mach dir also um die Speed keine Sorgen, ich muss nicht für jeden Buchstaben 1 Mio Einträge durchsuchen.

2. Keiner der Texteditoren die ich kenne, einschl. von Microsoft, handhabt Unicode 100% korrekt bzw. ohne kleinere Darstellungsfehler. Trotzdem hat es dicke gereicht, um alle mir bisher untergekommen Files anständig bearbeiten zu können. Und das sind nicht wenige, da ich beruflich mit allen möglichen Sprachen der Welt zu tun habe.

3. TuiTED bzw. das TextEditor Widget von NTUI ist eingiermassen sauber geschrieben, sodass Unicode kein Problem darstellt.
TTEgnine hatte ich sogar früher mal drin, habe ich aber wieder entfernt weil es nicht stabil war und auch den Text nicht da hin gerendet hat, wo ich wollte. Mittlerweile (v7.2) scheint es aber problemlos zu funktionieren.

4. UTF-x encodierte Files enthalten normalerweise einen BOM, das ist Standard. Müssen sie nicht, aber wer will sich schon auf Auto-Detection verlassen? Das wäre so wie Bilder als RAW Data speichern, und durch Korrelation der Zeilen beim Laden die Breite zu ermitteln. Kann man, ist aber nicht üblich.
Manchmal will ich gar nicht, dass UTF-8 Zeichen interpertiert werden, sondern will sie "nackt" als ASCII sehen.

5. Patchen werde ich nichts. Ich werde nur das NTUI TextBox Widget um Unicode erweitern. D.h. es kann dann 8bit im lokalen Zeichensatz wie bisher, und zusätzlich Unicode, evtl. erstmal 4byte um auf der sicheren Seite zu sein. UTF-x Dateien werden dann immer erstmal nach 4byte/Char umgewandelt. Später kann man evtl. noch optimieren, dass man direkt auf utf-8 arbeiten kann.
Letztendlich ist ein Texteditor nichts anders als ein Hex-Editor, man kann direkt auf dem Datei Image arbeiten. Nur die Darstellen ist anders und man muss etwas mehr "book-keeping" betreiben.
Ich will erreichen, dass der Texteditor nicht desktrukiv ist, also dass man sogar eine .exe reinladen kann, Zeichen (bytes etc.) verändern und wieder speichern. Dazu gehört z.B. dass man das NULL byte nicht als Zeilenterminator verwendet, sondern innerhalb einer Zeile zulässt. Mit Unicode kann ich es dann sogar vernünftig sichtbar machen.


--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de



[ Dieser Beitrag wurde von Der_Wanderer am 17.05.2009 um 20:00 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
17.05.2009, 20:21 Uhr

Gazelle
Posts: 151
Nutzer 		@Der_Wanderer:

Just as a side node, there is a CSET chunk defined for IFF (should be used with FTXT and the clipboard) which was updated by Detlef Würkner for OS4 to use the MIBenum (IANA) for CodeSet:
C code:
struct CSet
{
    uint32 CodeSet;
    uint32 Reserved[7];
}

/edit: Ähem, ich hoffe Ihr versteht auch Englisch. Irgendwie bin ich es gewohnt in Programmierforen auf Englisch zu schreiben.


[ Dieser Beitrag wurde von Gazelle am 17.05.2009 um 20:23 Uhr geändert. ]

[ - Antworten - Zitieren - Direktlink - ]
17.05.2009, 21:32 Uhr

Thore
Posts: 2266
Nutzer 		@Jolo
Ich kenne die Versionierung von Unicode und auch daß es bis 32 Bit geht. Ich versuch meine Beiträge aber so zu gestalten, daß die Leser nicht dauernd nachschlagen müssen.
In diesem Beitrag ging es auch immer um UTF-8, und dieses besteht aus 8 oder 16 Bit Zeichen, daher war der nächste Schritt eben ein 16 Bit Codepage, und dieses umfasst nunmal nur 65536 Zeichen, was in den allermeisten Fällen ausreicht. Also die Idee war erst, auf WideChars umzurüsten. In deiner Sprache: Wir verwenden die CodePoints des UTF-16, welches die Unicode Zeichen beinhaltet die zwischen U+0000 und U+FFFF liegen. Durch solche Beschreibungen kommen wir hier aber nicht weiter, es ging lediglich drum, ob nun UTF-8 oder UTF-16 verwendet werden soll... seufz...
Übrigens. 16Bit CodePoint, z.B. U+1234, stellt man als Anreihung von 2 Bytes dar, nämlich 0x12 und 0x34, für mich ist das ein 2-Byte-Zeichen. Oder sieht das jemand anders? Phrasendrescherei....
Der BOM ist auch eigentlich nur geschaffen, um die Reihenfolge der Bytes korrekt zu setzen (LE, BE) auch das ist allen hier klar, er KANN aber verwendet werden, um einen Text als UTF-8 zu markieren, und ja, wir wissen daß es für die verschiedenen Codepages auch verschiedene BOMs gibt, ein Fehler ihn hinzuzufügen ist es allerdings nicht, selbst HTML-Seiten haben manchmal diesen BOM (trotz Meta Tag).
Die Regel des 0x20-Sprungs ist sicher nicht überall so, jedoch in den meisten Fällen. Und wieso sollen Unicode-Zeichen nicht eindeutig sein?
In allen Textdateien von Unicode.org stehen in der 2. Spalte die 16 Bit Unicode Werte. Und die sind in allen Codepage-Dateien identisch, lediglich der Wert in der ersten Spalte, der des Codepages an sich, kann anders sein.
In ISO-8859-10 stehen Zeichen drin, die im 8859-1 nicht sind. Hier sind 140 Zeichen die der Groß-/Kleinschreibung unterliegen. In JOHAB.txt sind 240 Zeichen die dieser Schreibweise unterliegen. Sichtbar durch CAPITAL und SMALL in der Beschreibung.
Zur geraden Adresse: Wenn der Editor in 16Bit Zeichen suchen soll, dann muss er auf geraden Adressen suchen. Das ist nicht automatisch so, das muss man so programmieren. Wenn später auch nach UTF-8 Zeichen gesucht werden soll, muss das ebenso berücksichtigt werden.
Bisher sucht die Routine in 1 Byte Codes. Die einzig richtige Überlegung vom Wanderer ist, daß die Eingabe des Suchstrings das gleiche Codepage verwendet.
MorphOS unterstützt die Ausgabe chinesischer Zeichen! Multiview stellt sie dar, einwandfrei. NoWinEd nicht, und zwar nur deshalb weil es kein UTF-8 darstellt sondern konvertiert. Wie Du selbst geschrieben hast, viele MUI-Klassen unterstützen kein UTF.

Lange Rede, kurzer Sinn. Es ging nur darum, on die 8Bit Unicode oder 16 Bit Unicode-Funktion von TTEngine verwendet werden soll. Für die Ausdrucksweise verweise ich jetzt auf das Readme von TTEngine.

[ - Antworten - Zitieren - Direktlink - ]
18.05.2009, 12:32 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
1. Die "CaseFolding" Liste auf unicode.org hat etwa ~1100 Einträge. Das sind die Zeichen, die man bei einem Case-Insensitiven Vergleich berücksichtigen muss. Per Hashmap bekommt man den Zugriff auf beinahe O(1), da braucht ich noch nicht mal Binärsuche bemühen, mach dir also um die Speed keine Sorgen, ich muss nicht für jeden Buchstaben 1 Mio Einträge durchsuchen.
Statt einer HashMap kann man auch die vom Unicode-Konsortium empfohlene zwei-level Tabelle benutzen. Wie dem auch sei, genau darum ging es bei der ursprünglichen Aussage: Du musst etwas mehr Gehirnschmalz in die Implementierung stecken, als eine simplen Tabelle aufzubauen, wenn das Ergebnis halbwegs effizient sein soll. Das abzustreiten, während man selbst schon über eine Hashmap nachdenkt, ist absurd.
Zitat:
4. UTF-x encodierte Files enthalten normalerweise einen BOM, das ist Standard.
Falsch. Ein BOM bei UTF-8 widerspricht sogar dem Standard und hat sich bestenfalls bei einigen Systemen als Quasi-Standard durchgesetzt. Ich kenne es allerdings nur von Microsoft.
Bei UTF-16 gibt es einen BOM, bei UTF-16LE oder UTF-16BE dagegen nicht, da die Wahl des Encodings bereits die Byte-Reihenfolge explizit definiert.
Zitat:
UTF-x Dateien werden dann immer erstmal nach 4byte/Char umgewandelt. Später kann man evtl. noch optimieren, dass man direkt auf utf-8 arbeiten kann.
Hattest Du nicht mal gesagt, man soll auch mit großen Dateien vernünftig arbeiten können? Wenn schon fixe Zeichenbreite, dann erscheint mir 16 Bit pro Zeichen und die ohnehin selten vorkommenden surrogates als Sonderfall zu unterstützen sinnvoller.
Zitat:
Letztendlich ist ein Texteditor nichts anders als ein Hex-Editor, man kann direkt auf dem Datei Image arbeiten. Nur die Darstellen ist anders und man muss etwas mehr "book-keeping" betreiben.
Ja, insbesondere beim Mappen fester Adressen bei n bytes pro Zeichen zu den Positionen in einer UTF-8 Datei. Der Aufwand wird fast genauso hoch wie das Unterstützen von UTF-8 direkt im Editor.
Zitat:
Ich will erreichen, dass der Texteditor nicht desktrukiv ist, also dass man sogar eine .exe reinladen kann, Zeichen (bytes etc.) verändern und wieder speichern.
Das erfordert bei UTF-8 Strings natürlich besondere Aufmerksamkeit, da der sich Platzbedarf eines einzelnen Zeichens beim Überschreiben ändern kann. Will man die nachfolgenden Zeichen erhalten, muss man sie verschieben. Dazu benötigt man ein Stop-Position hinterm Cursor, ab der nicht mehr verschoben werden darf. Bei C-Programmen ist das ganz klar das 0-byte, bei anderen Programmen kann das anders sein.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
18.05.2009, 13:06 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Thore:
@Jolo
Ich kenne die Versionierung von Unicode und auch daß es bis 32 Bit geht. Ich versuch meine Beiträge aber so zu gestalten, daß die Leser nicht dauernd nachschlagen müssen.
Wenn Du Deine Beiträge mit Falschinformationen füllst, muss der Leser noch mehr nachschlagen.
Zitat:
In diesem Beitrag ging es auch immer um UTF-8, und dieses besteht aus 8 oder 16 Bit Zeichen, daher war der nächste Schritt eben ein 16 Bit Codepage, und dieses umfasst nunmal nur 65536 Zeichen, was in den allermeisten Fällen ausreicht.
Absurde Logik. Selbst bei altem Unicode, das nur 16Bit-Codepoints kennt, kann ein UTF-8 kodiertes Zeichen bis zu drei Bytes lang sein.
Inwieweit sich bei einer Diskussion um UTF-8 eine Beschränkung auf zwei bytes pro Zeichen aufdrängt, musst Du noch mal erklären.

Wenn man aber von UTF-8 spricht, und nicht explizit auf veraltete Standards verweist, kann ein UTF-8 Zeichen eben bis zu vier bytes lang sein, was in der Verarbeitung aber keinen nennenswerten Unterschied verursacht.
Zitat:
Die Regel des 0x20-Sprungs ist sicher nicht überall so, jedoch in den meisten Fällen.
Es gibt mehr als doppelt so viele Zeichen, bei denen der Offset 1 (in Worten: eins) beträgt. Selbst die übrig bleibenden Großbuchstaben, deren Mapping sich unregelmäßig auf ca. 40 verschiedene Offsets verteilt, kommen noch auf das anderthalbfache derer, bei denen der Offset 0x20 beträgt.

Deine "meisten Fälle" machen also ca. ein fünftel der Fälle aus--wohlgemerkt ein fünftel jener Zeichen, für die überhaupt ein Mapping existiert. Ungefähr für die Hälfte aller Großbuchstaben gibt es nämlich gar kein Mapping.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]
18.05.2009, 13:19 Uhr

Der_Wanderer
Posts: 1229
Nutzer 		@Holger

Würdest du intern mit UTF-8, festen 16 oder 32Bit arbeiten?


--
HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes und viele mehr...
Homepage: http://www.hd-rec.de


[ - Antworten - Zitieren - Direktlink - ]
18.05.2009, 14:12 Uhr

Holger
Posts: 8116
Nutzer
Zitat:
Original von Der_Wanderer:
@Holger
Würdest du intern mit UTF-8, festen 16 oder 32Bit arbeiten?
Für Textpuffer entweder mit UTF-8 oder mit UTF-16. Ich würde die Routinen strikt in Operationen auf dem Puffer und Operationen auf den Zeichen trennen. Letztere würden dann immer mit 32 Bit-Werten arbeiten.

Die Pufferoperationen sind überschaubar, weshalb es auch nicht allzu schwierig wäre, die Speicherform zu wechseln. Das wichtigste wäre ein Iterator, der das Lesen/Schreiben des nächsten Zeichen, Erhöhung des Adresszeigers und Konvertierung zwischen Pufferform und 32Bit-Wert kapselt und das Erreichen des Endes signalisiert. Selbst Operationen wie Anzahl Zeichen zählen können auf diesem Iterator aufsetzen, wobei je nach verwendeter Programmiersprache ein paar optimiertere Fassungen dazu kommen könnten, um den Overhead zu reduzieren.

Damit kann sich auch der klassische 8Bit-Encoding Puffer in die Anwendung einfügen ohne eine Spezialbehandlung zu benötigen.

Alle anderen Operationen, wie Vergleichen, Groß-/Kleinschreibung, Kopieren, Konvertieren arbeiten mit den 32 Bit-Werten, wobei das Konvertieren quasi zur No-Op, bzw. Kopieroperation wird: einfach die Werte des Lese-Iterators der Quelle an den Schreib-Iterator des Ziels übergeben.

Für die verlustfreie Bearbeitung von Binärdateien würdest Du einen weiteren speziellen Puffer-Modus benötigen, der zwischen verschiedenen Interpretationen wechseln kann, da eine durchgängige Interpretation weder als UTF-8 (würde ungültige Zeichen erzeugen), noch als UTF-16 (kann in Binärdatei an ungeraden Positionen beginnen) möglich ist.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Antworten - Zitieren - Direktlink - ]

1 -2- 3 [ - Beitrag schreiben - ]


amiga-news.de Forum > Programmierung > Unicode auf OS3.x [ - Suche - Neue Beiträge - Registrieren - Login - ]


.
Impressum | Datenschutzerklärung | Netiquette | Werbung | Kontakt
Copyright © 1998-2024 by amiga-news.de - alle Rechte vorbehalten.
.