Yesterday, I got a comment on Jbig2

Hi Steven,
thanks for the port to windows. It works very good, produces small pdf-file sizes. Only one strange thing happens. The generate pdf files have a huge page-size. For example if I process A4-size pages (29.7×20.9cm) @400dpi tiff or png the pdf file size is 164.9×116.6 cm.
Is it possible to fix this by the python pdf.py or is jbig2.exe responible for this?
Thanks
Armin

after check the last version pdf.py, I notice it uses a default DPI(600). Images has different DPI, so if you want to use pdf.py, you need always modify it, it is not a good solution.

Then I check the source code of jbig, and found in jbig2_page_info structure ,

struct jbig2_page_info {
  u32 width;
  u32 height;
  u32 xres;
  u32 yres;
...

we can get xres and yres, so we can directly use xres and yres to generated proper page size.

and here is the patch file

btw, you can also download the last version jbig2 from here.

P.S.

Armin became the first user, and here is his response,

Hi Steven,
thank you very much for your quick response, and the new pdf.py
which works perfect. (I checked it with my 400dpi page scans.
the pdf page size is now of the same size as the scans)

Thank you so much,
Greetings from rainy Germany :-)

Armin

Somebody sent me a encrypted PDF to ask me help decrypt, I tried pdfcrypt, it got error. and when used pdfcrack, got the following warning messages,

WARNING: O-String != 32 Bytes: 33
WARNING: U-String != 32 Bytes: 33


After studied the source code of iTextSharp, I noticed it is a bug of iTextSharp in SetupGlobalEncryptionKey method of the PdfEncryption class,
misused the this.ownerKey and ownerKey and we can only find this bug when the PDF has strange length of ownerkey/userkey, for example 33, not 32.

this.documentID = documentID;
//this.ownerKey = ownerKey;
Array.Copy(ownerKey, 0, this.ownerKey, 0, 32);
this.permissions = permissions;
// use variable keylength
mkey = new byte[keyLength / 8];

//fixed by ujihara in order to follow PDF refrence
md5.Reset();
md5.BlockUpdate(userPad, 0, userPad.Length);
//md5.BlockUpdate(ownerKey, 0, ownerKey.Length);
md5.BlockUpdate(this.ownerKey, 0, this.ownerKey.Length);


Then I review iText 5.1.1 and find it has the same bug:

this.documentID = documentID;
//this.ownerKey = ownerKey;
System.arraycopy(ownerKey, 0, this.ownerKey, 0, 32);
this.permissions = permissions;
// use variable keylength
mkey = new byte[keyLength / 8];

// fixed by ujihara in order to follow PDF reference
md5.reset();
md5.update(userPad);
//md5.update(ownerKey);
md5.update(this.ownerKey);


Sumatra PDF 1.5 released on Apr 23, 2011, and includes more important features,

• add support for viewing XPS documents
• add support for viewing CBZ and CBR comic books
• add File/Save Shortcut menu item to create shortcuts to a specific place in a document
• add context menu for copying text, link addresses and comments. In browser plugin it also adds saving and printing commands
• add folder browsing (Ctrl+Shift+Right opens next PDF document in the current folder, Ctrl+Shift+Left opens previous document)

btw,
Last week, I noticed MuPDF trunk adds XPS support, but still has some bugs in windows registers.