Also!
Danke für Eure Ideen... Soweit.
Kannst du denn nicht definieren das die entsprechende Quelldatei nicht UTF8 gespeichert wird? da gabs doch mal was ...
Das wäre ne Idee... Wo?
Wobei die Umwandlung von
Unicode/UTF-8 nach
ANSI vom jeweiligen System abhängt, also von dessen Standard-Codepage. Und somit ist soeine Umwandlung nicht immer Bytegenau möglich, wenn die Umwandlung erst auf den Zielsystem (zur Laufzeit) geschieht.
Somit keine Lösung ich werde warscheinlich alle Anweisungen umbauen..
Beispiel : PrintStr(#219+'011 Text '+#219+'001'); usw..
Ich glaube, möchte er nicht, dass ein Û dargestellt wird, sondern es als Escapezeichen benutzten:
Das hardcoden solcher Strings ist
imho nicht das Gelbe vom Ei (ein
printer.doDasWasDieSequenzTut()
wäre wohl netter, damit wäre der Drucker auch besser austauschbar.).
Aber wenn du darauf baust, müsste sich doch eigentlich eine
Ansi-Codierung (und damit die richtige Bytesequenz) erzwingen lassen
Damit der Printer austauschbar ist werden alle Sequenzen so konvertiert. #219 für jetzt kommt ne Umschalt-Ssequenz und dann 3 Zahlen für was...
(Der Code ist 20 Jahr alt... Nix Canvas.... Direkt-Copy an den Printerport... Am Windows vorbei Hardcoded EPSON ESC/2 Befehle... usw...
Mittlerweile gibtes einen Emulator der die Sequenzen wieder Umsetzt in einen Canvas-Printer...
Was ich nicht nachvollziehen kann ist der große Block unter #219. Laut
EBCDIC-Tabelle Codepage 1141 entspricht #219 einem "û" (
Unicode-#00FB).
Schöne Tabellen.... Mach mal nen CMD auf und tippe <ALT festhalten>219<Alt loslassen>
Es geht um den "alten" DOS Zeichensatz...
Aber abgesehen von meinem "Printer-Problem" habt Ihr diese Probleme nicht? Non-
Ascii Zeichen in String-Konstaten?
Kaum zu glauben...
Mavarik