Thanks Simon,
I was thinking I would have to do something like that but was not sure I
could create a file using two different code pages.
One quick question.
You are correct I was using CPYTOSTMF to get the file to the IFS (or file
server)
Would CPYTOSTMF work if I converted to ASCII using both code pages
Then using the CPYTOSTMF specify CVTDTA(*NONE)
Because no conversion is required if I already converted everything to
ASCCII when the file was created in the program
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Simon Coulter
Sent: Sunday, November 22, 2009 2:33 PM
To: Midrange Systems Technical Discussion
Subject: Re: Creating file in IFS with code page 420 - but I need
squarebrackets
On 23/11/2009, at 2:02 AM, John Allen wrote:
I am trying to create a PDF file in the IFS and I need it to contain
square
brackets [ ] for PDF formatting
I also need to use code page 420 to retain Arabic characters
Code Page 420 does not include square brackets so those characters get
converted to some weird characters during the translation when using
CPYTOSTMF
Does anyone have any ideas how I can retain the Arabic characters in
code
page 420 but also include the square bracket required for PDF files
(Creating a PDF file requires the [ ] characters in it's file
structure)
PDFs are effectively a binary file format. One code page is used for
the file structure and another is used for the content.
It's been a long time since I had to delve into PDF creation but as I
recall the file structure should be in Adobe Standard (1276) or Adobe
Latin-1 (1277) depending on which PDF version is being targeted. These
are very similar to 819.
The content can be in any code page supported by Adobe. Thus your PDF
should have data in two code pages therefore it cannot be stored
reliably with a single CCSID.
Given your mention of CPYTOSTMF I suspect you are building a sort-of
PDF in EBCDIC (using RPG or similar HLL) and then attempting to
convert from your EBCDIC format to an ASCII format for the final PDF
stream file. That's not going to work. Most of the freebie examples do
it that way but they are wrong. It only works in the examples because
they are written (generally) by (or for) Americans and expect to
operate on EBCDIC 37 data and are usually converted to ASCII 819 as
the final step. Very misguided. Converting EBCDIC 37 to ASCII 819
works because all (or enough of) the necessary characters exist in
both character sets. The technique fails miserably when applied to
anything more complex than English (Chinese, Japanese, Korean, Arabic,
Hebrew, Cyrillic, Greek, Thai, etc.)
The only way to correctly build a PDF is to write directly to the
final stream file using the stream file APIs. You must also convert
the file structure and the file content to the correct code page prior
to writing to the stream file. Any encoding or encryption must be
performed after the code page conversion.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
