Deutsche Umlaute, Frage z.B. an die EARWIGO-Programmierer

Hallo miteinander,
Kann mir jemand erklären, ob ich mit dem richtigen ("nativen") LUA-String deutsche Umlaute (ÄÖÜäöüß) ausgeben kann.
Ich habe etwas in der "Earwigo - WWB - the Wherigo™ Web Builder"-Group mitgelesen und deshalb meine Frage an die Fachleute in dieser Ecke:
Gibt es ein Tabelle welches Gerät (Emulator, PPC, Garmin Oregon, Garmin Colorado, Android Wheryougo, Iphone PIG) welche Kodierung verwendet, oder kann die jemand zusammenstellen?
Ist es dann möglich, wenn ich die entsprechenden Bytes im einem LUA-String verwende, dass ich Umlaute bekommen?

Über eine Erklärung oder einen Link mit den Infos, würde ich mich freuen.
docfred

Beim Oregon ist es so, dass selbst eine direkte Eingabe im lua-Code Umlaute nicht korrekt dargestellt werden.
Vllt können sie aber als Sonderzeichen maskiert werden (ähnlich UML oder HTML).
Die Frage wird aber immer sein, ob der Player das versteht.

Earwigo kriegt das hin - meines Wissens auch auf Garmin - also muss das m.E. mit LUA hinzubekommen sein, wenn man z.b. weiß, welche locale-Funktionen etc. ausgeführt werden müssen auf welchem Gerät.
(LUA: os-Packages, os.setlocale ???)

Wenn man von Earwigo generierten Source-Code nimmt mit Umlauten, müsste man eigentlich da auch
sehen können, wie man so etwas macht. Vielleicht stellt ein Earwigo-Programmierer mal sein gwz zur
Verfügung.

so schwer ist das nicht aber am Ende doch sher aufwändig, möchte man ein ganzes Projekt mit Sonderzeichen umsetzen.


ergibt auf dem Oregon:

o.K. mit dem ° habe ich mich vertan, das muß am Anfang eine 176 sein.

nicht wundern, im Emulator sieht es so aus:


Möchte man das im Urwigo umsetzen, dann muß man sich Variablen mittels Benutzerdefinierten Code anlegen und über Verketten in die Dialog/Messageboxen an die entsprechende Textstellen einbauen.

Sabeta

Man kann die Umlaute auch direkt (Hexadezimal) in die gwc-Datei schreiben, dann darf man die Textcodierung von Urwigo nicht nutzen.

Generell ist die Umlautgeschichte ein hausgemachtes Problem von Urwigo, die Textcodierung geht nur bis 7F (127) und die Sonderzeichen kommen dahinter, desweiteren maskiert Urwigo Sonderzeichen schon vor der Umsetzung in eine gwc-Datei.

Theoretisch, das möchte ich jetzt aber nicht testen, kann man auch codierte Texte ändern, da alles über 7F nicht angefasst wird, nur ist es eben recht schwer die entsprechende Textstellen im Codierten Text zufinden. Umgesetz werden Sonderzeichen generell als 3F ein "?", weshalb z.B. auch das ° zum ? wird.

Abschliesend noch die HEX-Dump, Hex0 ist das Beispiel mit string.char, hex1 das Beispiel bei dem ich direkt die Umlaute reingeschrieben habe (die Reihenfolge der Sonderzeichen habe ich nicht beibehalten).

Sabeta

Hallo Sabeta,
der Emulator selbst ist dann nie zur Ausgabe von Umlauten zu bewegen?
docfred

Wenn es um den Emulator vom Urwigo und den üblichen Weg geht (Taste-F5), dann hat man in der Tat keine Chance. Der Emulator des Wherigo Builders hingegen zickt nicht und stellt brav die Umlaute dar. Es ist wie schon oben erwähnt ein Problem des Urwigo-Programms. Ich habe sogar mal frech die gwc-Datei für den Urwigo-Emulator ausgetauscht, Ergebnis die oben abgebildeten Rauten.

Nun habe ich mir mal den Hex-Code vom Wherigo-Builder-gwc angesehen und sieh da der Text 123äß°Ö wird Hexadezimal als 31 32 33 C3A4 C39F C2B0 C396 umgesetzt. Es gibt also zwei Varianten (und mit string.char sogar drei) wie Umlaute und Sonderzeichen umgesetzt werden können. Aber keine der drei Möglichkeiten lassen sich ohne große Umstände im Urwigo anwenden, da muß der Programmierer vom Urwigo selbst hand anlegen. Ich habe teilweise Sätze, in denen 4 Umlaute und das ß vorkommt, wenn ich das im Urwigo mit Verketten einbasteln würde, wäre ich wohl verrückt.

Sabeta

Außer man würde die Texte konsequent in Lua-Tables auslagern und mit einer user-funktion laden - dann könnte das gehen oder?

bodenseepingu schrieb:

Außer man würde die Texte konsequent in Lua-Tables auslagern und mit einer user-funktion laden - dann könnte das gehen oder?

Zum Vergrößern anklicken....

Du darfst den Urwigo allerdings nicht vergessen.

Das einzige was ich bisher in der kurzen Zeit geschafft habe ist folgendes, den Text als Variable ablegen, da auch hier Urwigo zuschlägt die Umlaute maskieren, ich habe es hier mit einem "-" getan. Die Variable dann per Dialogbox ausgeben wobei die Variable zur Laufzeit berichtigt wird, ich habe hier nur die kleinen Umlaute als Beispiel eingebracht, man müsste das entsprechend erweitern.

Die Variable heißt TXT

Wenn ich an seine K-üsse denke k-önnte ich den ganzen Tag l-ächeln.

-Örtliche Bet-äubungen oder -ähnliches k-önnen -Übelkeit hervorrufen.

M-üssen M-änner -öfter Duschen?

M-ühlheim-K-ärlicher B-ürger k-önnten gr-üne Gr-ütze r-ühren, f-ür K-ölner w-äre -ähnliches m-öglich.

Zum Vergrößern anklicken....

man kann natürlich das Ganze auch als allg. Funktion schreiben, ich habs eben nur aus Bequemlichkeit direkt in die Dialogbox als Einzeiler geschrieben.

Wichtig, es funktioniert nur mit User-Variablen das man einfach ein - vor dem umlaut schreibt, schreibt man eigene Variable im benutzerdefinierten-Code werden aus den Umlauten sofort ? so das man hier die Umlaute von Anfang an als -a -u -o usw. schreiben muß. Letztlich ist es egal wie man es macht.

Sabeta

Das war bisher auch meine einzige Idee, dass man die Korrektur erst zu Laufzeit vornimmt. Ist allerdings ganz schön umstandlich.
docfred

Hier noch eine weitere Variante, allerdings weiß ich hier noch nicht ob es auf allen Geräten funktioniert. Am Wochenende kann ich das aber mal testen.

Mit Zeilenumbruch

klassisch ohne Zeilenumbruch

beides als Benutzerdefinierten Ausdruck direkt in der Dialogbox anzuwenden.

Prinzip ist hier, dass die hinteren Werte (ASCII-Code) an Stelle der Platzhalter %c eingesetzt werden.

Sabeta

Hallo Sabeta,
hab deinen String zur Laufzeit an einen item.description-Text an gehängt.
Das ist ein Garmin Oregon, da klappt es. (das "angehangt" ist URWIGO)
Für Tastatur-Texte ("Nächste Seite") wird das so allerdings nicht funktionieren, da die zur Laufzeit nicht geändert werden können. Aber das ist für wichtige Texte, z.B. Eigennamen mit Umlauten (die kann man nicht einfach umschiffen) schon ein Lichtblick. Ich möcht z.B. was mit einem Schachspiel in meinen WIG einbauen und das Wort "König" kann nicht so einfach durch ein umlautfreies Wort ersetzt werden. Man müsste auch prüfen, ob Texteingaben irgenwie gehändelt werden können.

Wenn man eine Routine bastelt (mir schwebt allerdings eine Funktion (string= umlaut(sting) vor, die durch Markierungen (z.B. &A=Ä, &a=ä.,... &s=ß) den Urwigotext übersetzt. Ich kenn mich mit dem Gesamt-table-Model eines WIG noch nicht wirklich aus, aber vielleicht ist es sogar möglich diese Funktion beim Start der Cartrige einfach über alle .descriptions .name drüber laufen zu lassen. Da wäre das Ganze händelbar.
Allerdings hab ich meine Zweifel, wenn ich die EARWIGO-Posts zum Iphone lese, ob alle Geräte die gleiche Kodierung verwenden.

Muss diese Frage eigentlich beantwortet werden? ps:
docfred
P.S. Kann man auf dem Oregon Screenshots machen?

Nur zur Frage Screenshots aufm Oregon.
Ja kannst du machen. Bei Einstellungen-->Anzeige-->Screenshot an
Danach wird jedes mal wenn du die Powertaste kurz drückst ein Screenshot gemacht.
Diese Bilder werden Garmin/scrn abgespeichert.

Man muss aber noch dazusagen, dass wenn man Screenshots aktiviert hat, man die Hintergrundbeleuchtung die man ebenfalls durch einfaches drücken der Powertaste regeln kann, nicht mehr geht.

>Allerdings hab ich meine Zweifel, wenn ich die EARWIGO-Posts zum Iphone lese,
>ob alle Geräte die gleiche Kodierung verwenden.
Du hast gleich. Colorado/Oregon = WIN-1252 (fast ISO-8859-1 aber mit noch ein Paar karakter dabei). PocketPC/Emulator = UTF-8. WhereYouGo (Android)/DesktopWiG = ungefähr UTF-8, aber mit speziellen Java-Unicode-bugs. iPhone = ungefähr UTF-8, aber mit (anderen) speziellen Java-Unicode-bugs.

Heute laufen Umläute ungefähr OK mit Earwigo auf Garmin, PPC, und WhereYouGo, aber /a/ nicht auf iPhone mit "Obfuscation" (anti-disassembly) und /b/ für Garmin muss man noch immer einen zweiten Cartridge hochladen bei Wherigo.com, denn der GWC-file ist noch kein "one size fits all".

Die nächste Earwigo-Release - kommt bald! - wird es (hoffentlich) möglich machen, /a/ auf alle Players Umläute zu nutzen, auch mit "Obfuscation", und /b/ mit einem .GWC file auf alle Platforme zu drehen. Es hat "Reverse Engineering" gekostet...

Vielen an sTeamTraen,
das war genau das, was ich wissen wollte.

Eine Frage an euch: Wäre es nicht möglich eine Funktion zu programmieren, die beim Start der Cartridge den Device-Typ abfrägt und dann ggf. in allen Strings die Sonderzeichen konvertiert?

Dann wäre der weg zur Plattform unabh. Cartridge doch nbicht mehr weit?

docfred

docfred schrieb:

Eine Frage an euch: Wäre es nicht möglich eine Funktion zu programmieren, die beim Start der Cartridge den Device-Typ abfrägt und dann ggf. in allen Strings die Sonderzeichen konvertiert?

Zum Vergrößern anklicken....

So ungefähr lauft (jetzt) meine Lösung; aber, weil ein .GWC-file im Prinzip nach 1-2-3 Jahr auf einem neuen Player abgespielt werden kann, probiere ich auch ein bisschen "Future-Proof zu denken, z.B. durch ''wie lang ist der string "\192\182"' zu fragen. (Antwort: 2 bytes auf Garmin/PPC, 1 byte auf WhereYouGo, Crash *beim Einladen* des Carts auf iPhone - willkommen zur magischen Welt der unterschiedliche Realisierungen von Unicode durch verschiedene Java-runtimes. Jetzt frage ich, 'wie lang ist der string "\224\160\128"?' - Antwort: 3 auf Garmin.PPC, 1 auf iPhone, 1 auf WhereYouGo, hoffentlich 1 oder 2 oder 3 oder im jeden Fall kein Crash auf dem nächsten Red-Hot Player Platform).

Das schwerigste ist übrigens nicht das umsetzen UTF-8/Win-1252, sondern das abhandeln des Newlines bzw. &-Zeichen, denn jeder Player hat eine eigenen Beziehung zwischen HTML und ASCII. Für ein Newline auf Garmin und PPC muss man z.B. "\060BR\062\010" richtung Bildschirm werfen; auf Garmin ist "&" als "\038amp;" dargestellt, auf PPC dagegen "\038amp;\038amp;".

An dieser Stelle ist EARWIGO den anderen Umgebungen dann weit voraus! Cool!
Geht den das zur Laufzeit auch mit den Command-Button Texten?
Wie ist das mit der Eingabe von Umlauten?
Ihr (Das heisst ja Team) habt euch ja intensiv mit dem Thema Kompatibilität beschäftigt. Was fehlt denn noch auf dem Weg zur Universalcartridge, wenn man die bekannten Eigenheiten der Player berücksichtigt, bzw. meidet. (Das Soundproblem ist ja "lösbar".)?

Vielleicht habt ihr ja Lust etwas Input in das entstehende WIKI zu geben.

docfred

docfred schrieb:

Geht den das zur Laufzeit auch mit den Command-Button Texten?

Zum Vergrößern anklicken....

Meistens ja. Auch fremd; Bei PocketPC/Emulator ist der Ur-input in Win-1252 kodiert, das muss in UTF-8 umgesetzt werden.

docfred schrieb:

Wie ist das mit der Eingabe von Umlauten?

Zum Vergrößern anklicken....

Eingabe von Freitext? Dass soll laufen, meine ich, habe nie getest. Aber auf Colorado (...) ist es unmöglich denn Umlauten kommen einfach nicht auf der "Tastatut" vor. Man soll also auch ae, oe, ue, ss als "richtig" akzeptieren.

docfred schrieb:

Was fehlt denn noch auf dem Weg zur Universalcartridge, wenn man die bekannten Eigenheiten der Player berücksichtigt, bzw. meidet. (Das Soundproblem ist ja "lösbar".)?

Zum Vergrößern anklicken....

Eigentlich nicht zu viel: Image-Size bzw. Sound ist doch ein Problem denn das automatisch wiederkompilieren durch Wherigo.com erkannt heute nur zwei Platforms (Garmin/PPC). Ein "vanilla" .GWC file lauft, ist aber dann nicht "personalised" mit Wherigo.com-Username -> Probleme beim "Completion".

Zumindest an einer Stelle besteht Hoffnung für Urwigo: Man sollte über die in
http://www.das-wherigo-handbuch.de/...Objekte_einer_LUA-Datei_ausgeben_/_bearbeiten beschriebene Methode alle Namen und Descriptions von Objekten
bearbeiten können um damit z.B. &a mit ä zu ersetzen - natürlich muss das Player-spezifisch gemacht werden.

Vorher würde ich aber empfehlen, auf allen möglichen Playern zu prüfen, ob das grundsätzlich so geht.

Für Messageboxen sehe ich etwas Probleme, weil es hier keine Objekte gibt - da muss man dann die Texte
in tables auslagern und genauso über diese drübergehen..

Auf http://www.das-wherigo-handbuch.de/index.php?title=Deutsche_Umlaute_mit_Urwigo gibt
es die erste Cartridge (Urwigo) zum Testen für deutsche Umlaute.

Auf der Seite ist alles wichtige beschrieben.

Bitte um Freiwillige, die für verschiedene Geräte durchtesten insbesonders
- gibt es auf verschiedenen Geräten unterschiedliche Darstellungen der deutschen Umlaute - über das Item Codetabelle könnt ihr die Werte für äöüßÄÖÜ ermitteln - implementiert wurde momentan für Whereyougo/OpenWig
- werden die verschiedenen Geräte korrekt unterschieden - hier ist noch was zu tun - I-Phone hab ich noch nicht implementiert
- Für welche Objekte funktioniert die Umlaut-Ersetzung bzw. für welche nicht - im Moment konnte ich Inputs noch nicht erfolgreich testen, für Kommandos kann ich mir vorstellen, dass es vielleicht auch noch Probleme macht
- gibt es für bestimmte Geräte Abstürze - auch der Emulator hat (unverständlicherweise) gezickt - hier bräuchte ich noch Angaben, was ich bei welchen Geräten ggf. nicht machen darf.