VeryPDF Knowledge Base

Hi Guys,

We have a requirement where we want a ability to print series of PDF documents to printer on single click of Button.

We came through PDF print on VeryPDF.com. Can you please answer few of our below questions?

1. We have only PCL printers, is pdf print will work fine with the PCL printers.

2. If we will buy the server license for “VeryPDF PDFPrint SDK Version v2.0”, does we are going to get support for the product. If yes how long we can get the support.

Thanks
=======================================

Hi,

>>1. We have only PCL printers, is pdf print will work fine with the PCL printers.

Yes, PDFPrint Command Line does support all PCL Printers.

>>2. If we will buy the server license for “VeryPDF PDFPrint SDK Version v2.0”, does we are going to get support for the product. If yes how long we can get the support.

Thanks for your message, we are provide One Month Free Gold Support for Server License and Developer License since your purchase date, after you purchased it and if you encounter any problem within first month, please feel free to let us know, we will solve your problem for you asap, after first month, you may purchase gold support to enjoy Gold Support Service continue.

Please look at following page for the more information about the "Gold Support",

https://www.verypdf.com/custom/maintenance.htm

VeryPDF

I put in the request for VeryPDF, and have implemented it into our Webservice client.  Things are working fine. There will still may be some tuning, but mostly it is working.

I use dynamic linking of the DLL (first time a PDF arrives for a client, which may be never).  I then simply keep the DLL loaded.  Also, I do not store the registration code in memory.  I ‘build’ it, then use it, and then make sure all memory buffers used temporarily are memset.  There is no strings in my exe listing the reg code at all (or any part of it).  I know that the usage like this was not specified in your "how to use", but this is something I do any time I have to deal with keys/reg codes, so that it is much more difficult for any end user to determine what the reg code is.

My question is on deployment.  Exactly what needs to be deployed?  Do I simply add the 3 dll's to the install script, and that is it?   I notice
an "encoding" directory with many Adobe postscript font files.  The pdf printer seems to print just fine without them.  Do they have a purpose, or can they simply be left out of the installation data set?
=================================================

Yes, you need deploy 3 DLL files along with your product to your customers.

If your PDF files are not contain CJK characters, you can ignore "encoding" folder, "encoding" folder is useful for CJK PDF files.
VeryPDF
==================================================

I have very pdf incorporated into our software, and working. However, I am experiencing some issues. Our product is a long running service 'like' product. The algorithm I am 'using' is this:

0. Wait for file message to print (web service calls to our corp site to check for new messages). Until one arrives, we stay in step 0.

1. Download the message file to print.

2. File is checked to see if PDF. If no PDF, then original text printing code is performed, then goto step 0.

3. if file is pdf, then:

4. if DLL not loaded, load it.

5. Build reg code.

6. call DLL function, using: sprintf(szCommandLine,"pdfprint \"-$\" \"%s\" -silent -restoreprinter -quiet -pdforient 4 -scalex -1 -scaley -1 -printer \"%s\" \"%s\"", lpRegcode,lpPrinterName,lpPDFName);

7. clean up the reg code string.

8. sleep 3 seconds.

9. goto step one.

Here are the issues I am seeing.

1. The code is consuming 100% of 1 CPU, but mostly in system CPU cycles. The %CPU is not being charged to my process, but to Windows explorer

2. The memory footprint grows. It does not 'appear' to be a memory leak, but possibly memory fragmentation.

Now my question. Is keeping the DLL loaded, the proper way to use this product, for a long running process? I have made some changes, and things appear to have changed. The changes I made are:

'before' step 4 of my algorithm, I added code to free the DLL, and set my flags to appear not loaded, every 20 PDF documents printed.

By making that simple change, the CPU usage dropped to about 1/2 of a CPU (still charged to system CPU). Also, at this time the memory 'growth' seems to not be happening, at least, not as bad as it was before. I still need to have the process run a little longer, before I can make a claim that I think it is working without leaks/fragmentation, but it certainly appears to be working better than before.

So, again back to the question, HOW should this product be used for long running processes?

Should the DLL be loaded each time, used, then freed, then loaded on next pdf file to print?

Should it be loaded, and used for a short while (a few minutes, or a few documents), and then freed and reloaded on next message?

Should it be able to be loaded one time (the first pdf seen) and then used 'forever'?

Also, could this be some command line argument(s) that I am NOT using, but should use?
======================================================

Hi,

Thanks for your message, we have a suggestion to you, we suggest you may call PDFPrint SDK functions in a stand-alone EXE application, you can call this EXE application to print all of your PDF files, the EXE process will exit from memory automatically after printing be finished completely, the EXE process will release its memory and CPU too, we hoping this solution will helpful to you, you may give it a try.

Please change your steps as following,

0. Wait for file message to print (web service calls to our corp site to check for new messages). Until one arrives, we stay in step 0.
1. Download the message file to print.
2. File is checked to see if PDF. If no PDF, then original text printing code is performed, then goto step 0.
3. if file is pdf, then:
//You can delete following steps,
//4. if DLL not loaded, load it.
//5. Build reg code.
//6. call DLL function, using: sprintf(szCommandLine,"pdfprint \"-$\" \"%s\" -silent -restoreprinter -quiet -pdforient 4 -scalex -1 -scaley -1 -printer \"%s\" \"%s\"", lpRegcode,lpPrinterName,lpPDFName);
//7. clean up the reg code string.
//8. sleep 3 seconds.
4. You can call PDFPrint SDK EXE process to print this PDF file, wait until EXE process exit from memory,
9. goto step one.

This solution can be done easily, please give it a try.
VeryPDF
================================================
Thank you for this suggestion. I am building a thin SDK exe to spawn, and believe this suggestion will get us past this issue. If I have additional issues, I will contact you with those. However, I believe this will get me to completion of the project.