VeryPDF Knowledge Base

Dear Support

To enhance our capabilities we are now looking for parser technology as one method of counting pages per print job.

We have been doing some tests with your product and found it of interst to look into. Currently we have one customer with a very limited demand of the PCL Page Counter software but it might be of interest for us to use your product as an add on for all customers.

In order to determine if the product can be used or not we kindly ask if there are any programming guides with description of all APIs available for us?
======================
You can download the trial version of PCL Page Counter SDK from following page to try, you can use PCL Page Counter SDK to count the pages in PCL3/4/5, PCL6, PCL5c, PCL5e, PCL-XL, PCLXL, PS, PDF, etc. formats easily,

http://www.verydoc.com/pcl-page-count/pcl-page-count.html

VeryPDF
======================
Thanks for fast response.

We already downloaded the trial version which seems to work as expected. What we need is some programming guide describing all available APIs to see if we can get the needed control from our software, and we cannot find this document in the downloaded package.
======================
PCL Page Counter SDK is provide ReadInfoFromPSFile(),ReadInfoFromPCLFile() etc. functions, you can call these functions to retrieve page count from existing PS and PCL files, please refer to a VB.NET example from following page,

http://www.verydoc.com/pcl-page-count/pcl-page-count.html

if you encounter any problem with our PCL Page Counter SDK, please feel free to let us know, we will assist you asap.

VeryPDF
======================
We have tested your Page Counter SDK and have a few questions:

* what does bIsRenderToPDF do?

* can you provide us with a list of possible paper sizes that can be returned?

* what is the expected behavior of ReadInfoFromPSFile() vs. ReadInfoFromPCLFile() given different print language file types, we have noticed that they (usually?) can parse both types.

* we have noticed that when parsing fails, the return value does not always indicate failure, instead, it is more common that a successful parsing is indicated and that 1 b/w page with paper size LETTER is returned. Do you have documentation as to when we can expect which type of behavior?

* if the input files are not named .pcl or .ps, how do you recommend we use your SDK? Should we try to parse the file headers to determine if the file is postscript or PCL before calling ReadInfoFromPSFile() or ReadInfoFromPCLFile(), or should we just always call either of these functions (as I mentioned before, they both seem to be able to parse both postscript and PCL files)

* do you have any information regarding how well this scales performance wise when running multiple instances on a server with multiple CPU/cores?

* do you have any figures for expected performance/memory usage given different file types/sizes?

Please do reply even if you can't answer all of the questions.
==============================
Hi,

>>We have tested your Page Counter SDK and have a few questions:
>>* what does bIsRenderToPDF do?

If you set bIsRenderToPDF to TRUE, Page Counter SDK will able to count Black and White pages and color pages separately.
>>* can you provide us with a list of possible paper sizes that can be returned?

It will return following paper sizes,

{"eLetterPaper", 8.5, 11},
{"Letter", 8.5, 11},
{"eLegalPaper", 8.5, 14},
{"eA4Paper", 8.3, 11.7},
{"A0", 33.11, 46.81},
{"A1", 23.39, 33.11},
{"A2", 16.54, 23.39},
{"A3", 11.6929, 16.535433},
{"A4", 8.2677, 11.6929},
{"A5", 5.83, 8.27},
{"A6", 4.13, 5.83},
{"A7", 2.91, 4.13},
{"eExecPaper", 8.5, 11},
{"eLedgerPaper", 17, 11},
{"eA3Paper", 11.7, 16.5},
{"eCOM10Envelope", 8.5, 11},
{"eMonarchEnvelope", 8.5, 11},
{"eC5Envelope", 8.5, 11},
{"eDLEnvelope", 8.5, 11},
{"eJB4Paper", 8.5, 11},
{"eJB5Paper", 8.5, 11},
{"eB5Paper", 7.17, 10.12},
{"eB5Envelope", 6.93, 9.84},
{"eJPostcard", 8.5, 11},
{"eJDoublePostcard", 8.5, 11},
{"eA5Paper", 5.83, 8.27},
{"eA6Paper", 8.5, 11},
{"eJB6Paper", 8.5, 11},
{"JIS8K", 8.5, 11},
{"JIS16K", 8.5, 11},
{"JISExec", 8.5, 11},
{"B0", 39.37, 55.67},
{"B1", 27.83, 39.37},
{"B2", 19.69, 27.83},
{"B3", 13.90, 19.69},
{"B4", 9.84, 13.90},
{"B5", 6.93, 9.84},
{"B6", 4.92, 6.93},
{"B7", 3.46, 4.92},
{"B8", 2.44, 3.46},
{"B9", 1.73, 2.44},
{"B10", 1.22, 1.73},
{"LEDGER", 17, 11},

As well as all paper size listed at following web page,

http://msdn.microsoft.com/en-us/library/dd183565(v=vs.85).aspx
>>* what is the expected behavior of ReadInfoFromPSFile() vs.
>>ReadInfoFromPCLFile() given different print language file types, we have noticed that they (usually?) can parse both types.

Yes, ReadInfoFromPSFile() and ReadInfoFromPCLFile() functions will do same work in the latest version, they will check the input file format and call correct function automatically.
>>* we have noticed that when parsing fails, the return value does not
>>always indicate failure, instead, it is more common that a successful
>>parsing is indicated and that 1 b/w page with paper size LETTER is
>>returned. Do you have documentation as to when we can expect which type of behavior?

"paper size LETTER" and "1 b/w page" are default values, if Page Counter SDK can't parse your input file format, it will return FALSE. However, if you encounter a PS/PCL file that can't be parsed by Page Counter SDK, please email that file to us for checking, we will figure out a solution to you after we checked your sample file.
>>* if the input files are not named .pcl or .ps, how do you recommend we use your SDK?
>>Should we try to parse the file headers to determine if the file is
>>postscript or PCL before calling ReadInfoFromPSFile() or
>>ReadInfoFromPCLFile(), or should we just always call either of these
>>functions (as I mentioned before, they both seem to be able to parse
>>both postscript and PCL files)

No, Page Counter SDK will check the file header and call correct functions automatically, you can always call ReadInfoFromPSFile() function to count the pages in PS or PCL files, you needn't parse the file header by yourself.
>>* do you have any information regarding how well this scales performance wise when running multiple instances on a server with multiple CPU/cores?

We haven't a performance report yet, however, if you will run multiple instances on a server with multiple CPU/cores, the speed will be fast enough.
>>* do you have any figures for expected performance/memory usage given different file types/sizes?

Sorry, we haven't a performance report for memory usage at the moment.

VeryPDF
========================================
Thanks you for a prompt and detailed response!
I have now written an application and done some testing, but have encountered a problem.

I want to use the parsers ability to check the file header and call correct functions automatically. This does work well.
There is a problem with the number of copies though.
When a Postscript document is parsed, the number of pages returned is multiplied with the number of copies, but not when parsing PCL.

Both ReadInfoFromPCLFile and ReadInfoFromPSFile have these results on my test files:

PCL 2 pages 3 copies -> parser returns 2 pages, 3 copies
PS 2 pages 3 copies -> parser returns 6 pages, 3 copies

I think that maybe the parser does have a consistent behavior here, but if I don't know if the print job is PCL or PS, I will now know how I should handle the number of copies.

There are two ways you could fix this:
1. make the copy behavior consistent across PS and PCL
2. add another return value that tells me if the file is Postscript.

The files I used for testing are available for download at

XXXXXXXXXXXXXXXXXXX

========================================
Thanks for your message, you can check Postscript format easily, just read the file hearder, if file header contains following line,

%!PS-Adobe-3.1

It is indicate this is a PS format, then you can process it by your rule.

We can also provide a new version to you with "make the copy behavior consistent across PS and PCL", you can purchase the product from our website, email to us your Order ID, we will ask our engineer to check your files and provide a new version to you asap, we will solve all of your problems in the new version.

VeryPDF