I added new scale function, symmetrical and non symmetrical scale, options to scale paper and scale contents independantly, and to align to page (top left, center, center right ... etc) Please update main repository with new code. Only few files were changed/upgraded

I added new scale function, symmetrical and non symmetrical scale, options to scale paper and scale contents independantly, and to align to page (top left, center, center right ... etc) Please update main repository with new code. Only few files were changed/upgraded

Description: dump_data_utf8 outputs numeric values with thousands separators (commas), which makes the output incompatible with update_info_utf8.

This is particularly visible in fields such as:

• PageMediaRect
• PageMediaDimensions

Steps to reproduce:

1. Run: pdftk helloworld.pdf dump_data_utf8 output data.txt
2. Observe commas in numeric values in PageMediaRect / PageMediaDimensions
3. Run: pdftk helloworld.pdf update_info_utf8 data.txt output out.pdf

Expected behavior:

• dump_data_utf8 should output machine-readable numeric values (no thousands separators)
• OR update_info_utf8 should accept localized numbers

Actual behavior:

• update_info_utf8 fails or misparses numeric values containing commas

Notes: This appears to be locale-dependent (LC_NUMERIC / LANG). It breaks the expected round-trip workflow between dump_data_utf8 and update_info_utf8.

helloworld.pdf

When updating Info-dictionary date fields using update_info or update_info_utf8, pdftk-java writes a date as a UTF-16BE text string with BOM instead of an ASCII string. This causes interoperability issues with ExifTool, which does not normalize this date into a standard human-readable form.

Since the PDF date format uses only printable ASCII characters, UTF-16BE encoding is unnecessary and leads to inconsistent encoding within the same Info dictionary.

To reproduce, grab https://pdfobject.com/pdf/sample.pdf and run pdftk sample.pdf update_info <(echo -e "InfoBegin\nInfoKey: CreationDate\nInfoValue: D:199812231952-08'00'") output sample_with_date.pdf

ExifTool shows ModifyDate (which has not been changed) normalized and therefore somewhat human-readable but CreationDate as a raw PDF string, which is way less human-readable:

$ exiftool -a -G sample_with_date.pdf | grep "PDF.*Date"
[PDF] Modify Date : 2008:07:01 05:24:47Z
[PDF] Create Date : D:199812231952-08'00'

According to mutool, CreationDate is written as a UTF-16BE hex string:

$ mutool show sample_with_date.pdf trailer/Info | grep "Date"
  /ModDate (D:20080701052447Z00'00')
  /CreationDate <FEFF0044003A003100390039003800310032003200330031003900350032002D003000380027003000300027>

A hex dump confirms the presence of the UTF-16BE byte-order mark and null bytes:

$ hexdump -C sample_with_date.pdf | grep -A3 "Dat"
000045c0  20 28 50 61 67 65 73 29  0a 2f 4d 6f 64 44 61 74  | (Pages)./ModDat|
000045d0  65 20 28 44 3a 32 30 30  38 30 37 30 31 30 35 32  |e (D:20080701052|
000045e0  34 34 37 5a 30 30 27 30  30 27 29 0a 2f 43 72 65  |447Z00'00')./Cre|
000045f0  61 74 69 6f 6e 44 61 74  65 20 28 fe ff 00 44 00  |ationDate (...D.|
00004600  3a 00 31 00 39 00 39 00  38 00 31 00 32 00 32 00  |:.1.9.9.8.1.2.2.|
00004610  33 00 31 00 39 00 35 00  32 00 2d 00 30 00 38 00  |3.1.9.5.2.-.0.8.|
00004620  27 00 30 00 30 00 27 29  0a 2f 50 72 6f 64 75 63  |'.0.0.')./Produc|

Notice that the original ASCII /ModDate (D:20080701052447Z00'00') is followed by a line feed, which is followed by /CreationDate (0xfe 0xff 0x00 0x44 0x00 0x3a 0x00 0x31 ...)

Instead, the updated CreationDate should be written as printable ASCII (PDFDocEncoding subset), consistent with the original ModifyDate and the PDF date string format: /CreationDate (D:199812231952-08'00').

PDF specifications define date strings as containing only ASCII characters:

• In PDF spec 1.3, https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/pdfreference1.3.pdf, Table 3.21, a date is a string, and a string is specified at the beginning of § 3.2.3 as a series of bytes—unsigned integer values in the range 0 to 255.
• In PDF spec 1.7, https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandards/PDF32000_2008.pdf, Table 34, a date is an ASCII string.
• In PDF spec 2.0, https://developer.adobe.com/document-services/docs/assets/5b15559b96303194340b99820d3a70fa/PDF_ISO_32000-2.pdf, Table 35, a date is also an ASCII string.

A reader might notice that § 7.9.4 in specs 1.7 and 2.0 say that the date is a “text string”, which, when interpreted as a data type rather than as plain English, may use UTF-16BE. However, this is unnecessary for date fields, since they contain only printable ASCII characters.

This bug affects interoperability, as the same Info dictionary contains mixed encodings:

/ModDate (D:20080701052447Z00'00')  % ASCII
/CreationDate <FEFF0044...>         % UTF-16BE

Suggested fix: When writing Info-dictionary date fields, pdftk-java should write printable-ASCII strings (a PDFDocEncoding subset) instead of UTF-16BE when the string contains only printable ASCII characters. If a character outside the printable ASCII is present in an input date string, the string is not a valid PDF date (in which case the string might still represent a date, but not in English, e.g., “четверг, 19 февраля 2026 г., 23:02:57 МСК”, a case for an error/warning message or for a translation/conversion attempt).

I use pdftk-java 3.3.3 and openjdk 21.0.10 2026-01-20 on Debian trixie.

Downstream issue report: https://bugs.debian.org/1128417 .

PS. More generally, also other fields from the Document Information Dictionary would profit from ASCII whenever the input is representable in ASCII. For example, pdftk sample.pdf update_info <(echo -e "InfoBegin\nInfoKey: Title\nInfoValue: sample") output sample_with_title.pdf && grep -a sample sample*.pdf currently does not find sample_with_title.pdf but would do so if the rewritten title “sample” were stored as ASCII. Last but not least, a tiny bit of space would be saved.

I don't know if you care much about bad error messages, but since it's telling me to report it ...

After I had accidentally set wrong permissions in /etc, pdftk failed with an unhelpful error message. It contains a stack trace which doesn't help, but doesn't mention the affected file, so I had to use strace to find the problem.

To reproduce:

% sudo chmod 700 /etc/java-21-openjdk/  # or whatever version
% pdftk A=/usr/share/texmf/doc/latex/preview/preview.pdf cat A output /tmp/foo.pdf  # file names and content don't matter
Unhandled Java Exception in create_output():
java.lang.InternalError: Error loading java.security file
        at java.base/java.security.Security.initialize(Security.java:105)
        at java.base/java.security.Security.lambda$static$0(Security.java:84)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.base/java.security.Security.<clinit>(Security.java:83)
        at java.base/sun.security.jca.ProviderList.<init>(ProviderList.java:179)
        at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:96)
        at java.base/sun.security.jca.ProviderList$2.run(ProviderList.java:94)
        at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
        at java.base/sun.security.jca.ProviderList.fromSecurityProperties(ProviderList.java:93)
        at java.base/sun.security.jca.Providers.<clinit>(Providers.java:55)
        at java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:156)
        at java.base/java.security.MessageDigest.getInstance(MessageDigest.java:185)
        at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfEncryption.createDocumentId(PdfEncryption.java:342)
        at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfWriter.close(PdfWriter.java:1370)
        at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfCopy.close(PdfCopy.java:783)
        at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfDocument.close(PdfDocument.java:963)
        at com.gitlab.pdftk_java.com.lowagie.text.Document.close(Document.java:532)
        at com.gitlab.pdftk_java.cat.create_output_cat(cat.java:481)
        at com.gitlab.pdftk_java.TK_Session.create_output(TK_Session.java:1451)
        at com.gitlab.pdftk_java.pdftk.main_noexit(pdftk.java:190)
        at com.gitlab.pdftk_java.pdftk.main(pdftk.java:161)
There was a problem with pdftk-java. Please report it at
https://gitlab.com/pdftk-java/pdftk/issues
including the message above, the version of pdftk-java (3.3.3), and if possible steps to reproduce the error.

In the directory of the attached file 100871529.pdf execute:

pdftk 100871529.pdf generate_fdf output data.fdf
pdftk 100871529.pdf fill_form data.fdf output filled.pdf

Error message is:

Unhandled Java Exception in create_output():
java.lang.ClassCastException: class com.gitlab.pdftk_java.com.lowagie.text.pdf.PRIndirectReference cannot be cast to class com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfArray (com.gitlab.pdftk_java.com.lowagie.text.pdf.PRIndirectReference and com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfArray are in unnamed module of loader 'app')
	at com.gitlab.pdftk_java.com.lowagie.text.pdf.AcroFields.getAppearance(AcroFields.java:763)
	at com.gitlab.pdftk_java.com.lowagie.text.pdf.AcroFields.getAppearance(AcroFields.java:800)
	at com.gitlab.pdftk_java.com.lowagie.text.pdf.AcroFields.setField(AcroFields.java:1357)
	at com.gitlab.pdftk_java.com.lowagie.text.pdf.AcroFields.setFields(AcroFields.java:1234)
	at com.gitlab.pdftk_java.filter.create_output_filter(filter.java:320)
	at com.gitlab.pdftk_java.TK_Session.create_output(TK_Session.java:1457)
	at com.gitlab.pdftk_java.pdftk.main_noexit(pdftk.java:190)
	at com.gitlab.pdftk_java.pdftk.main(pdftk.java:161)
There was a problem with pdftk-java. Please report it at
https://gitlab.com/pdftk-java/pdftk/issues
including the message above, the version of pdftk-java (3.3.3), and if possible steps to reproduce the error.

By deleting stuff and running fill_form again data.fdf can be condensed to the attached data_dropdown11.fdf

cat data_dropdown11.fdf displays it like this:

%FDF-1.2
%����
1 0 obj

<<
/FDF 
<<
/Fields [
<<
/T (Dropdown11)
/V (��-00$k0o0$j0g50��x0�0`N�0k0`0Q�^0M0~0Y Question No. 12 must be answered only by those who chose 5 in No. 11 above0�\r)
>>]
>>
>>
endobj

trailer

<<
/Root 1 0 R
>>
%%EOF

nano and emacs add ^@ before the ascii characters. The value here corresponds to the first option in the dropdown and is shown by default. The last choice, a single space character, doesn't contain any Japanese characters. But even when I try to put a space as the value, I get the same stack trace. This suggests that the problem isn't so much the Japanese in data.fdf but filling out the PDF. At this point it is not clear if the issue is with generate_fdf or fill_form. The generated data.fdf might be fundamentally faulty, maybe in the header, and cause problems with fill_form no matter what you delete). However data.fdf can be condensed to

%FDF-1.2
%\342\343\317\323
1 0 obj

<<
/FDF 
<<
/Fields [
<<
/T (Text2)
/V ()
>>]
>>
>>
endobj

trailer

<<
/Root 1 0 R
>>
%%EOF

which does work, suggesting that the output of generate_fdf is not inherently faulty. Therefore I believe that the root cause is fill_form struggling with the Japanese characters of the PDF.

Bonus observation: data.fdf can also be condensed to

%FDF-1.2
%âãÏÓ
1 0 obj

<<
/FDF 
<<
/Fields [
<<
/T (Dropdown16)
/V (-)
>>]
>>
>>
endobj

trailer

<<
/Root 1 0 R
>>
%%EOF

which causes the aforementioned stacktrace too. Dropdown16 does not have any Japanese options, so Im not sure what's going on here...

Hello,

I tried to process the following PDF file from Wikipedia:

https://upload.wikimedia.org/wikipedia/commons/f/fa/Misak-%C4%B1_Mill%C3%AE_Beyannamesi.pdf

I saved the file on my local disk under the filename 9.pdf

The I ran the command

pdftk 9.pdf output tmp.pdf

And got the following error:

1 dirk@dirk-ThinkCentre-M75q-Gen-5:~/tur/document/images$ pdftk 9.pdf output tmp.pdf Unhandled Java Exception in create_output(): java.lang.ClassCastException: class com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfLiteral cannot be cast to class com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfDictionary (com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfLiteral and com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfDictionary are in unnamed module of loader 'app') at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfStamperImp.close(PdfStamperImp.java:251) at com.gitlab.pdftk_java.filter.create_output_filter(filter.java:490) at com.gitlab.pdftk_java.TK_Session.create_output(TK_Session.java:1457) at com.gitlab.pdftk_java.pdftk.main_noexit(pdftk.java:190) at com.gitlab.pdftk_java.pdftk.main(pdftk.java:161) There was a problem with pdftk-java. Please report it at https://gitlab.com/pdftk-java/pdftk/issues including the message above, the version of pdftk-java (3.3.3), and if possible steps to reproduce the error.

I am running Ubuntu 24.04

dirk@dirk-ThinkCentre-M75q-Gen-5:~/tur/document/main$ uname -r

6.14.0-33-generic

dirk@dirk-ThinkCentre-M75q-Gen-5:~/tur/document/main$ pdftk --version pdftk port to java 3.3.3 a Handy Tool for Manipulating PDF Documents Copyright (c) 2017-2018 Marc Vinyals - https://gitlab.com/pdftk-java/pdftk Copyright (c) 2003-2013 Steward and Lee, LLC. pdftk includes a modified version of the iText library. Copyright (c) 1999-2009 Bruno Lowagie, Paulo Soares, et al. This is free software; see the source code for copying conditions. There is NO warranty, not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I am doing a mass testing of my mediawiki2latex project on the English Wikipedia and the error came up during this testing. When processing the article:

https://en.wikipedia.org/wiki/United_Kingdom_during_the_Turkish_War_of_Independence

Yours Dirk Hünniger

Hello, I think this project can support gradle v9 but there is an error for now.

  Welcome to Gradle 9.0.0!
  
  Here are the highlights of this release:
   - Configuration Cache is the recommended execution mode
   - Gradle requires JVM 17 or higher to run
   - Build scripts use Kotlin 2.2 and Groovy 4.0
   - Improved Kotlin DSL script compilation avoidance
  
  For more details see https://docs.gradle.org/9.0.0/release-notes.html
  
  To honour the JVM settings for this build a single-use Daemon process will be forked. For more on this, please refer to https://docs.gradle.org/9.0.0/userguide/gradle_daemon.html#sec:disabling_the_daemon in the Gradle documentation.
  Daemon will be stopped at the end of the build 
  
  FAILURE: Build failed with an exception.
  
  * Where:
  Build file '/private/tmp/pdftk-java-20250916-8795-l66o4n/pdftk-v3.3.3/build.gradle' line: 5
  
  * What went wrong:
  An exception occurred applying plugin request [id: 'com.github.johnrengelman.shadow', version: '7.1.2']
  > Failed to apply plugin class 'com.github.jengelman.gradle.plugins.shadow.ShadowJavaPlugin'.
     > Could not get unknown property 'convention' for root project 'pdftk' of type org.gradle.api.Project.
  
  * Try:
  > Run with --stacktrace option to get the stack trace.
  > Run with --info or --debug option to get more log output.
  > Run with --scan to generate a Build Scan (Powered by Develocity).
  > Get more help at https://help.gradle.org.
  

Thanks,

Hello,

apache-commons-lang3 need to be updated to at least 3.18. https://bugzilla.redhat.com/show_bug.cgi?id=2379554

Thanks,

Regards

I am probably "missing out" but still so far I've only used qpdf for decryption of encrypted PDFs. The second-nature syntax of pdftk after years of using it... having created many shell aliases for common pdftk tasks... has kept me holding on.

Given the AES256 problem I would be interested migrating fully to qpdf if there were a good guide how to translate syntax from one to the other: but still I'll hope for a solution here.

We get a class cast exception when processing a pdf file. The file we process is a user file, with personal data, so we cannot upload that here. We hope the stacktrace also tells you something.

Prepared transformation with external tool failed (Command 'timeout -k5 900 pdftk '/tmp/RackMultipart20250825-6-n2cj5j' output '/tmp/20250825-6-eloyn9'' returned 2. Expected 0
Here is the command output: STDOUT:



STDERR:

Unhandled Java Exception in create_output():
java.lang.ClassCastException: class com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfDictionary cannot be cast to class com.gitlab.pdftk_java.com.lowagie.text.pdf.PRIndirectReference (com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfDictionary and com.gitlab.pdftk_java.com.lowagie.text.pdf.PRIndirectReference are in unnamed module of loader 'app')
  at com.gitlab.pdftk_java.com.lowagie.text.pdf.PdfStamperImp.close(PdfStamperImp.java:194)
  at com.gitlab.pdftk_java.filter.create_output_filter(filter.java:490)
  at com.gitlab.pdftk_java.TK_Session.create_output(TK_Session.java:1457)
  at com.gitlab.pdftk_java.pdftk.main_noexit(pdftk.java:190)
  at com.gitlab.pdftk_java.pdftk.main(pdftk.java:161)
There was a problem with pdftk-java. Please report it at
https://gitlab.com/pdftk-java/pdftk/issues
including the message above, the version of pdftk-java (3.3.3), and if possible steps to reproduce the error.)

Hi, @marcvinyals still no plans to do this in pdftk-java? For the people who are using qpdf, are you replacing pdftk-java completely with qpdf, or do you just use it for certain functions?

thanks

termux 119 beta 3 amdroid 15 file link stamp gives the exact same error .../p/n $ pdftk chem.pdf background wm.pdf output watermarked.pdf Error: Invalid PDF: Rebuild failed: trailer not found.; Original message: xref subsection not found at file pointer 120 Error: Failed to open input PDF file: chem.pdf Errors encountered. No output created. Done. Input errors, so no output created.

In a PDF, each page is identified by a unique "page index" expressing the page's position from the beginning of the document. This corresponds to what we think of as a physical page number (except we start counting physical pages at 1, whereas PDF page indices start at 0). But PDF pages can also be associated with an independent "page label" serving as a logical page number. This is commonly done to have separate numbering for the front matter (e.g., i, ii, iii, iv, v, etc.) and/or appendices (e.g., A-1, A-2, A-3, …, B-1, B-2, B-3, etc.). Many PDF viewers will display both the physical and logical page numbers, and when prompting users for page numbers may default to interpreting them as logical rather than physical numbers. Page labels are documented in §12.4.2 of the PDF 1.7 specification.

As far as I can tell, the page numbers passed to various pdftk-java commands are always interpreted as physical page numbers. It would be nice if there were some way of telling pdftk-java to interpret any given page number as a logical page number, such as with a new qualifier character. This way, if I want to extract (say) a book's appendix page labelled A-127, I don't need to open it in a PDF viewer first to find out its physical page number, or to remember that the book has 28 pages of front matter and 1775 pages of main matter and then do the math in my head.

One possible problem is that logical page numbers are not guaranteed to be unique, though I think PDFs with duplicate page labels are fairly rare. The simplest solution would probably be for pdftk-java to always interpret the "begin logical page number" of a page range as the first physical page with the corresponding page label in the PDF document, and the "end logical page number" as the first physical page after the "begin (logical) page number" with the corresponding page label. This behaviour should probably be documented to avoid unexpected surprises.

Another possible problem is that page labels can contain arbitrary strings, including the hyphens and spaces that pdftk-java uses to delimit page ranges and arguments. pdftk-java would need to specify some way that these characters occurring in logical page numbers should be escaped on the command line.

Hello,

apache-commons-lang3 need to be updated to at least 3.18. https://bugzilla.redhat.com/show_bug.cgi?id=2379554

Thanks,

Regards

just a note - it automatically updated again and broke. Had to downgrade again, then ran this command to lock the version.

yum versionlock add tzdata

We are good as well, thank you guys for the help!

Thanks guys! I ran sudo yum downgrade tzdata-2024a-1.el7.noarch tzdata-java-2024a-1.el7.noarch

Also installed version lock and ran sudo yum versionlock tzdata tzdata-java.

thank you for this information. For those that don't have the older version in their repo, here's what I ran

#Removed the new version sudo rpm -e --nodeps tzdata tzdata-java

#Downloaded the older versions wget https://vault.centos.org/7.9.2009/updates/x86_64/Packages/tzdata-2024a-1.el7.noarch.rpm wget https://vault.centos.org/7.9.2009/updates/x86_64/Packages/tzdata-java-2024a-1.el7.noarch.rpm

#Installed sudo rpm -Uvh --oldpackage tzdata-2024a-1.el7.noarch.rpm tzdata-java-2024a-1.el7.noarch.rpm

Restart

sudo systemctl restart httpd

Fixed the issue.

I had the same issue after years of everything working flawlessly. After a lot of debugging, I discovered that two packages (tzdata and tzdata-java) were automatically updated by yum three days ago.

These packages provide the system timezone data that Java uses internally. The new version included updated timezone files that caused pdftk-java to crash when trying to read them (specifically when adding PDF metadata like creation date).

Downgrading these packages immediately solved the problem: sudo yum --disablerepo=centos7-els downgrade \ tzdata-2024a-1.el7.noarch \ tzdata-java-2024a-1.el7.noarch