Problems with correct color rendering

Anders, please provide DownloadURL to some PDF samples or send them per email at: quickpdf(at)gmx.net

Jan

Depending on your software and the number of customers this could be an alternative solution for you:

http://www.glyphandcog.com/XpdfPrint.html

We are using this in our application. There are no serial numbers or activation needed for distribution. Support also is very good.

Hi

And regarding you demo problem you should send this file to me as well. You will see if it could help you with your problem (you have nothing to loose).

Hi

Don't get stressed about this subject - my customers has been used to this for 1½ years now, so take the time you need.

Hi Jan,

Edited by marian_pascalau - 18 Dec 06 at 7:42AM

Jan,

 

Your see, when I begun releasing source code updates some of our community members where not so happy with my new design. It took me a lot of time to make this source code more visible to me and take control over it's implementation (rendering).

 

The problem is that the old source code failed on the path to it's next level and needed some sorts of redesign.  Despite the fact that this project expose a huge amount of valuable information it fails quite often an really small things a situation more than unpleasant (I have identified a lot of strange situations and fixed a lot of errors in seconds for bugs which took me days to understand).

 

At the moment I am trying to find support for a small investment in studying the PDF specification. With each bug resolved I need to go much too deep in theory and this costs me too much time.  

 

Jan, I do believe that with some sort of support it is possible to make this library better and  useful for all of us.  If you really believe the same you can count on me.

 

Best regards,

Marian

Edited by marian_pascalau - 18 Dec 06 at 7:05AM

Jan,

Thank you marian, I will. I am very thankful for the great job you are doing!

Edited by anders_hg - 18 Dec 06 at 12:51PM

chicks wrote: How about free? Adobe Reader is still the ONLY component I've found that renders PDFs the way you expect them to render. It has two programmatic interfaces, the ancient but reliable DDE interface, and the new (as of Reader 7) OLE/COM interface, both of which can be used to print PDFs. Since Reader is nearly universally installed, it's an easy choice for me. There are some usage examples for both the DDE and OLE interfaces here: http://www.esnips.com/web/PDFTools

I've just about given up on using Quickpdf for rendering. It is great at creating and manipulating, but I just think it has too many problems to be overcome in rendering without a real commercial enterprise footing the bill for development.

I've posted code in the samples forum that attempts to duplicate your pdfp program in Delphi without the need to shell out, I would appreciate any help you could give me with that.

Thanks
Harry

chicks wrote: Wish I could help, but I've never really used Delphi (attempted it once without much success). I should note that using Reader for printing high volumes of PDFs isn't a very good option, since it doesn't have a commandline interface, and any errors pop up dialog boxes.

I'm curious about what you consider "high volume". In our application a user will normally have to print a set of documents that is anywhere from 20 to 30 pages. They have to do this several times per hour.  Normally we don't want them exposed to any pop ups, but if it is to deal with a problem (out of paper or toner for example) that is not such a bad thing.

Our real problem at this point is more a matter of perception. For years we just printed pcl5 documents using passthrough and all was well. However the customers were insistent that they had to be able to preview the documents before printing and the best option for doing that was to switch to acrobat format and use reader to display. If they just print the document from Reader they can see that it prints very fast on most all Laserjet printers, but if they print from our application using Quickpdf rendering it is much slower. Printing a set of documents using Quickpdf rendering takes just over 5 minutes on an HP 4250. Even customers with older Laserjets can print reasonably fast using Adobe, but it is very slow using Quickpdf. It would be much easier to explain to them that they needed to spend another $900 per branch if they could not see that printing from Acrobat is not an issue on their existing printer.

Thanks
Harry

chicks wrote: BTW, Reader 7 & 8 now have an ActiveX control that allows you to visually embed Reader in your application for previewing. You can also print from this control, although you would need to use the print method that pops up a print dialog to use other than the default printer.

That is what we have been using to display the documents, and it is that control that got us in trouble. They could see how fast it printed from that and how slow it was when we used Quickpdf to do it directly. I spent a good deal of time trying to make that control print without the dialog box, but we do need to use different printers so it just wouldn't work, or at least I never figured out how to make it work.

So far it looks like the DDE solution is going to work even better than I expected, so all I have to worry about is how long Adobe is going to make that available in future versions.