Problem with OwnerPW in PDFcreator from TextDynamic

Hi there,

i was experimenting with the PDF creation abilities of TextDynamic. Quite impressing...

But i stumbled across something i have have no explanation for.

The following VFP9 SP2 code sets some security settings for the export including password for the Owner. The exported PDF is perfectly OK and shows all signs of a "secured" PDF. Unfortunately getting access to the PDF.settings part with Adobe Acrobat 9 fails with "wrong password". Even when i hardcode the password (like in this test) Acrobat does not accept the password. Very weird.

WITH thisform.TextDynamicObject as WPTDYNINT.WPDLLInt
	.PDFCreator.Compression = lnCompress
	.PDFCreator.PDFAMode = IIF(thisform.PDF_PdfA_kompatibel,1,0)
	.PDFCreator.Security = lnSecurity
	.PDFCreator.Protection = lnProtection


	.PDFCreator.OwnerPW="test"


	.PDFCreator.PDFFile = ALLTRIM(thisform.SaveTo_Fullpath)

	.PDFCreator.BeginDoc
	.PDFCreator.Print
	.PDFCreator.EndDoc


ENDWITH

VFP uses regular ANSI as Charset. Is it possible that OwnerPW is expected to be something different?

Any ideas anyone?

Thanks and best regards
Michael

Hi Julian,

i tested a littlebit more and would like to add the following findings:

If i use the internal-dialogbased method with

thisform.rtf.rtf.wpaProcess("DiaPDFProperties","")

everything works just fine when i choose a security setting with OwnerPassword. The resulting PDF is protected with the very same choosen password.

Unfortunately this dialog is no way to go for us. As we often need a no-dialog way (via the ServerLicence) to produce PDF. As an additional annoyance the dialog is english-only (at least i have not found a way to switch language to german) AND you put a very prominent hyperlink to your website on the dialog which is IMHO not very acceptable for a fully licenced component.

As my target was a no-dialog-pdf-production anyway, i stick to my first intention with a code-only attempt.

But the following code as an alternative to dialog-based does not work:

WITH thisform.TextDynamicObject as WPTDYNINT.WPDLLInt
	.PDFCreator.Compression = 0 
	.PDFCreator.PDFAMode = 0 
	.PDFCreator.Security = 0 
	.PDFCreator.Protection = 1 + 2 
	.PDFCreator.OwnerPW = "test"  
	.PDFCreator.UserWP = "" 


	.PDFCreator.PDFFile = thisform.SaveTo_Fullpath

	.PDFCreator.BeginDoc
	.PDFCreator.Print
	.PDFCreator.EndDoc
ENDWITH

I think this code is pretty straight forward. The resulting PDF opens with perfect content and shows under Adobe Reader 9 as "(GESCHÜTZT)" (german for "Protected"). The DocProperties are indeed protected and when i try to enter it i am asked for a password, but unfortunately nothing works here. Adobe always complains about "wrong password".

Perhaps this is again something like the BeginPrint/Endprint - thing where this is simply ignored when used directly. Any other way to stuff the Passwords into your object? Something like the TextCommandStr for the MEMO... ?

Anything yet from looking into it?

Thanks and best regards
Michael

---
Just a hunch... What format has the PW? VFP works with single-byte-ANSI. Is it possible that you need Double-Byte-Characters here? UTF-8 ?

Well... that explains a lot.

As i assumed... it's DoubleByteCharacter - String. Foxpro uses only SingleByteCharacter. Which, when just handled without test and used along the resulting password in the pdf will be garbage.

I'll just have to change the string to DBC / Unicode and feed the PDFCreator with that.

I will test tomorrow and post back the result.

Until then... have a nice evening
Michael

Hi Julian,

nope... that's not the reason why it fails.

The COM-Properties are indeed presented with correct UTF - Stringformat. The neccesary conversion between datatypes in the COM-Object and Strings within VFP is done transparently. As all other String-Properties and -parameters of the TD COM object are working perfectly well, i can assume that this also works well for these specific PDFcreator.props.

There are several "switches" with which i can change this autoconversion behaviour. I tested all of it and even tested switching off the autoconversion and doing the ansi-to-unicode(wide) - conversion myself before stuffing the string onto the UserWP-Property.

Bottomline: I am 100% sure that at least it is the correct String-Type that is presented to the COM-Property here AND i am sure that the EditorMode is set correctly too. The export to PDF is working and all the nice little settings like DontAllowPrinting, NoEditing etc. are set correctly in the resulting PDF.

But... From my side of the fence i can't see what data is actually reaching your kernel-DLL because of the different wrappers used here. VFP-OLEcontainer wrapping the OCX wrapping the DLL-calls...

I could offer you to build a little VFPbased Testprogram that uses the TD OCX to build such a PDF. With that you could test the behaviour and the data you actually receive in a debug environment with your tools.

Any Idea?

Best regards
Michael