Writing text to existing PDF: context not created, page index is either wrong, or page is null

[RoyHP]

I'm having this problem with one specific (and very popular) PDF.

This code is copied from the test sample, with coordinates set to 0, 0 (doesn't matter which coordinates I use since the context is never created)

const hummus = require('hummus');
console.log(__dirname + '/china.pdf');
var pdfWriter = hummus.createWriterToModify(__dirname + '/china.pdf', {
    modifiedFilePath: __dirname + '/output.pdf'
});
console.log(pdfWriter);
var pageModifier = new hummus.PDFPageModifier(pdfWriter,0);
console.log(pageModifier);
pageModifier.startContext().getContext().writeText(
    'Test Text',
    0, 0,
    {font:pdfWriter.getFontForFile(__dirname + '/Courier.ttf'),size:28,colorspace:'gray',color:0x00}
);

pageModifier.endContext().writePage();
pdfWriter.end();

I attached the PDF here: china.pdf

If you have any advice on how to fill this particular PDF (it seems to have FDF data? But no library I can find is able to read/modify it) it would be much appreciated.

Thank you.

[RoyHP]

I'm noticing that the only PDF's I'm having this problem with are those with multiple pages. Are their page indexes not starting at 0 or something? How would I know?

[galkahana]

no. defo not about multi pages. defo about the funky method to define xrefs in this file. parser is probably not understanding how to read it. need to fix. if you're just looking to remedy this file, you can try to "save as" it from one of the popular PDF editors, and it will probably make it a PDF that hummus can read.

[RoyHP]

It's not just this one, but a few others I am finding. For instance the same problem happens with this one. pakistan.pdf

Saving it from chrome via print makes it editable by Hummus.

[galkahana]

k. debug the parser, or wait for me :)

[galkahana]

k. looked at a bit into the problem at hand. Thing is that the PDF is encrypted in an encryption that's not supported by hummus. hummus can read types 1 and 2 but not 4 (thats like the encryption version). This means that the parser object is created but it can only provide some info. you can see this with either of the following:

1. Try to get the pages count with pdfWriter.getModifiedFileParser().getPagesCount(). you'll see that its 0. the C++ layer parser (that you get via getModifiedFileParser) does have a method that sais "isEncryptionSupported" that you can use in combo with "isEncrypted" but its not exported to the JS level, unfortuneately...this could have been another way to tell.

2. when debugging you can create a log like this:

   var pdfWriter = hummus.createWriterToModify(__dirname + '/china.pdf', {
   modifiedFilePath: __dirname + '/output.pdf',
   log: __dirname + '/outputLog.txt'
   });

it will tell the problem (well...you need to realize that its a problem):

[ 09/09/2017 13:31:11 ] DecryptionHelper::Setup, Only 1 and 2 are supported values for V. Unsupported filter encountered - 4

Well..the thing to do here is what you did (save as from a friendly source, that will drop the encryption) or to finish writing support for level 4. I did start it back when i wrote (and never really documented, other than here) encryption support, but didn't finish debugging the level 4 support, just because...and then forgot about it and moved on to other things. would be good to get back to this sometimes...i was nearly done as i recall.

[galkahana]

new version(1.0.82) shoud be able to handle this.

[RoyHP]

Thank you. I will attempt some testing over the next few days and let you know if I encounter similar issues.

[RoyHP]

It's been working fine since 1.0.82 - Thanks!