Hallo nochmal.
Ich habe hier ein höchst nützliches DoIt für alle, die das zweite unten beschriebene Problem haben und gerne korrekte Umlaute angezeigt bekommen wollen. Dies funkioniert soweit ich sehen kann für alle NewYork und Atlanta fonts sowie für die nicht-MS (nicht TTF-) Comic Fonts. Ich weiss allerdings nicht ob es vernünftiger wäre, anstatt der lebenden Instancen eine Änderung im Code anzugehen. Soweit ich feststellen konnte, werden die Instanzen aber nicht 'im normalen Betrieb' erzeugt und es reicht sie einmal zu ändern. Hier das DoIt: | map | StrikeFont allInstances do:[:each| map _ each instVarAt: (each class instVarNames indexOf: 'characterToGlyphMap'). map ifNotNil:[ (each name beginsWith: 'NewYork') ifTrue:[ map at: ($ asciiValue + 1) put: ($ asciiValue). map at: ($ asciiValue + 1) put: ($ asciiValue). map at: ($ asciiValue + 1) put: ($ asciiValue). map at: ($ asciiValue + 1) put: ($ asciiValue)]. ((each name beginsWith: 'Comic') or:[each name beginsWith: 'Atlanta'] ) ifTrue:[ map at: ($ asciiValue + 1) put: 16r80. map at: ($÷ asciiValue + 1) put: 16r85. map at: ($ asciiValue + 1) put: 16r86. map at: ($ asciiValue + 1) put: 16r8A. map at: ($ asciiValue + 1) put: 16r9A. map at: ($ asciiValue + 1) put: 16r9F]]].
Des weiteren glaube ich, dass man bei den TTF Fonts auch was machen könnte. Hier empfiehlt es sich aber definitiv, bei der Erzeugung (also dem Import) anzusetzen. Leider habe ich keine Erfahrungen mit dem FontReader und weiss auch nicht ob ich ihn jetzt unter Linux zum Laufen bringen kann. Ich bin aber der Überzeugung, dass die Änderung in TTFontReader>>processCharMap: passieren sollte. Hier wird noch angenommen, dass das Squeak-Imge auf MacRoman basier, was so ja wohl nich mehr stimmt. Also müsste hier die Fallunterscheidung dahingehend modifiziert werden, das genau im anderen Fall eine Umwandlung (in genau die andere Richtung) passiert. In etwa so: TTFontReader>>processCharMap: assoc "Process the given character map"
| charTable glyph cmap | cmap _ assoc value. charTable _ Array new: 256 withAll: glyphs first. "Initialize with default glyph"
assoc key = 1 ifTrue: "Mac encoded table" [1 to: (cmap size min: charTable size) do: [:i | glyph _ glyphs at: (cmap at: i) + 1. charTable at: (self macToWin: i) put: glyph]].
assoc key = 3 ifTrue: "Win encoded table" [1 to: (cmap size min: charTable size) do: [:i | glyph _ glyphs at: (cmap at: i) + 1. charTable at: i put: glyph]]. mit TTFontReader>>macToWin: anInteger "analog zu winToMac:" ^ (index - 1) asCharacter squeakToIso asciiValue + 1
^ charTable
HTH, Torge
On Fri, 27 Jun 2003 11:02:41 +0200, Torge Husfeldt torge.husfeldt@gmx.de wrote:
Hallo Leute,
Ich weiss nicht ob das Problem schon anderweitig gelöst wurde, aber in Zusammenhang mit Umlauten habe ich hier auf der Liste immer mehr Fragen als Antworten gelesen. Hier also mal eine Antwort: Kontext: In dem vorbereiteten Demo-Image von
http://swiki.squeakfoundation.org/squeak-ev/84 http://www.ira.uka.de/~marcus/SqueakDeutsch.zip
Ist die Eingabe von Umlauten 'gestört'. Das liegt m.E. daran, das auf detuschen OS/VM-Kombinationen meistens keine multi-character-keycodes für die Umlaute erzeugt werden un Yoshiki diese Möglichkeit nicht ausreichen berücksichtigt hat. Lösung: Ein 'dirty hack' der für mich unter Linux ganz gut klappt, ist in der Methode HandMorph>>generateKeyboardEvent: An dem letzten umfassenden ifTrue: Block noch ein ifFalse mit folgendem Inhalt anzuhängen: keyValue _ keyValue asCharacter squeakToIso asciiValue. Das ist so ähnlich auch das was Yoshiki im Fall mit multi... macht. Changeset ist angehängt. Ein weiteres Problem ist, dass Umlaute in allen anderen als den default... Zeichensätzen nicht korrekt angezeigt werden. Wenn man sich solch einen String dann aber greift und (z.B. in einem Inspector) anzeigt, erkennt man, dass Squeak sich durchaus im klaren ist, dass da ein Umlaut kommen soll. Hier hilft es wohl nur, für die fehlerhaften Zeichensätze die Glyph- Tabelle zu reparieren. BTW ich habe das Gefühl, dass es einen Unterschied macht, ob die Zeichensätze Default... heissen. Ich meine ich hatte mal einen Fall, da war das Zeichen korrekt angezeigt, aber der printString vom Zeichensatz war genau der gleiche, wie bei einem anderen, nicht korrekt angezeigten, der wohl unter seinem spezifischen Namen referenziert wurde (wie NewYork10 12 oder so).
HTH, Torge
P.S.: Gute Arbeit! P.P.S: Habe auch noch zwei kleine Korrekturvorschläge für addGermanVocabulary angehängt. Zum Wiederfinden am besten diffen.