Printing from QuickPDF
Printed From: Debenu Quick PDF Library - PDF SDK Community Forum
Category: For Users of the Library
Forum Name: General Discussion
Forum Description: Discussion board for Debenu Quick PDF Library and Debenu PDF Viewer SDK
URL: http://www.quickpdf.org/forum/forum_posts.asp?TID=172
Printed Date: 22 Nov 24 at 7:59PM
Software Version: Web Wiz Forums 11.01 - http://www.webwizforums.com
Topic: Printing from QuickPDF
Posted By: jabaltie
Subject: Printing from QuickPDF
Date Posted: 08 Nov 05 at 5:01AM
|
I'm trying to print a PDF from inside QuickPDF but the logotype it contains (image) wont show up at the paper.
When I print the same PDF from Acrobat, it works fine. There must be something related to the PDF that I dont know... The PDF I'm loading can be get from here : http://www.DES.online.unimep.br/au/test.pdf And, below is the code I'm using to print it : OPTION EXPLICIT DIM objMyForm,nReturn,nCount,nI,fName,fValue,poptions Set objMyForm = WScript.CreateObject("ISED.QUICKPDF") WScript.Echo objMyForm.unlockkey("...") if objMyForm.LoadFromFile("TEST.PDF") = false then MsgBox objMyForm.LastErrorCode() Wscript.Quit(1) end if nReturn= objMyform.PrintOptions(0,0,"JobTitle") WScript.Echo nReturn poptions=objMyForm.PrintDocument("MYHPG85",1,1,nReturn) What it could be ? - The printer driver ? - Something wrong with the PrintDocument method ? - Chicks suggested me the GDI+ Library. What is it ? Is it free ? |
Replies:
Posted By: chicks
Date Posted: 08 Nov 05 at 11:40AM
|
Jose,
Again, it's just a guess, but if you're on Win2K or earlier, you may not have GDI+ installed. If you're on XP, it's part of the OS. http://www.microsoft.com/downloads/details.aspx?FamilyID=6a63ab9c-df12-4d41-933c-be590feaa05a&DisplayLang=en Also, try another printer, it printed for me on three different printers without problems. |
Posted By: jabaltie
Date Posted: 08 Nov 05 at 1:34PM
|
Chicks :
Thanks again 4 your help ! I updated the GDI Plus as you suggested on a W2K machine and it worked fine. However, on my own machine, which is a W98, it is still not working. I dont know how to update it... Also, 98 % of my clients machines are W98. I have to figure out a strategy to update them all... |
Posted By: chicks
Date Posted: 08 Nov 05 at 2:32PM
|
Do they all have Adobe Reader installed? I have a commandline app that can print PDFs silently using Reader versions 4 and up...
Also, according to this site: http://www.geopainting.com/en/gdiplus.html it's apparently the same .dll for all OS'. You "should" be able to simply download their .zip, extract gdiplus.dll, and copy it to \windows\system32... |
Posted By: jabaltie
Date Posted: 08 Nov 05 at 2:42PM
|
Hi Chicks !
I found how to solve the problem : just copied GDIPLUS.DLL on the same directory of the application and it worked fine ! As for Acrobat, I dont care if they have or not because QuickPDF doesnt demand it. Thanks again 4 your help ! |
Posted By: chicks
Date Posted: 08 Nov 05 at 2:52PM
|
Cool!
Say hello to that "Girl From Ipanema" for me... |
Posted By: Michel_K17
Date Posted: 08 Nov 05 at 10:54PM
|
Also, keep in mind that the QuickPDF library has a "loadlibrary" command so that you can tell it where GDI+ is located. Here are the specifics:
SetGDIPlusFileName Description Sets the path and filename of the GDI+ DLL (gdiplus.dll) used by the RenderDocumentToFile and DARenderPageToString functions. This can usually be left at the default, which means the DLL will most probably be stored in the windows/System folder, but on webservers, etc. it may be necessary to store the file in a different location. Definition function SetGDIPlusFileName(DLLFileName As String) As Long Parameters DLLFileName The path and file name of the GDI+ DLL, for example "c:dllsgdiplus.dll". Returns 0 The specified file could not be found. 1 The GDI+ DLL file name was set successfully. |
Posted By: jabaltie
Date Posted: 10 Nov 05 at 5:14AM
|
Hi MIchel !
Thanks 4 your help. Nevertheless, the thing is : my original application, which is written in XBase++ (a Clipper 32 bits language) I could make it work fine using GDIPLUS.DLL on the same dir as the EXE. However, when using VBScript, I still cant make it work. I tried to put GDIPLUS.DLL on the same directory as the script and it wont work. Also, tried to put it on the same place as CSCRIPT.EXE. Wont work either. Then I tried your function call. Still wont work. This is my script : OPTION EXPLICIT Dim QP Set QP = CreateObject("iSED.QuickPDF") Call QP.UnlockKey("-mykey-") if QP.SetGDIPlusFileName("C:\RPS\GDIPLUS.DLL") = 0 Then WScript.Echo "Could not load GDIPLUS..." WScript.Quit End If Call QP.PrintDocument("HPG85", 1, 1, QP.PrintOptions(2, 1, "TEST.PDF")) set QP = nothing Any clues ? |
Posted By: jabaltie
Date Posted: 10 Nov 05 at 5:22AM
|
OPS, sorry !
The script was wrong... Even fixing it however, the only way to make it work is to put the dll on c:\windows\command. The SetGDIPlusFileName function call seems to be useless at the script, although it's loading OK the dll : OPTION EXPLICIT Dim QP Set QP = CreateObject("iSED.QuickPDF") if QP.SetGDIPlusFileName("C:\RPS\GDIPLUS.DLL") = 0 Then WScript.Echo "Could not load GDIPLUS..." WScript.Quit End If Call QP.UnlockKey("mykey") if QP.LoadFromFile("C:\TEST\WSH\TEST.PDF") = false then MsgBox objMyForm.LastErrorCode() Wscript.Quit end if Call QP.PrintDocument("HPG85", 1, 1, QP.PrintOptions(2, 1, "TEST JOB")) set QP = nothing |
Posted By: chicks
Date Posted: 10 Nov 05 at 3:34PM
|
Jose,
It "should" work if it's anywhere in your %PATH%. At the command prompt, type PATH to get your configured path. I don't remember Win98 (been a while), but it should have something like "C:\windows\system32" or "C:\windows\system" in the path. This is where M$ would normally install it. QuickPDF should automagically use it if it's in your path somewhere. |
Posted By: jabaltie
Date Posted: 16 Nov 05 at 6:39AM
|
OK. I've moved it up to there , that is, C:\WINDDOWS\SYSTEM and now it's working.
Thanks again for your support. Thread closed. |
Posted By: student
Date Posted: 22 Nov 05 at 8:12PM
|
Did anyone run into this weird situation, when printing files automatically from ISED.DLL that there were JPEG files generated in the process.
Plus any suggestions about the large spool sizes on certain PDF files. |
Posted By: Ingo
Date Posted: 23 Nov 05 at 2:27AM
|
Hi!
The automatically generated jpg-work-files are a small bug. In the old forum Jan told that's a "forgotten debug-function"... Oliver gives there the advice... try this: - create a temporary, empty directory - set the current dir for your app to that directory - run your pdf-functions... - erase the temporary directory Best regards, Ingo ------------- Cheers, Ingo |
Posted By: swb1
Date Posted: 08 Dec 05 at 9:35AM
|
The offending code can be found around line 1046 of v5.11 uPDFImageDecoder.pas. If you are a site licensee (with source code) and using Delphi you can fix this problem by commenting-out lines 1046 through 1050 and re-compiling the library. swb |
Posted By: Michel_K17
Date Posted: 08 Dec 05 at 10:53PM
|
Thanks for the tip! I'll go fix my copy. Update: I commented out the lines you suggested, and it did the trick. Thanks!
By the way, even though iSed calls it v5.11, the actual version number of the compiled library says that it is v4.42, which makes more sense to me as there are very little differences between v4.41 and v4.42. But they did fix the "EncryptFile" routine. When was that again? A year ago? Wow... time flies. 
|