Page 1 of 1

Paper.SheetSizeIndex doesn't work?

Posted: Fri Nov 26, 2021 10:50 pm
by sabio5
After upgrading from version 5 to version 9 of the driver API, I can no longer set the paper size. My C code looks like this...

Code: Select all

 m_pPrinter->Option[L"Paper.SheetSizeIndex"] = L"0";   // set US Letter/ANSI A
I've tried other index values, and have also tried using just Paper.Size as suggested in some older forum posts. And I've tried setting the Paper.SheetWidth and Paper.SheetHeight properties directly, but no matter what, despite no errors being thrown, the result is A4.

On a related note, I can change the settings in the via the driver's preferences UI, but when I try to set them from my app, it always reverts to A4.

Thanks in advance,
Jack McGregor

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 4:45 pm
by Ivan - Tracker Software
In V9 possible values for Paper.SheetSizeIndex and Paper.Size was unified - standard paper index is used instead of paper index.

I.e., to set Letter as a Sheet, you will have to use 1 instead of 0.

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 6:49 pm
by sabio5
This isn't working for me. I've verified that it is now using 1 rather than 0, and have also tried other index values such as 5, which would be either US Letter or ANSI E, depending on which index system was in effect, but no matter what value I specify, I get A4. Same goes for Paper.Size instead of Paper.SheetSizeIndex.

The only approach that seems to work is to just set the paper directly in the DEVMODE (as one would for standard Windows printing independent of PDFX), provided I don't use any Paper.SheetSizeIndex or Paper.Size directives. (They all seem to have the same effect of setting the size to A4.)

I suppose that's a workaround, but it would require a more complex adjustment to my app to maintain backward compatibility. Any other ideas?

Also, are there any other known changes to the interpretation of options that haven't been reflected in the documentation?

Thanks,
Jack

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 8:30 pm
by Ivan - Tracker Software
Hm, that's strange it does not work. I will double-check that.
Also, are there any other known changes to the interpretation of options that haven't been reflected in the documentation?
No, as I'm aware of.

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 9:26 pm
by Paul - PDF-XChange
Hi JAck,

Ivan is asking for the printer temp files. It should be the same process for you as for the end user as described here: https://www.pdf-xchange.com/knowle ... -I-do-this

If the files are too large for email please upload them to our file upload service as detailed here: https://www.pdf-xchange.com/knowle ... le-service

Please name them something eponymous and/or tell us the file names used so that we may associate it with this thread move it to a more suitable location.

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 10:44 pm
by sabio5
Ok, here it is...
pxpSheetSizeIndex-155806.zip

Re: Paper.SheetSizeIndex doesn't work?

Posted: Mon Nov 29, 2021 11:48 pm
by Ivan - Tracker Software
Thanks for the file, but I see no custom settings there.

Can you please send me a piece of code where you set printer options and start the printing process?

Please use ivan@tracker-software.com email.

Re: Paper.SheetSizeIndex doesn't work?

Posted: Tue Nov 30, 2021 6:23 am
by sabio5
I'm not quite sure how to provide you something you can actually use. The relevant code is basically identical (and indeed lifted from) the CExAPI sample. I have a wrapper class APDFX9 with a PreparePrinter routine ...

Code: Select all

BOOL APDFX9::PreparePrinter(PXC::IPXCPrinterPtr& printer, PXC::IPXCControlExPtr& pFactory, BOOL bNoEvents)
{
	if (printer == NULL)
	{
		printer = pFactory->Printer[(WCHAR*)L"", m_wchPrinterName, m_pKey, m_pDevCode];
		if (printer == NULL)
			return FALSE;
		if (!bNoEvents)
			DispEventAdvise(printer);
	}
	printer->ResetDefaults();
	...
	printer->Option[L"Paper.SheetSizeIndex"] = L"1";        
	printer->ApplyOptions(0);
I haven't gone through all of the possible printer options, but others that I've tried clearly work, such as Save.Path. And the code all worked in version 5, with the main update being to use the new pdfsaver.tlb that came with the V9 API.

Perhaps I can build a small one based on the CExAPI sample. But oddly, I can't get that sample program to work. It seems to be targeted at API V7, and fails on the init ...

Code: Select all

m_pFactory = PXC::IPXCControlExPtr(__uuidof(PXC::CPXCControlEx));
The pre-compiled versions also appear to have a similar problem (and do nothing when clicking Go).

Is there an updated sample specifically targeted at V9?

Re: Paper.SheetSizeIndex doesn't work?

Posted: Tue Nov 30, 2021 8:36 pm
by Ivan - Tracker Software
Looks like I can reproduce the issue on my side. Checking right now what may cause it

Re: Paper.SheetSizeIndex doesn't work?

Posted: Tue Nov 30, 2021 8:47 pm
by Ivan - Tracker Software
I found the problem - it fails when there are no "Paper.StdSheetWidth" and "Paper.StdSheetHeight" are not specified.

I fix the issue, but it will be available in the next build.

As a workaround, you can specify

Code: Select all

printer->Option[L"Paper.SheetSizeIndex"] = -2; // Custom
printer->Option[L"Paper.StdSheetWidth"] = w; // width in tenth of mm; for example, 2100 for A4
printer->Option[L"Paper.StdSheetHeight"] = h; // height in tenth of mm; for example, 2970 for A4

Re: Paper.SheetSizeIndex doesn't work?

Posted: Sat Dec 04, 2021 12:13 am
by sabio5
Is that fix in 3.2.359? (I downloaded it but didn't see any version history notes.) And it doesn't seem to behave any differently in this respect. If it will be later, do you have an estimated time frame?

If I understand correctly, the workaround would require me to set up a table to convert the sheet size index values into the corresponding physical paper dimensions. That's do-able but seems a bit roundabout, especially if the fix is not far off.

Re: Paper.SheetSizeIndex doesn't work?

Posted: Sat Dec 04, 2021 12:19 am
by Daniel - PDF-XChange
Hello, sabio5

No, build 9.2.359.0 was released on November 23rd, before this came to light. The next release will be 360, and hopefully this fix can be implemented there. at the moment we do not have a timeline for when it will be ready, so I will have to ask for your patience in this matter.

Kind regards,