PDA

View Full Version : Unicode - Etikettendruck zpl2 - CGIDEV2



Seiten : [1] 2

Drittaccount
05-02-14, 19:44
Hallo zusammen,

wir würden gerne ein Etikett aus der AS400 drucken, welches in west- und osteuropäischen Sprachen verfügbar sein soll.
Bsp: http://www.moree.de/download/20131015_Energy_Efficiancy_Labels/DE/Cube/EEL_06-05-01-LED_DE.jpg


Die Textkonstanten liegen in einer PF File mit folgendem Feld als Unicode.
Daten wurden über den iNavigator in SQL Statements eingelesen. Hier werden sie auch richtig angezeigt.

A XXUNIC 050G TEXT('Unicodetexte ')
A CCSID(1200)


1. Ansatz:
ILE RPG das PRTF erstellt und an Drucker schickt.
... zum verzwêifeln ...


2.Ansatz:
ILE RPG mit CGIDEV2 das Textdatei auf IFS erstellt und diese per ftp an Drucker sendet.


Wenn ich eine Vorlage auf im IFS erstelle welche den Text schon drin hat und den mit CGIDEV2 kopiere werden die Zeichen richtig übernommen. Die Datei hat auch das richtige Encoding.

/$Labeltext
^FO050,100^AN,N,20,16^FH^FDТова осветително^FS
^FO050,130^AN,N,20,16^FH^FDтяло е предназначено^FS


Will ich den Text jetzt aus der DB lesen und in die Datei schreiben kommt bei den osteuropäischen Sprachen nichts lesbares raus.

Auf was muss ich hier achten?
Warum klappt Umwandlung UCS-2 in UTF-8 nicht bei allen Sprachen?
Muss hier noch die CCSID geändert werden?
Oder ist schon die PF mit 1200 falsch?
System läuft unter CCSID 65535


/$Labeltext
^FO050,100^AN,N,20,16^FH^FD
/%Zeile_1%/
^FS
^FO050,130^AN,N,20,16^FH^FD
/%Zeile_2%/
^FS


DmyString S 250A VARYING
...
myString = XXUNIC;
updHtmlVar('Zeile_1' : myString);
...
WrtHtmlToStmf('/TMP/ZPL_1208.txt' : 1208);

KM
06-02-14, 06:52
Ich denke mal, dass das an den unterschiedlichen CCSIDs liegt. Und da das System unter 65535 läuft, erfolgt wohl auch keine automatische Codewandlung.
Versuche doch mal in Deinem Programm die Variable XXUNIC erst per SQL von 1200 nach 1208 zu casten und dann in die Variable myString zu übertragen.

Gruß,
KM

Fuerchau
06-02-14, 08:05
Das Problem ist, dass die Zeichen als SBCS an den Drucker gehen (CHRID des Spools, WSCST).
Unicode/UTF-8/16 wird dabei nicht unterstützt.
Allerdings kannst du (mit etwas mehr Aufwand) UTF-16 auch mit ZPL druchen, siehe hier:
http://stackoverflow.com/questions/13040822/unicode-characters-on-zpl-printer

Über den Code ^FH kannst du in Hex die Unicode-Zeichen entsprechend übergeben.
Im RPGLE musst du halt eine C-Variable (UCS2) redefineren (Overlay) als 2-Byte-Array und die Bytes einzeln nach HEX erweitern.

B.Hauser
06-02-14, 08:26
Und warum schreibst Du das Ding nicht gleich mit embedded SQL als Unicode (allerdings mit CCSID 13488) file ins IFS?



D MyDBCLOBFile S SQLTYPE(DBCLOB_File)

D MyUCS2Var S 50C Varying
D MyCharVar S 50A Varying
D CRLF S 2A Inz(x'0D25')
//************************************************** ********************************
C/Exec SQL Set Option Commit=*None, DatFmt=*ISO, TimFmt=*ISO,
C+ Naming=*SYS, CloSQLCsr=*EndActGrp
C/End-Exec
/FREE
MyDBCLOBFile_Name = '/home/Hauser/TST_Unicode.txt';
MyDBCLOBFile_NL = %Len(%Trim(MyDBCLOBFile_Name));
MyDBCLOBFile_FO = SQFOVR; //Create/Replace IFS File

MyUCS2Var = %UCS2('First Text passed in Unicode');
Exec SQL Set :MyDBCLOBFile = :MyUCS2Var Concat :CRLF;
If SQLCODE < *Zeros;
//Handle Error
EndIf;

MyDBCLOBFile_FO = SQFAPP; //Add to IFS File

MyCharVar = 'Second Text passed as Character';
Exec SQL Set :MyDBCLOBFile = :MyCharVar concat :CRLF;
If SQLCODE < *Zeros;
//Handle Error
EndIf;

Exec SQL Set :MyDBCLOBFile = 'Third Text passed dirctly' concat :CRLF;
If SQLCODE < *Zeros;
//Handle Error
EndIf;
*InLR = *On;
/END-FREE

Birgitta

Fuerchau
06-02-14, 08:39
Weil die IFS-Datei so nicht an den Drucker geschickt werden kann, siehe obigen Link zur ZPL-Druckersprache.

Fuerchau
06-02-14, 08:50
Nachtrag:
Allerdings kann ich in SQL mir die UCS2-Daten (cast auf CCSID 13488!) mittels der Funktion HEX(Feld) direkt für die ZPL-Sprache aufbereiten lassen.

KM
06-02-14, 09:13
@Birgitta:

Wo wird denn in Deinem Beispiel festgelegt welche CCSID die Textdatei haben soll? Wenn ich Dein Beispiel ausführe, wird die Textdatei mit CCSID 273 erstellt und der Unicode-Text ist nicht darin enthalten.

Gruß,
KM

Drittaccount
06-02-14, 10:00
Nachtrag:
Allerdings kann ich in SQL mir die UCS2-Daten (cast auf CCSID 13488!) mittels der Funktion HEX(Feld) direkt für die ZPL-Sprache aufbereiten lassen.
... +
http://stackoverflow.com/questions/13040822/unicode-characters-on-zpl-printer



Nehmen wir mal das Beispiel und versuchen eine Zeile zu ergänzen ...



SELECT CAST(XXUNIC as CHAR(50) CCSID 37),
HEX(trim(CAST(XXUNIC as GRAPHIC(50) CCSID 13488))) FROM
LIB/FILE WHERE XXUSPR = 'DE'


Stimmt der Cast so?
CAST(XXUNIC as GRAPHIC(50) CCSID 13488)) hat selben inhalt wie XXUNIC in der SQL Ansicht


Text: werden.
Hex: 00770065007200640065006E002E


...
00770065007200640065006E002E -> _00_77_00_65_00_72_00_64_00_65_00_6E_00_2E




^XA
^LH100,150
^CWT,CAL000.FNT
^CFT,30,30
^CI28
^FT0,0^FH^FDTesting 1 2 3^FS
^FT0,50^FH^FD_D0_94_D0_BE _D1_81_D0_B2_D0_B8_D0_B4_D0_B0_D0_BD_D0_B8_D1_8F^F S
^FT0,100^FH^FD_00_77_00_65_00_72_00_64_00_65_00_6E _00_2E^FS
^FT0,150^B3^FDAAA001^FS
^XZ



da kommt nix raus.

Fuerchau
06-02-14, 10:22
ich denke mal, wie im Beispiel, je UCS2-zeichen ein leerzeichen dazwischen.
Ansonsten mal deinen Lieferanten fragen, ob dein Modell das überhaupt unterstützt.

Drittaccount
06-02-14, 10:33
Ich denke mal, dass das an den unterschiedlichen CCSIDs liegt. Und da das System unter 65535 läuft, erfolgt wohl auch keine automatische Codewandlung.
Versuche doch mal in Deinem Programm die Variable XXUNIC erst per SQL von 1200 nach 1208 zu casten und dann in die Variable myString zu übertragen.

Gruß,
KM

Mal testen ...


SELECT CAST(XXUNIC as CHAR(50) CCSID 1208) FROM
LIB/FILE WHERE XXUSPR = 'DE'
Ausgabe:
ÏÁÊÀÁ>

Wenn ich eine LF erstelle mit dem Feld als CCSID 1208:

SELECT XXUNIC FROM LIB/XXUC1208 WHERE Z7USPR = 'DE'
Ausgabe:
werden.

Verwende ich jetzt diese LF im Programm bekomme ich einen Fehler: E/A-Fehler CPF5029