Ungarische Zeichen mit deutschem oder englischen Job drucken

[Jaexp]

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...

[BenderD]

... 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...

[Fuerchau]

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.

[Jaexp]

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/knowledg...is/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