|
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 - ] |
|
11.05.2009, 16:54 Uhr Der_Wanderer Posts: 1229 Nutzer |
Wie (kann man überhaupt) stellt man denn Unicode unter OS3.x dar? Das geht wohl mit "Bordmitteln" nicht, oder? -- 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 - ] |
|
11.05.2009, 17:06 Uhr cgutjahr Posts: 2783 [Administrator] |
Zitat:Wenn du dir nicht eine komplette eigene Font-/Codeset-Engine schreiben willst (warum eigentlich nicht, das fehlt dir doch noch in deiner Sammlung  ), ist die codesets.library vermutlich der einzige gangbare Weg? Ist natürlich nicht "Darstellung" sondern "Konvertierung", wird beispielsweise von YAM benutzt:http://aminet.net/package/util/libs/codesets-6.6 -- Gutjahrs Amiga Seiten [ - Antworten - Zitieren - Direktlink - ] |
|
11.05.2009, 17:23 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ja, Konvertierung auf das lokale 8bit System ist nicht das Problem. Ich möchte TuiTED Unicode fähig machen, was aber wenig Sinn hat wenn man die Zeichen nur als leere Kästchen bewundern kann. -- 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 - ] |
|
11.05.2009, 20:23 Uhr Holger Posts: 8116 Nutzer |
Der einzige Weg, Unicode ohne verlustbehaftete Konvertierung mit AOS3.x-Bordmitteln darzustellen, besteht darin, die bullet.library, bzw. eine API-kompatible Engine direkt anzusprechen. Das ist wenig komfortabel. Zuerst muss man den Font normal öffnen, dann die Attribute abfragen, um herauszufinden, welche (bullet-kompatible) Library die zuständige Engine ist, die dann öffnen, über diese den Font erneut öffnen und für jedes einzelne Zeichen des Strings die Attribute abfragen, wobei der Erstellen einer BitMap für das Zeichen genauso wie ein Attribute abgefragt wird. Dann muss man nur noch die BitMaps unter Berücksichtigung der abgefragten Größen und optionales Kerning platzieren und auf den Bildschirm blitten. Und wer clever ist, wird wohl entweder die Glyph-Images oder komplette String-Images oder eine Kombination daraus cachen... Und sobald Du das fertig hast und für alle AB3-User zu Verfügung stellst, werde ich wohl auch auf AB3 umsteigen.  Schade nur, dass der gesamte Rest des AOS3 nix mit Unicode anfangen kann. mfg Ach so, habe ganz vergessen, zu erwähnen, dass das nur mit Outline-Schriften funktioniert, falls das noch nicht aus der Beschreibung hervorgegangen ist... -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
11.05.2009, 20:28 Uhr Holger Posts: 8116 Nutzer |
Natürlich gibt es noch eine andere Möglichkeit. Man kann eine eigene fertige BitMap-Schrift in irgendeinem Custom-Format mit dem Programm mitliefern und diese selbst rendern. So sehr unterschiedet sich das nicht von der o.g. Variante. mfg [ - Antworten - Zitieren - Direktlink - ] |
|
11.05.2009, 20:34 Uhr jolo Posts: 110 Nutzer |
@Der_Wanderer: Hi. Was Du benötigst wäre eine Render-Engine die Unicode unterstützt. Es gibt zwei für OS3. Beide arbeiten aber nur mäßig und sind sehr eingeschränkt im Umfang. Im Prinzip fast nutzlos. Die eine nennt sich TTEngine und die andere UCode. Vorab, falls Du einem Texteditor Unicode beibringen willst, sollte dieser: a) bidirektionale Zeichenausgaben beherrschen und auch diverse Methoden für Weak und Strong Characters anbieten b) zwischen Spacing und Non-Spacing Marks unterscheiden können c) Proportionale Schriftenausgabe beherrschen d) mehr als eine Schriftart pro Textzeile zulassen und diese Schriften zudem auch in unterschiedlicher Größe pro Textzeile darstellen können Alles andere wäre nur eigeschränkt Unicode fähig. Falls Du nur westliche Schriften unterstützen möchtest, reicht die Codesets-Bibliothek aus, um die Unicode-Werte auf den entsprechenden, westlichen Zeichensatz, abzubilden und dann mittels Text() das auszugeben, was abgebildet werden kann. Allerdings hat das in meinen Augen nichts mehr mit Unicode zu tun. Mein Rat an Dich wäre derzeit ein solches Projekt auf dem Amiga zurückzustellen und zu warten, bis irgendjemand eine voll funktionsfähige Unicode Render-Engine bereitstellt (z.B. Pango in Verbindung mit Cairo). Alles andere ist entweder halber Kram oder gänzlich Spielerei (siehe UCode). Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
11.05.2009, 21:44 Uhr Der_Wanderer Posts: 1229 Nutzer |
Hm... @Holger Den Mund nicht zu voll nehmen, am Ende implementiere ich das ja genau so... ;-) > a) bidirektionale Zeichenausgaben beherrschen und auch diverse > Methoden für Weak und Strong Characters anbieten Bidirektional ist nur für die korrekte Anzeige notwendig, und machen auch unter WindowsXP viele Editoren nicht. Unter Vista ist das mittlerweile verbessert worden. Theoretisch müsste man dann auch Complex-Script (z.B. für Arabisch) machen etc. Aber so wichtig ist das fürs editieren nicht, wenn man nicht einen Roman auf Arabisch schreiben will... (wie ich auf AmigaWorld sehe, kommen 99,9% aller Amiga User aus Regionen, wo man von Links nach Rechts schreibt. Mir geht es hierbei mehr draum, mit Unicode Files überhaupt was anfangen zu können und sie editieren zu können ohne das Dokument zu zerstören. Alle Feinheiten der Anzeige muss man nicht unbedingt haben, weil, wie gesagt, es wenig Leute auf dem Amiga betreffen würde. Für Darstellung auf einer Website gebe ich dir aber recht, denn da will man ja einen Text schön formatiert lesen. Bei Editoren ist es manchmal sogar umgekehrt, dass man z.B. Non-Spacing Marks seperat hat um sie besser identifizieren/editieren zu können. > b) zwischen Spacing und Non-Spacing Marks unterscheiden können Siehe a) Fürs Editieren ist es sogar besser die Marks explizit zu sehen. > c) Proportionale Schriftenausgabe beherrschen Das kann TuiTED ja. Puh! > d) mehr als eine Schriftart pro Textzeile zulassen und diese > Schriften zudem auch in unterschiedlicher Größe pro Textzeile > darstellen können Das stimmt, das sollte ich noch einbauen, wäre aber nicht so schwer. > Alles andere wäre nur eigeschränkt Unicode fähig. Ich denke c) und d) sind notwendig, um mit dem Unicode Text vernünftig umgehen zu können. a) und b) sind für Editoren nicht so wichtig denke ich, da es eher um ein schönes Darstellen geht, aber notwendig um den Text zu lesen/editieren ist es nicht. Es geht hier ja auch nicht darum, ein spezial Tool zum Anzeigen von jeder erdenklichen Unicode File zu machen, sondern um einen Texteditor, der das momentan gar nicht kann, zu erweitern dass eine Unicode File korrekt bearbeitet werden kann. Mir gefällt aber die Idee von Holger gar nicht schlecht, die Unicode Zeichen vorzurendern und als Bitmaps dem Editor beizulegen. Den Text() Befehl zu simulierenist ja dann trivial. Wenn dann ein Zeichen nicht vorhanden ist, kann es aus dieser Font geholt werden. So kann man auch gleich alle Steuerzeichen dazu packen, das hatte ich soweiso vor, einschl. dem NULL-Byte. Mir geht es darum, Text files (oder auch Binaries) verlustfrei im Texteditor zu editieren und wieder zu speichern, dann spart man sich auch ab und an den Hex Editor anzusmeissen. -- 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 11.05.2009 um 21:44 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.05.2009, 09:54 Uhr Holger Posts: 8116 Nutzer |
Zitat:Und gehören natürlich auch beide nicht zu den Bordmitteln. Zitat:Kann ich nicht nachvollziehen. Zitat:Was hat die Darstellung der Schriftarten in verschiedenen Größen bitteschön mit Unicode-Fähigkeit zu tun? Zitat:So so. Und wie teilst Du unter AOS3.x der Text()-Funktion mit, mit welchen Zeichensatz Du rendern willst? Das AOS3.x schert sich bekanntermaßen nicht darum, ob ein Schriftsatz für einen anderen Zeichensatz entworfen wurde. Und warum darf man nicht außer westlichen Schriften auch osteuropäische Sprachen, russisch, mongolisch oder Quốc Ngữ unterstützen, nur weil man rechts-nach-links Sprachen nicht unterstützt? Warum muss es "alles oder nichts" sein? Zitat:Also noch weitere zehn Jahre warten. Toller Ratschlag. Dir ist aber schon bewusst, dass sich die Bordmittel von AOS3.x prinzipiell nicht mehr verändern? Zitat:Hab ich kein Problem mit. Schlimmer als C kann AB3 ja nicht sein Zitat:Ja, man kann schon mit einer Sprache mehr Unicode-Features nutzen, als mit einer Konvertierung in einen der existierenden 8 Bit-Zeichensätze abgebildet werden können. Zitat:Dazu ein kleiner Tip: Suche im Netz nach freien Unicode-Schriftarten. Da gibt es imho einige, die mit dem Ziel antreten, möglichst viele Zeichen abzudecken. Und im Unicode-Zeichensatz sind auch graphische Repräsentationen von Steuerzeichen reserviert. ␀ ␄ ␆ ␇ ␈ ␍␊ mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
12.05.2009, 13:21 Uhr Der_Wanderer Posts: 1229 Nutzer |
@Holger ACK. Um das Rendern von Vektoren zu umgehen, könnte ich ja eine recht große Bitmap "Font" erstellen, 2-Farbig, dann braucht es nicht so viel Speicher und kann es RLE komprimieren. Wenn dann ein Zeichen gefragt ist, wird es in der entsprechenden Größe als Bitmap gezoomed und gechached. Ich habe das mal ausprobiert, ist nicht perfekt, aber besser als nichts: Original: Bild: http://www.hd-rec.de/pics/UnicodeTestA.png S/W Bitmap: Bild: http://www.hd-rec.de/pics/UnicodeTestB.png Gezoomed: Bild: http://www.hd-rec.de/pics/UnicodeTestC.png Der Font Renderer ist ja dann nur für den Editor gedacht, somit ist auch das AA kein Thema, da die Hintergrundfarbe bekannt ist. Dann kann man halt Unicode Files nur in einer Font angucken (hier MS Arial Unicode). Alternative wäre evtl. direkt die freetype.library zu benutzen. Muss ich mir mal anschauen. -- 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 - ] |
|
12.05.2009, 13:29 Uhr Der_Wanderer Posts: 1229 Nutzer |
Weiss jemand, ob es zur freetype2.library irgendwo ein SDK oder zumindsest eine .fd File gibt? Nachtrag: Die ttengine.library scheint mir von allen wohl am geeignetsten zu sein. Die hatte ich auch schonmal in TuiTED integriert, allerdings gab es Probleme mit dem Layout. Mal sehen ob ich es diesmal besser hinbekomme. Wird dann allerdings nicht TuiTED werden, sondern das NTUI TextBox Widget. -- 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 12.05.2009 um 14:16 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
12.05.2009, 19:42 Uhr Der_Wanderer Posts: 1229 Nutzer |
Habe gerade mit Schecken festellen müssen, dass OS4, MOS und AROS alle kein Unicode können. Simmt das oder irre ich mich? -- 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 - ] |
|
13.05.2009, 08:37 Uhr Thore Posts: 2266 Nutzer |
Unter MorphOS2.x wurde für Multiview bei Texten UTF-8, UCS-2 und UCS-4 Unterstützung eingebaut und für Guide UTF-8, so daß hier auch zum Beispiel chinesische Texte lesbar sind (von mir mit Erfolg getestet). Auch Copy n Paste geht. Die locale.library hat ebenfalls eine Unicode-API verpasst bekommen und unterstützt in Katalogen UTF-8 und UTF-32/UCS-4. Auch die intuition.library hat für IDCMP Tastatur-Eingaben Unterstützung für UCS-4. (Infos auf http://www.morphos-team.net/releasenotes-2.0.html und http://www.morphos-team.net/releasenotes-2.2.html) Unter AmigaOS3.x gibt es für koreanisch, chinesisch und japanisch Text-Patches, die aber etwas buggy sind, was Multiview angeht (Copy n Paste kann zu Absturz führen), und im EditPad gibts Probleme beim Markieren. Die TTEngine.library ist ein guter Ansatz, jedoch ist mir noch kein Programm bekannt, das auch Copy n Paste unterstützt. Vielleicht lassen sich die relevanten Routinen (u.a. OpenFont()/CloseFont(), Text(), TextLength() und TextExtend()) durch die TT_ Funktionen patchen, nur muss hierfür geprüft werden, ob ein TTF-Font benutzt wird oder ein anderer, und je nach dem zwischen den alten Routinen und den TT-Routinen umschalten muss. Wenns denn überhaupt so machbar ist... [ - Antworten - Zitieren - Direktlink - ] |
|
13.05.2009, 11:03 Uhr Der_Wanderer Posts: 1229 Nutzer |
Wie sieht denn die OS API aus für Unicode? Ich dachte MOS macht das lediglich via TTEngine, was ja aber nicht direkt OS Funktionen sind und auch angeblich Probleme hat wenn zwei Programme die Lib gleichzeitig nutzen. Mit dem Clipboard ist es natürlich etwas schwierig. Hier würde sich evtl. utf-8 anbieten, wie für alle OS funktionen, dann bräuchte man keine extra Funktion. Allerdings müssten die Funktionen irgendwie wissen, dass es utf-8 ist, und nicht ISO-xzy etc. Evtl. wäre das ein Fall für die locale.library? -- 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 - ] |
|
13.05.2009, 11:53 Uhr Thore Posts: 2266 Nutzer |
Ja das Clipboard handeled UTF-8. Ich kann heute Abend mal ein paar Tests damit machen, ob es Probleme beim Kopieren gibt. Wie die API aussieht kann ich nicht sagen, hier verweise ich auf die Programmierer von MorphOS oder jemanden der das neueste SDK hat. [ - Antworten - Zitieren - Direktlink - ] |
|
13.05.2009, 19:46 Uhr Thore Posts: 2266 Nutzer |
Kopiertest: Zum Test wurden verwendet: OWB, MorphOS Editor, Multiview, MorphOS2.2 Als 1-Byte-Zeichen bezeichne ich hier die Darstellung von UTF-8 Zeichen in ISO-8859-1 Codierung, sprich "Sonderzeichen statt Unicode" 1. Test: Kopieren aus OWB von chinesischem Text (zhongwen 中文) ins Clipboard, einfügen in MorphOS Editor. Dort werden die Zeichen als 1-Byte-Zeichen eingefügt, da der Editor kein UTF-8 beherrscht. 2. Test: Anzeigen des Textes aus dem Editor mittels Multiview: Zeigt chinesisch korrekt an. 3. Test: Kopieren von chinesischem Text aus Multiview und Einfügen in OWB: Wird korrekt dargestellt. 4. Test: Kopieren von ISO-8859-1 Text (mit Umlauten ä, ö, ü und ß) aus Multiview und Einfügen in OWB wird korrekt gemacht 5. Test: Einfügen von ISO-8859-1 Text und nachträglich UTF-8 Text aus OWB in den Editor und Anzeigen in Multiview bringt ISO-8859-1 Text, die UTF-8 Zeichen werden als 1-Byte-Zeichen dargestellt, was in diesem Fall korrekt ist. Umstellen von Multiview auf UTF-8 bringt Abhilfe für die Sonderzeichen. 6. Test: Kopieren dieses Mischtextes aus Multiview und Einfügen in OWB ergibt ebenfalls nur ISO-8859-1 Text. Umstellen von Multiview auf UTF-8 und anschließendes Kopieren zeigt UTF-8 Text richtig an. Fazit: UTF-8 lässt sich zwar mit dem MorphOS-Editor nicht erzeugen, doch Multiview geht damit recht gut um. Catalog konnte ich noch nicht testen, da SimpleCat immer abgestürzt ist beim Importieren.... [ - Antworten - Zitieren - Direktlink - ] |
|
13.05.2009, 21:29 Uhr jolo Posts: 110 Nutzer |
Hi. @Wanderer Zitat: Okay, das dürftest Du mittels UTF-8 und einem Filter um die originale Text()-Funktion sehr leicht hinbekommen. Zitat: Oje, da sind wir beide aber grundsätzlich verschiedener Meinung.  Gerade komplexe Schriftbilder sind darauf angewiesen, dass die Non-Spacing-Marks auf die korrekten Positionen ausgerichtet werden ansonsten wird es unleserlich, nicht für Dich und mich, aber für die Menschen die diese Sprache beherrschen. Zitat: Das geht mittels UTF-8 und einem Filter um die Text()-Funktion. Zitat: Die Frage ist dann nur, welche Zeichen willst Du vordefinieren. Im Prinzip machst Du nämlich nichts anderes als einen Zeichensatz (Font) zu erstellen, der eine Untermenge an Unicode-Charakteren enthält, wie schon ein paar tausend FreeType und TrueType Zeichensätze. Wäre die FreeType2-Bibliothek nicht so komplex und ihre Benutzung ein wenig einfacher, würde ich Dir diese empfehlen. Du kannst ja erst einmal mit einer eigenen Zeichensatz-Implementierung beginnen und zu einem späteren Zeitpunkt die Benutzung der FreeType2-Bibliothek in Betracht ziehen. Zitat: Relativ einfach durchzuführen. Lade alle Dokumente als UTF-8 Texte, falls sie in diesem Format noch nicht vorliegen, konvertiere sie beim Laden. Du kannst nach wie vor die Text()-Funktion für Werte im Bereich 0 bis 127 verwenden, auch die normalen Funktionen zur Ermittlung der Zeichenbreite. Errechnete Werte im Bereich 128 bis 255 kannst Du auch noch mittels Text() ausgeben, allerdings nur über einen temporären Puffer, und erst bei Werten im Bereich von 256 bis einschließlich 1114109 kommt dann Dein 'Custom-Rendering' zum Einsatz. Zitat: Normalerweise kommt die FreeType2-Bibliothek als Linker-Bibliothek zum Einsatz. Eine offiziell genormte Schnittstelle für Amiga-Shared-Libs ist mir nicht bekannt, kann mich aber täuschen. Im Aminet müsste die FreeType2-Bibliothek sowohl als Linker- als auch als Shared-Lib für OS3 zu finden sein. Wie gesagt, ob die Schnittstelle genormt ist, entzieht sich meiner Kenntnis. Zitat: Soweit ich weiß benutzt MorphOS2.x TTEengine2 und die hat nicht mehr viele Gemeinsamkeiten mit TTEngine1 für OS3. @Wanderer Zitat: Betrifft nur TTEngine1. TTEngine2 krankt nicht daran. Zitat: Unter OS3? Nee, leider nicht. Die Identifizierung eines UTF-8 Textes musst Du leider selber vornehmen. Ist aber nicht sehr schwer. Alternativ kannst Du auch die CodeSets-Bibliothek dafür verwenden. Grüße [ - Antworten - Zitieren - Direktlink - ] |
|
13.05.2009, 21:50 Uhr Thore Posts: 2266 Nutzer |
Die Erkennung von UTF-8 Text ist sehr einfach, musste das mal programmieren. Auch die Konvertierung von UTF-8 nach ISO-8859-1 und andersrum, als auch Unicode->UTF-8, UTF-8->Unicode hab ich schon programmiert (mit Umwandlung aus den Unicode-Codepage-Tabellendateien) und ist nicht wirklich so schwer. Was ich als Hürde empfinden würde, wäre tatsächlich die Proportionaldarstellung und dem damit verbundenen Markieren und Kopieren. (Im Clipboard muss es ja gemischt 1 und 2 Byte Zeichen haben und visuell nur einzelne Zeichen markiert) Die weitere Hürde wäre den relevanten Routinen mitzuteilen, welche Texte mit TTEngine und welche mit graphics.lib gerendert wurden. Je nach dem müssen diese anders reagieren (Font-Handling ist anders, TextLength und TextExtend muss angepasst sein, schließen von Font muss entscheiden können obs ein TTFont oder AmigaFont ist...) Ich hab mir vor einiger Zeit mal Gedanken mit dem Thema gemacht, da ich mich mit Schriften befasse und lerne, und dafür UTF-8 auf 68k wollte. Ich bin zum Entschluss gekommen, daß eine neue diskfont.library vonnöten wäre(oder entsprechende Patches, da hier ein Glyph nur ein Byte groß sein kann), und zusätzlich die Patches der graphics.lib. Ein wenig Aufwand also... [ - Antworten - Zitieren - Direktlink - ] |
|
13.05.2009, 22:10 Uhr Der_Wanderer Posts: 1229 Nutzer |
UTF-8 lässt sich nicht mit 100%iger Sicherheit bestimmen. Der Text könnte ja auch tatsächlich diese Kombination von Zeichen enthalten. Und wenn wir Text() patchen, dann bekommt man ja nicht einen langen Text sondern möglicherweise sogar nur einzlene Buchstaben oder Wörter. Aber besser als gar nichts. So könnte man z.B. die Text() (und Verwandte) patchen, dass die im Falle einer positiven UTF-8 Identifikation auf TTEnigne oder Freetype zurückgreifen. Das ganze kann man dann ja in AfA packen. AfA benutzt ja sowieso schon freetype2.library. Einziges Problem ist die diskfont.library, die es nur erlaubt 256 Glyphs zu cachen. D.h. man müsste diese auch modifizieren damit sie entweder mehr cached oder die 256 Zeichen dynamisch verwendet. Für den Editor ist das ja kein Problem, da ich den ja selbst schreibe. Dort würde ich mit 16bit Characters arbeiten. Ein Editor, der von UTF-8 keine Kenntnis hat, würde dann den Text sogar richtig Anzeigen, sich allerdings möglicherweise komisch Verhalten wenn man anfängt zu editieren. Wenn er sauber implementiert ist, würde das aber kein echtes Problem darstellen. Alternative wäre, wenn man dem Text() immer einen BOM vornedran hängt, wenn man will dass es als UTF-8 interperetiert wird. (BOM = byte-order-marker). Bei UTF-8 sind das drei spezielle 8bit Zeichen () die so im Text eigentlich nie auftreten. Nachteil: Wenn ich einen Teilstring zeichnen will (wie z.B. bei Syntax highlightning ständig der Fall), müsste ich den String immer umkopieren vor dem Zeichnen. Aber auch besser als gar nichts! Beispiel: Text("Tatütata") => Tatütata (wie gehabt als Codepage) Text("Tatütata") => Tatütata (UTF-8 interpetiert)  ist der BOM für UTF-8. -- 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 13.05.2009 um 22:53 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 10:14 Uhr Holger Posts: 8116 Nutzer |
Zitat:Der Unterschied liegt darin, dass man diese Outline-Fonts erst rastern muss. AOS3.x unterstützt nur das Rastern in ein Zeichensatz mit 256 Zeichen, außerdem kostet das Rastern auf 68k Systemen seine Zeit. Prinzipiell ist das natürlich nichts anderes als die zweite Hälfte dessen, was man implementieren müsste, wenn man Unicode-Strings via bullet-API rendern will. Schließt sich also nicht aus. Zitat:Natürlich muss die shared-lib ein dokumentiertes API haben, sonst wäre sie ja wertlos. Zitat:Ich würde darauf verzichten, eine fehleranfällige Rateroutine zu implementieren. Das Clipboard benutzt IFF-FTXT, also ein erweiterungsfähiges Format. Man müsste nur einen neuen, optionalen Chunk definieren, der das Encoding definiert oder einen, der eine alternative Unicode-Repräsentation des im im Standard-Chunk verbleibenden latin-Textes erlaubt, und alle Programme, die das unterstützen, könnten Unicode via Clipboard austauschen, ohne dass andere Programme gestört werden. Zitat:Ging es nicht eben noch um die Unterstützung im eigenen Programme, mit Bordmitteln? Und jetzt soll gepatcht werden? Zitat:Wenn Du der Text()-Funktion ohnehin irgendwie verklickern musst, dass Du weißt, was Du tust, und UTF-8 meinst, reicht ein Flag im RastPort vollkommen aus, um den Modus umzuschalten. Dieses Flag setzen natürlich nur die Programme, die es kennen... mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 10:32 Uhr Thore Posts: 2266 Nutzer |
Zitat:Doch auch. Wenn jemand einen Texteditor auf TTEngine-Basis baut, der auch Copy n Paste beherrscht, wäre das doch mal ein Anfang. Doch dann werden sicher Stimmen laut, daß man es noch hier und da benutzen können sollte, dann wird wieder das patchen ein Begriff sein. Ausreichend wäre (jedenfalls für mich) momentan mit UTF-8 Unterstützung: - text.datatype - amigaguide.datatype - TextEditor - WebBrowser BTW: Kann OWB für OS3.9 auch UTF-8 (nur reine Interesse, diese Frage)? [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 10:58 Uhr Holger Posts: 8116 Nutzer |
Zitat:Dann würde ich ein Ersetzen exakt jener Komponenten/Programme mit Versionen, die UTF-8 beherrschen, gegenüber jeglicher Art von Patch bevorzugen. Zitat:Ich vermutet mal ganz stark, ja. Allerdings würde ich nicht auf Clipboard-Support wetten. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 12:11 Uhr Der_Wanderer Posts: 1229 Nutzer |
Die Frag ist halt, ob es besser ist wenn der Berg zum Prophet kommt oder der Prophet zum Berg. Beispiel: Nehmen wir an, man erweitert die Text() Funktion so, dass sie bei UTF-8 Detektion (implizit oder explizit durch BOM) Unicode ausgibt, dann wäre es realtiv einfach, in einem Program Unicode zu unterstützen und es wäre abwärtskompatibel. Auch das Clipboard braucht nichts davon zu wissen. Wenn man es per TTEngine implementiert, dann kann das die eigene Software, aber das nächste Program X müsste den gleichen Aufwand nochmal treiben. (wobei TTEngine offenbar unter AmigaOS3 buggy ist...) Via AfA OS wäre die erstere Variante kein Problem, da die Funktionen ja sowieso schon erstetzt werden. Zweitere Variante wäre allerdings unabhängig vom OS. Tja... Oder wie wäre es denn mit einer neuen "bullet.library", die Textrenderings immer als UTF-8 interpretiert. Dann muss man nur eine Font erstellen, sagen wir "Amiga Arial Unicode" (analog zu MS Arial Unicode ;-). Und wenn man diese Font auswählt, erhält man Unicode Ansicht, ansonsten wäre der UTF-8 uninterpretiert sichtbar. Wenn ich dann also im Texteditor Unicode betrachten will, muss ich ihn auf diese Font stellen. Nur kann man dann leider keine Unicode Zeichen tippen, bzw. nur auf Umwegen. -- 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 14.05.2009 um 12:15 Uhr geändert. ] [ Dieser Beitrag wurde von Der_Wanderer am 14.05.2009 um 12:17 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 12:34 Uhr Thore Posts: 2266 Nutzer |
Unter gewissen Win-Programmen wird UTF-8 auch falsch interpretiert, während andere Programme, z.B. Kate unter Linux oder Editor auf MorphOS das richtig machen. Ich sag nur "Keiner mag die Hüter" in Notepad... Unter MorphOS wird auf den BOM auch verzichtet beim Copy n Paste. Zurück zu OS3.x Es gibt eine IME für UTF-8, allerdings glaube ich nur für europäische Zeichen (http://aminet.net/package/util/misc/UTF-8) In diesem Fall ist es ein patch für das input.device. Ein Systempatch für UTF-8 ist generell besser, aber wohl schwieriger umzusetzen, es müssen auch interne Strukturen angepasst werden (wie schon beschrieben die 256 chars der diskfont.lib erweitern oder gfxlib Flags mitgeben ob UTF-8 und TTF). Programme und Komponenten mit UTF-8 zu erstellen ist weniger aufwendig und systemfreundlicher, jedoch nicht global verwendbar. Und warum sollte man nicht auch beide Lösungen gleichzeitig anbieten können 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). [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 12:37 Uhr Der_Wanderer Posts: 1229 Nutzer |
Ja, die blosse Konvertierung bringt eigentlich nichts, wenn man nicht auf der eigenen Codepage bleibt, und dann wiederum braucht man UTF-8 nicht unbedingt. AfA, AROS und MOS verwenden ja die gleiche diskfont source. Wenn es also jeamdn in angriff nimmt, wäre vielen damit geholfen. BTW, AfA kann man ja auch unter OS4 einstetzen ;-) 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. Nur beim löschen ist das blöd, da fehlt ja die Information dass es sich um UTF-8 handelt. Das müsste der Editor aktiv unterstützen... -- 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 14.05.2009 um 12:39 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 13:50 Uhr Holger Posts: 8116 Nutzer |
Zitat:Wie Du schon selbst sagst, befindet sich der BOM nur am Anfang des Textes und das Ganze schlägt fehl, sobald nur ein Teil des Textes dargestellt wird, wie es bei jedem mehrzeiligen Text der Fall ist. Und spätestens, wenn ein Programm versucht, einen Zeilenumbruch zwischen zwei bytes eines multibyte-Zeichens einzufügen, knallt es. UTF-8-Support kann man einem Programm nicht durch die Hintertür beibringen. Du kannst es bestenfalls auf den ersten Blick aussehen lassen, als ob es funktioniert. Zitat:Dafür gibt es shared libraries. Zitat:Die "bullet.library" kann kein UTF-8 interpretieren, weil die "bullet.library" nur einzelne Zeichen interpretiert. Die sind unter AOS3.x Unicode, beschränkt auf BMP0. Zitat:Du verwechselst hier Zeichensatz mit Kodierung. Und bevor ich einen Unicode-Zeichensatz selbst entwerfe, sich ich im Netz nach einem freien... Zitat:So funktioniert das nicht. Selbst, wenn man die "bullet.library" so erweitern könnte, was wie gesagt prinzipiell nicht geht, hast Du das Problem, dass die Programme überhaupt nicht das bullet-API benutzen, sondern direkt oder indirekt die graphics.library. Zitat:Solange die diskfont.library nichts weiter macht, als einen 8Bit-Rasterfont zu erstellen, hilft das alles nichts. Du brauchst ein Format, dass mehr Zeichen erlaubt, und Du brauchst einen Mechanismus, Zeichen on demand zu rastern und bei Nichtbenutzen wieder freizugeben, denn Du willst nicht bis zu 100.000 Zeichen im Speicher halten, wenn vielleicht 300 benutzt werden. Zitat:Eben. Und wenn auch nur ein Aspekt eine aktive Unterstützung erfordert, kannst Du das automatisch unterjubeln vergessen. Bleibt also unterm Strich nur entweder richtigen Support oder gar keinen. mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 14:46 Uhr Der_Wanderer Posts: 1229 Nutzer |
Holger am 13. Mai: > Warum muss es "alles oder nichts" sein? Holger am 14. Mai: > Bleibt also unterm Strich nur entweder richtigen Support oder gar keinen. Hehe, so schnell kann einen das "Geschwätz von Gestern" einholen ;-) Wie auch immer, im Prinzip haben hier ja alle Recht. Nur eine Lösung hat keiner, einschl. mir. Die einzig "richtige" Lösung wäre, für alle Text() Funktionen eine Unicode Variante einzuführen. Also TextW(), TextLengthW(), etc., aber auch OpenW(), LockW() etc. (so ist das bei Win32 auch gelöst) Fürs Clipboard könnte man einen 8bit Text und einen 16bit Text Chunk einfügen, sodass Abwärtskompatibelität verhanden bleibt. Oder Codepage und UTF-8. Das Problem ist halt nur, das plattformübergeifend (OS4, OS3, MOS, AROS) unter einen Hut zu bekommen. Das Problem sehe ich hier bei OS4, allen anderen könnte man das beibringen (AROS ist OpenSource, MOS teil sich die Sourcen mit AROS, und OS3 wird via AfA OS erweitert). Vielleicht kann man ja mal eine Petition bei Hyperion einreichen, ob sie bei einer kompatiblen API dabei wären. Nichts wäre schlimmer als wenn OS4, MOS und AROS eine eigene (oder keine) Lösung entwickeln würden. So gesehen wäre es vielleicht wirklich das beste, für TuiTED das einfach direkt zu Coden, evtl. sogar mit vorgerenderten Bitmaps. Dann greift man nicht ins OS ein und verlang auch vom OS nichts, läuft also überall. -- 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 14.05.2009 um 14:48 Uhr geändert. ] [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 15:45 Uhr Holger Posts: 8116 Nutzer |
Zitat:Das sind zwei völlig verschiedene Dinge. Ein Editor, der UTF-8 richtig beherrscht, aber bestimmte Zeichen nicht darstellen kann oder kein bidi beherrscht, ist unterm Strich brauchbar. Ein Editor, der durch einen Hack UTF-8 nach dem Einladen richtig darstellen kann, aber selbigen durch nahezu jede Bearbeitungsfunktion zerstört und bei dem weder Navigieren, noch Suchen richtig funktioniert, ist unbrauchbar. Zitat:Dir ist aber schon klar, dass 16 Bit bereits überholt ist? Das W impliziert eine unveränderliche Kodierung, nämlich UCS2, die aber nicht zwangsläufig die beste für die jeweilige Aufgabe ist. Und vor allem bei der Interpretation als UTF-16 Spielraum für ähnliche Fehler wie das Reinwürgen von UTF-8 in 8Bit-Text Anwendungen lässt. Für das Bearbeiten eines Unicode-Textes braucht man aber kein Unterstützung von Unicode-Dateinamen. Die Darstellungsfunktionen braucht man, wie gesagt, nicht durch weitere Funktionen zu komplementieren, da es einen Kontext (RastPort) gibt, der zusätzlich Optionen aufnehmen kann. Es reicht also ein Flag oder Encoding-Attribut... Und beim Öffnen eines Fonts werden Tags unterstützt. Zitat:Das wäre nicht schwer. Zitat:Für das Clipboard brächte man keine Erweiterung des OS. Es müssten sich nur genügend Programme an die Konvention halten. Lediglich die Erweiterung des RastPorts wäre betroffen. Wobei da wahrscheinlich schon beim Setzen eines 24Bit-Pens die Funktionen auseinanderdriften. Zitat:Das war ja auch Deine ursprüngliche Frage, oder? Selbst wenn es ein AfA mit einer entsprechenden Funktion gäbe, ändert das nichts daran, dass ein nacktes AOS3.x diese Funktion nicht hat. Natürlich könnte man diese Funktionen auch in eigene Library gießen, die in allen AmigaOS-Varianten funktioniert. Wobei, hat da vielleicht schon jemand dran gedacht? http://aminet.net/package/util/libs/UniLibDev http://aminet.net/package/text/show/Ucode mfg -- Good coders do not comment. What was hard to write should be hard to read too. [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 16:36 Uhr Thore Posts: 2266 Nutzer |
UCode ist ne nette Spielerei, aber nicht ernsthaft zu gebrauchen. Das war mein erstes Unicode Produkt das ich auf OS3.x getestet hab, mit mäßigem Resultat. Was mich wirklich mehr beeindruckt hat ist TTEngine, da hier neben Codepages auch Antialias und Alphablending machbar ist. Ab Version 7.1 ist auch das Problem korrigiert, was bei mehrfachbenutzung der Lib auftrat. TTEngine basiert auf FreeType2. Wie gesagt, eine Unterstützung in den o.g. Komponenten/Tools würde für die meisten Zwecke schon ausreichen. [ - Antworten - Zitieren - Direktlink - ] |
|
14.05.2009, 16:52 Uhr Der_Wanderer Posts: 1229 Nutzer |
Also wenn TTEngline.library 7.2 gescheit funktioniert, scheint mir das der gangbarste Weg zu sein, einen Texteditor mit Unicode-Fähighkeit auszustatten. Ich werde das mal probieren. Die Lib gibts ja überall. -- 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, 19:41 Uhr Thore Posts: 2266 Nutzer |
Wenn bei Dir bei AntiAlias Fonts Farbfehler auftreten musst Du in der config den Gamma-Wert anpassen (Nur für den Fall falls das nicht bekannt ist) [ - 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. |
|
