You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by "ASF subversion and git services (JIRA)" <ji...@apache.org> on 2015/06/20 12:45:00 UTC
[jira] [Commented] (PDFBOX-2837) PDFBox creates files with EBCDIC
code on z/OS
[ https://issues.apache.org/jira/browse/PDFBOX-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14594514#comment-14594514 ]
ASF subversion and git services commented on PDFBOX-2837:
---------------------------------------------------------
Commit 1686551 from [~tilman] in branch 'pdfbox/trunk'
[ https://svn.apache.org/r1686551 ]
PDFBOX-2837: avoid output being written in EBCDIC in non ASCII systems
> PDFBox creates files with EBCDIC code on z/OS
> ---------------------------------------------
>
> Key: PDFBOX-2837
> URL: https://issues.apache.org/jira/browse/PDFBOX-2837
> Project: PDFBox
> Issue Type: Bug
> Components: Writing
> Affects Versions: 1.8.9, 1.8.10, 2.0.0
> Environment: OS: Unix Service running on Z/OS.
> JRE: JRE 1.6.0 IBM J9 2.4 z/OS s390-31
> Reporter: Tilman Hausherr
> Assignee: Tilman Hausherr
>
> A PDF file created on z/OS (an IBM mainframe os) has this
> {code}
> xref
> ð ù
> 0000000000 65535 f
> {code}
> the two chars are EBCDIC code for 0 9. The cause is this code that outputs in the system default encoding:
> {code}
> private void writeXrefRange(long x, long y) throws IOException
> {
> getStandardOutput().write(String.valueOf(x).getBytes());
> getStandardOutput().write(SPACE);
> getStandardOutput().write(String.valueOf(y).getBytes());
> getStandardOutput().writeEOL();
> }
> {code}
> getBytes should use the specific charset, e.g. getBytes(Charsets.ISO_8859_1).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pdfbox.apache.org
For additional commands, e-mail: dev-help@pdfbox.apache.org