View Full Version : Ungarische Zeichen mit deutschem oder englischen Job drucken
Hallo zusammen!
Ich habe folgendes Problem:
Ein Feld in einem PF(CCSID1141) ist CHAR(30) definiert.
Die Daten werden mit
deutschem Job(CCSID 1141),
ungarischem Job(CCSID) 1153 und
englischem Job(CCSID 37)
eingegeben.
Mit folgenden 4 Zeichen habe ich ein Problem beim Drucken mit 1141 oder 37:
(wurden ungarisch erfasst)
Ő (https://hu.wiktionary.org/wiki/%C5%90) = X'EF'
ő (https://hu.wiktionary.org/wiki/%C5%91) = X'CF'
Ű (https://hu.wiktionary.org/wiki/%C5%B0) = X'FB'
ű (https://hu.wiktionary.org/wiki/%C5%B1) = X'DC'
Mir ist schon klar, dass es diese Zeichen in 1141 oder 37 nicht gibt.
Hat jemand eine Idee, wie ich diese Zeichen trotzdem auf den Druck bringen könnte?
Ein Umstellen des Druckfeldes auf "graphic"(CCSID 1200) hat nur teilweise Erfolge gebracht.
Ein Umstellen des Datei-Feldes auf UNI-Code ist leider nicht möglich!
Danke, Jaexp
RobertMack
02-02-21, 17:08
Ideen gibt's immer. Neben SQL, falls es in RPG passieren soll/darf:
a) zwei D-Zeilen Const(x'......') mit %Xlate auf das Feld (oder String)
b) wenn's nicht zuviele Zeichen sind, je Hexwert:
DoW %Scan(x'EF':FELD:1) <> *Zero;
FELD = %Replace('Ö':FELD:%Scan(x'EF':FELD:1):1);
Enddo;
// anstelle des 'Ö' den gewünschten Hexwert einsetzen
Danke für die schnelle Antwort, aber es sollen keine Ersatzzeichen sein.
Eine Idee war, das Feld in ein Unicode-Feld zu übertragen und hier die entsprechenden Zeichen als Unicode auszutauschen, bin aber an der Ausführung gescheitert.
Andreas_Prouza
03-02-21, 08:06
Hallo,
du kannst neben 1200 auch 1208 (UTF-8) verwenden.
Da werden nur die Sonderzeichen, Umlaute & Co mit mehr Bytes abgespeichert.
Was für ein Problem genau hast du da gehabt bzw. wie hast du das umgesetzt?
lg Andreas
Um das zu gewährleisten ist die PF bereits in Unicode (1200/13488) zu erstellen.
Bereits beim Schreiben mit Job-CCSID 1153 in eine PF mit 1141 sollte es eigentlich einen Abbruch im Job geben.
Da du wahrscheinlich wie die meisten mit Job-CCSID *HEX arbeitest, erfolgt keine Codewandlung und beim Lesen nimmt die DB dann an, dass es eben die Datei-CCSID 1141 ist.
Eine Rückübersetzung in 1153 ist nicht möglich.
Um nun doch die Daten korrekt auszudrucken, musst du einen OVRPRTF mit einer passenden CHRID zur CCSID 1153 wählen. Dann werden die Daten deiner Datei (wenn dein Job noch auf 65535 steht) korrekt gedruckt. Aber konstante Texte, die es ja meist zuhauf auf Papier gibt, werden dann ebenso in 1153 erwartet.
Damit der Drucker das dann wieder schafft, muss dieser die Codepage für Ungarisch unterstützen, sonst gehts da auch wieder schief.
Danke für deine Antwort!
Eine Änderung der DB ist hier unmöglich(Standard-SW)
Eine Änderung der Datei-CCSID ist hier unmöglich(Standard-SW)
Es war mir klar, dass das Feld eigentlich schon in der DB als Graphic-Field definiert sein sollte.
Die Jobs laufen unter der jeweiligen CCSID der Landes der Belegsprache: 1141(273), 37, 1153(870),
Im Userprf ist die Steuerung am Beispiel H: HUN, HU, 1153(870), *JOBCCSID, HU_HU.locale
Ein OVRPRTF ist nicht möglich, da dies von der Standard-SW gesteuert wird.
Ich kann nur das Feld im PRTF als Graphic statt Alpha definieren.
Deswegen habe ich nur Spielraum im Datenbeschaffungs-Programm.
Dieses beschafft das Feld als ALPHA, das ich manipulieren könnte.
Ich weiß mit welcher CCSID die Daten beschafft werden und mit welcher CCSID sie erfasst wurden.
Daher die Idee diese 4 Zeichen Hex zu manipulieren.
Ich glaube ich werde damit leben müssen...
... wenn der Datensatz ausweist mit welcher CCSID die Daten erfasst wurde, kann man da eine SQL View bauen, die das glatt stellt.
D*B
Danke für deine Antwort!
Eine Änderung der DB ist hier unmöglich(Standard-SW)
Eine Änderung der Datei-CCSID ist hier unmöglich(Standard-SW)
Es war mir klar, dass das Feld eigentlich schon in der DB als Graphic-Field definiert sein sollte.
Die Jobs laufen unter der jeweiligen CCSID der Landes der Belegsprache: 1141(273), 37, 1153(870),
Im Userprf ist die Steuerung am Beispiel H: HUN, HU, 1153(870), *JOBCCSID, HU_HU.locale
Ein OVRPRTF ist nicht möglich, da dies von der Standard-SW gesteuert wird.
Ich kann nur das Feld im PRTF als Graphic statt Alpha definieren.
Deswegen habe ich nur Spielraum im Datenbeschaffungs-Programm.
Dieses beschafft das Feld als ALPHA, das ich manipulieren könnte.
Ich weiß mit welcher CCSID die Daten beschafft werden und mit welcher CCSID sie erfasst wurden.
Daher die Idee diese 4 Zeichen Hex zu manipulieren.
Ich glaube ich werde damit leben müssen...
Dann solltest du PRTF's über Sprach-Libs mit der passenden CHRID vorschalten.
Du hast sonst wirklich keine Chance diese Codes korrekt zu drucken, wenn die CHRID der Printfile nicht korrekt steht und der Drucker dies nicht supportet. Es liegt auch einfach daran, dass im deutschen Zeichensatz die polnischen oder ungarisachen Zeichen gar nicht vorhanden sind.
Der Default ist *DEVD. Wenn du also Drucker vorhältst deren Standard-Codepage der Sprache entspricht, könnte dies gehen.
Bei Hosttransform könntest du auch verschiedene Devices/Remote-OUTQ's und einem WSCST mit einer Initsequenz für die Codepage im Drucker bereitstellen.
Wenn du das PRTF-Feld auf Unicode stellst, wird das bei standard AFP/SCS-Druckern ignoriert bzw. führt u.U. zu Fehlern. Unicode-Felder werden mit entsprechenden Unicode-Fonts nur bei z.B. PDF-Erstellung korrekt bedient.
Wie du das mit den Jobs hinkriegst frage ich mich da auch. Denn wenn der Job z.B. auf 870 steht kann ich nicht in eine PF mit 273 schreiben oder aus ihr lesen.
Danke für die Hilfe und Antworten.
Ich habe das Problem mit dem API 'CDRCVRT' gelöst.
Da ich die Erfassungs-CCSID kannte, konnte ich damit den Alphawert in Unicode umwandeln, weil dieses API unabhängig von der Job-CCSID konvertiert.
Den Unicode-Wert habe ich dann in einem Unicode-Feld im PRTF ausgegeben.
Hier der Aufruf des APIs(Sorry für die Formatierung):
https://www.ibm.com/support/knowledgecenter/ssw_ibm_i_74/apis/CDRCVRT.htm
D #CVT DS
D C#CCS1 1 4B 0
D C#ST1 5 8B 0
D C#S1 9 264
D C#L1 265 268B 0
D C#CCS2 269 272B 0
D C#ST2 273 276B 0
D C#GCAS 277 280B 0
D C#L2 281 284B 0
D C#S2 285 540
D C#L3 541 544B 0
D C#L4 545 548B 0
D C#FB 549 560
/Free
C#L1=%size(ALPHA);
C#L2=%size(UNICODE);
/End-Free
C MOVEL ALPHA C#S1
C*
C CALL 'CDRCVRT' 01
C PARM E-CCSID C#CCS1
C PARM 0 C#ST1
C PARM C#S1
C PARM C#L1
C PARM 1200 C#CCS2
C PARM 2 C#ST2
C PARM 0 C#GCAS
C PARM 256 C#L2
C PARM *BLANK C#S2
C PARM *ZERO C#L3
C PARM *ZERO C#L4
C PARM *BLANK C#FB
C*
C MOVEL C#S2 UNICODE