Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Encoding for cross reference table wrong #642

Merged
merged 4 commits into from
Mar 13, 2022

Conversation

soenkekueper
Copy link

When creating an pdf on an system with different default encoding (for example ibm z/os where IBM-273 is the default encoding) the cross reference table is written in that encoding and afterwards unreadable.

Description of the new Feature/Bugfix

When writing the cross reference table entries now the Method PdfEncodings.convertToBytes without encoding is used, so the values are written as ISO-8859-1 bytes instead of IBM-273 encoded values.

Related Issue: #

Unit-Tests for the new Feature/Bugfix

jUnit Test SimplePdfTest.testCrossReferenceTableEncoding() added

Compatibilities Issues

No.

Testing details

I'll build this locally and include in our deployment and run on our z/os mainframe.

Sönke Küper added 2 commits December 29, 2021 15:24
…ng, instead of default system encoding, which is wrong for example on ibm zos, where default encoding is IBM-273.
@soenkekueper
Copy link
Author

Sorry this is a duplicate of #614. I've been too fast with correction and didn't check for other PRs in advance.
May be closed if #614 got merged.

@sonarcloud
Copy link

sonarcloud bot commented Feb 4, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@asturio
Copy link
Member

asturio commented Mar 5, 2022

Hi @soenkekueper , the test is not green. Can you take a look at it?

@soenkekueper
Copy link
Author

soenkekueper commented Mar 6, 2022

Hey,
this is, unfortunately, not a bug within the test, but a runtime problem with the java module system.
So this test only fails with java 16, but not with java 11.

The cause is that i've to reset the privafte field Charset.defaultCharset, for java property file.encoding to be evaluated.
So i'm using reflection to do so. But with the module system, this access is not allowed, which leads to an InaccessibleObjectException.

The change of file.encoding must be done, because if this is not changed, the test would also pass with the old implementation (on all systems that usw an ISO based enoding, which is the case).

So i see the following options for now:

  1. add the java parameter --add-opens java.base/java.nio.charset=ALL-UNNAMED for test execution
  2. do not execute the test case for java 16
  3. remove the entire test

What would you suggest as best solution?

@asturio asturio linked an issue Mar 10, 2022 that may be closed by this pull request
@asturio
Copy link
Member

asturio commented Mar 10, 2022

I'll checkout your branch and try to make the test pass.

@asturio asturio merged commit afa7272 into LibrePDF:master Mar 13, 2022
@asturio asturio mentioned this pull request Mar 13, 2022
2 tasks
@asturio asturio added this to the 1.3.28 milestone May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

PDFWriter uses wrong file.encoding to write XREF
3 participants