2006 Sep 13 2:19 PM
Hello,
we have switched a CRM4.0 system from non-unicode to unicode. In this context we became two problems with the result of the function module 'CONVERT_OTF'. We call the function Module following:
call function 'CONVERT_OTF'
exporting
format = 'PDF'
max_linewidth = 132
copynumber = 0
importing
bin_filesize = lv_bin_filesizepdf
tables
otf = it_otfdata
lines = lt_lines_pdf
the otf tabel is generated by a Smartform.
Noticeable is, that the pdf table in the unicode system has similarly only the half quantity of rows than in the non-unicode system. (The parameter FLATE_COMPR_OFF in Report RSTXPDF3 allways is on)
1. Problem
We send the pdf table (lt_lines_pdf) via RFC to a non-unicode R/3 system and save it there on the file system. After switching to unicode, the document in the RFC system is damaged an cannot processed.
2. Problem
We transform the lt_lines_pdf for an archive in the following way.
data: ls_data type char1024
, lv_134 type char134
, ls_lines type tline
, lt_data type standard table of tbl1024
.
field-symbols: <fs> type tbl1024.
assign ls_data to <fs> casting.
lv_count = 0.
loop at lt_lines_pdf into ls_lines.
lv_134 = ls_lines.
lv_offset = lv_count.
lv_count = lv_count + 134.
if lv_count < 1024.
ls_data+lv_offset(134) = lv_134.
else.
lv_count = lv_count - 1024.
lv_begin = 134 - lv_count.
ls_data+lv_offset(lv_begin) = lv_134(lv_begin).
append <fs> to lt_data.
clear ls_data.
if lv_count > 0.
ls_data = lv_134+lv_begin(*).
endif.
endif.
endloop.
if ls_data is not initial.
append <fs> to lt_data.
endif.
We need lt_data for the FM 'SCMS_AO_TABLE_CREATE'.
I hope anybody can help me, I invest already much time in this problem!
Hello,
we have switched a CRM4.0 system from non-unicode to unicode. In this context we became two problems with the result of the function module 'CONVERT_OTF'. We call the function Module following:
call function 'CONVERT_OTF'
exporting
format = 'PDF'
max_linewidth = 132
copynumber = 0
importing
bin_filesize = lv_bin_filesizepdf
tables
otf = it_otfdata
lines = lt_lines_pdf
the otf tabel is generated by a Smartform.
Noticeable is, that the pdf table in the unicode system has similarly only the half quantity of rows than in the non-unicode system. (The parameter FLATE_COMPR_OFF in Report RSTXPDF3 allways is on)
1. Problem
We send the pdf table (lt_lines_pdf) via RFC to a non-unicode R/3 system and save it there on the file system. After switching to unicode, the document in the RFC system is damaged an cannot processed.
2. Problem
We transform the lt_lines_pdf for an archive in the following way.
data: ls_data type char1024
, lv_134 type char134
, ls_lines type tline
, lt_data type standard table of tbl1024
.
field-symbols: <fs> type tbl1024.
assign ls_data to <fs> casting.
lv_count = 0.
loop at lt_lines_pdf into ls_lines.
lv_134 = ls_lines.
lv_offset = lv_count.
lv_count = lv_count + 134.
if lv_count < 1024.
ls_data+lv_offset(134) = lv_134.
else.
lv_count = lv_count - 1024.
lv_begin = 134 - lv_count.
ls_data+lv_offset(lv_begin) = lv_134(lv_begin).
append <fs> to lt_data.
clear ls_data.
if lv_count > 0.
ls_data = lv_134+lv_begin(*).
endif.
endif.
endloop.
if ls_data is not initial.
append <fs> to lt_data.
endif.
We need lt_data for the FM 'SCMS_AO_TABLE_CREATE'.
I hope anybody can help me, I invest already much time in this problem!
2007 Mar 21 9:52 AM
Hi,
CONVERT_OTF packs two byte into one character of i-tab LINES on unicode systems. If you pass this via RFC to non-unicode systems data ist lost. The table contents are bytes when if the data type is character. The conversion routines between unicode and non-unicode do not know about this.
However the function module contains an export paramter BIN_FILE. This parameter is of type XSTRING, which has always a byte-representation. This datatype will not be converted between RFC-calls.
Greetings
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |