[Allegro] Re: <Alt>+m-Mechanismus nicht invariant gegen'fcharset...' in spchr.rtf?

[Thomas Berger]

Am 04.06.2013 23:37, schrieb Andreas Wolf:
> Hallo.
> 
> Ich habe das an einer konkreten Datenbank nachvollzogen:
> 
> A. Die Daten sind allesamt in Windows 1250 konvertiert.
> 
> B. allegro wird mit 'set DArial Unicode MS=238' gestartet.
> 
> C. Alle '*head.rtf' sind auf Arial Unicode MS mit charset=238 gesetzt.
> 
> D. Die 'spchr.rtf' ist auf Arial Unicode MS mit charset=238 gesetzt.
> 
> E. Alle Daten und die 'spchr.rtf' werden korrekt angezeigt.
> 
> Und es funktioniert: NICHT bzw. genau so wie es Heinrich Allers beschrieben
> hat. Immer nur Fragezeichen.
> 
> Frage: Wer 'regiert' eigentlich bei den Funktionen <alt>+m bzw. <strg+c>
> bzw. <strg>+v  in allegro ?
> 
> Gibt es da einen festverdrahteten Font im Sourcecode vielleicht ?

Da a99 mit 8bit-Zeichensatz arbeitet, regiert entweder die fuer
den Rechner eingestellte Standardcodepage (typischerweise CP 1252)
oder CP 1252.

Da Windows intern mit Unicode arbeitet, weiss es ganz genau dass
ein L mit Stroke, auch wenn es in irgendeiner anderen 8bit-Codepage
notierbar ist, das Unicode-Zeichen U0141 *ist* und daher in
CP1252 nicht abbildbar ist.

Es ist schon lange nicht mehr so, dass via Zwischenablage das nackte
Byte (was es ja oft gar nicht ist) entsprechend der Codierung des
Quellfensters speichert, die Codierung vergisst und dasselbe Byte
ohne Beruecksichtigung der eingestellten Codierung in das Zielfenster
kopiert. Und man kann natuerlich auch nicht erwarten, dass Windows
die Spezialitaeten des allegro-Windows-Zeichenatzes kennt, also dass
dort das "Û" wie ein "Ł" /aussieht/ und dann "entsprechend" agiert
(selbst wenn es das wuesste waere es falsch, denn die Zuordnung
sollte natuerlich die Bedeutung und nicht das Aussehen der Glyphen
beruecksichtigen, und die Bedeutung ist halt "Ù").

viele Gruesse
Thomas Berger