Home/ Questions/Q 8909199
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-15T03:22:19+00:00

I am trying to use iText 2.1.7 in my application. I nailed down by

  • 0

I am trying to use iText 2.1.7 in my application. I nailed down by problem to the following piece of code:

InputStream inputFile = ...
OutputStream outputStream = ...
PdfReader pdfReader = new PdfReader(fis);
PdfStamper pdfStamper = new PdfStamper(pdfReader, os, '0', true);

pdfStamper.close();
pdfReader.close();
outputStream .close();

This code yields broken pdf (error 118) when as input I use this pdf (this is polish taxation form). Do you know if it there is some easy work-around for this problem? I know that corresponding code in c#/iTextSharp works.

Edit: This is not a problem with encryption. I have already solved this one.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    As mentioned as a comment, the document in question is encrypted to restrict permissions. The code from the official iText 2.1.7 jar will, therefore, throw a BadPasswordException when instantiating the PdfStamper because the correct password was not supplied. Thus, it does not produce a broken PDF and so the issue here is not a bug. 😉

    That being said it of course is possible to coerce iText 2.1.7 into ignoring the fact that the password was not supplied. In that case the program (having corrected the variable names where necessary) indeed produces a PDF which Adobe Acrobat refuses to open showing an error code 118.

    Doing the same with the current iText 5.x, on the other hand, produces a document which Adobe Acrobat opens without any objection.

    If one compares those two outputs, the problem becomes clear. While in case of iText 2.1.7 the updated info dictionary looks like this:

    16 0 obj
<<
/Creator(ADEP Document Services … Designer 10.0)
/Producer(Adobe LiveCycle Forms ES3; modified using iText 2.1.7 by 1T3XT)
/schemat(http://crd.gov.pl/wzor/2011/12/19/732/)
/Title(PIT-37)
/wersja_schemy(1-0E)
/ModDate(D:20121129153659+01'00')
/Subject(þÿ Z e z n a n i e   o   w y s o k o[ c i   o s i g n i t e g o   d o c h o d u \( p o n i e s i o n e j   s t r a t y \)   p r z e z   p o d a t n i k a   p o d a t k u   d o c h o d o w e g o   o d   o s ó b   f i z y c z n y c h)
/wariant(17)
/Author(Ministerstwo Finansów)
/CreationDate(D:20120816122649+02'00')
>>
endobj

    it looks like this with the current iText 5.x:

    16 0 obj
<<
/Creator(Ìû±d\\‘0Ú¼U´N°4@è4÷¤&‚ŸWŠÖsW¦ïôeå¿ê¹@aC<M¹^\t¯p; Um­…‡&U$“)
/Producer(Ìû±d\\‘0Ú¼U´NSH<š¶CìœhMÙg6\(@+C“rxó3% èúáž#„~îí$´Ñ\rEÿ\){â®ø×ÇMõÒ”/k«'T“…Ô»6D±Šàûèq}=_]YùèM»Lõ‡!õØûÚ©'é+t#Väò¿ÃSVõñý)
/schemat(Ìû±d\\‘0Ú¼U´N„hÙÚújñÂð\)÷Lsg—¥oÏ0<Á@õ5/•X6úJ!–nÈÒvU‚nð)
/Title(Ìû±d\\‘0Ú¼U´NÅÎéÈ€Ã3 ÅpC„¡H)
/wersja_schemy(Ìû±d\\‘0Ú¼U´NAÞ&·4ul‰¡b‘Œó)
/ModDate(Ìû±d\\‘0Ú¼U´NÏbZk£&"!õH³Î¨l\f6\)¥+¥ûcoûÒ\rÕ8˜Í)
/Subject(Ìû±d\\‘0Ú¼U´N:¡Ž”"ؘí¹~KŸpS†ÑŽäQ%”ýãtõÌt\t‚Ý3t\r9Ñ}#M …O¦\nqWóm: íÑ;A“GÝ.mÐÔéÔ]Ùn“Ƽä°'0%±@ \rÞªeé¶T<“¾./ýÂA"ÆRvoo€‚—Ý{?Ü“Nö\r¼¨]üv•¯y©Tˆ aŸ?"y°à¡ÀaÂÛ”ÄR’rèŽêKD•M6{Ä£t´é¾ù|%¬ƒÒˆM….’Ëð½˜B‡lƳ¤+¦Š¹ôTÝ^å¤=‹BAO‚Ø€°ú̱æj9_!#÷h‡5)
/wariant(Ìû±d\\‘0Ú¼U´N6©BÛâ`Ì¡k‹Ô <½`)
/Author(Ìû±d\\‘0Ú¼U´NŒ’×,ïZ2ä¡Åöw윭?bjÃô‚w|éUÆб)
/CreationDate(Ìû±d\\‘0Ú¼U´N'·¬‡jHÎâÃë&šZ¦Ñ.U©ü«s¾½Ý;2¸Q)
>>
endobj

    Thus, the iText 2.1.7 did not encrypt the entries of the updated info dictionary, and Adobe Acrobat hickuped while trying to decrypt it.

    EDIT

    Unfortunately, even after spacing away the unencrypted info dictionary, there is the 118 when trying to load the file. Thus looking at the files again there is another difference: the version created by iText 2.1.7 contains a tiny object stream while the other version does not. iText itself stumbles when trying to read that object stream…

    • 0