|
Re: Windows print driver
by afoken (Chancellor) on Nov 11, 2015 at 07:30 UTC
|
In the old days, a friend told me about a trick to make a virtual printer emitting PDF files. It used Ghostscript for Windows, a "magic" ghostscript command line entered into a tool named RedMon. RedMon is still available, and it can do more than just starting Ghostscript and prompt for an output filename. It can be configured to run a program that will handle output on its own.
RedMon feeds the print job into STDIN of the program. The format depends on the printer driver used, typically you use some color postscript printer (some ancient Apple LaserWriter or the Ghostscript PDF driver distributed with Ghostscript). Additionally, some environment variables are set. Programs may write to STDOUT. This is quite similar to how CGI works.
It should be quite easy to create a wrapper for Ghostscript that forwards STDIN to Ghostscript, makes Ghostscript write a PDF to a temporary file (similar to PDF writer in the manual), and automatically uploads that temporary file to the server. Document name, user name and machine name are availabe in the environment (see above). The most interesting ones for you should be REDMON_DOCNAME, REDMON_USER, REDMON_MACHINE, REDMON_BASENAME. RedMon should start that wrapper instead of Ghostscript, configured as "program handles output". After the upload, the temp file should be deleted.
The users see just another printer with a catchy name like "Upload as PDF to the documents server". No questions asked. Perhaps the wrapper pops up a message box "Upload completed" after the job is done.
If the users may work offline, the wrapper needs to detect that and collect temp PDF files and all required environment variables for later upload. A second program should try to upload the temp files as soon as the user is back online.
Alexander
--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
| [reply]
[d/l]
[select] |
|
|
That sounds just like the kind of sorcery they are asking for. I'll play with it and see if it will be feasible. Thanks for the information!
| [reply] |
Re: Windows print driver
by LanX (Saint) on Nov 10, 2015 at 23:32 UTC
|
What's the interface you are envisioning?
Something like a right-click option ("open with") in the context menu should be possible by associating your application to PDF (be by extension or by mime-type)
But I have to admit I never tried this again since W98 ...
UPDATE
Additionally PDF printer drivers normally allow to print to file. You could choose BUK's suggestion of a monitored shared drive as default destination. (just call it "SQL-Upload" or similar)
see also Win32::ChangeNotify for an alternative in monitoring a directory.
| [reply] |
Re: Windows print driver
by BrowserUk (Patriarch) on Nov 10, 2015 at 22:32 UTC
|
Thye mechanism I would use for this consists of two parts:
- Write a Perl script that creates and monitors a Named Pipe using Win32::Pipe.
- Run that script as a service and set up a Windows share for it on the network.
Users then simply copy (drag&drop) their files to the share and the service takes care of the rest.
With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l] |
|
|
Users then simply copy (drag&drop) their files to the share and the service takes care of the rest.
Um, when I informed them they could drag and drop their files to the "browse" button within the browser page, it was declared "too much work". ...I wish I were kidding... They want something directly from their application (whatever that may be at any given time) to magically submit these files for them.
*sigh*
| [reply] |
Re: Windows print driver
by SuicideJunkie (Vicar) on Nov 10, 2015 at 20:41 UTC
|
My condolences. Even generic people using facebook can upload files so you must be facing some serious users. It sounds like a print driver will also be too complicated and won't work out. I expect there will be a lot of strange documents being sent to you and a lot of oddly similar complaints about the printer not working. You might also consider giving them an address they can send attachments to.
| [reply] |
|
|
"Serious" users? No. Just lazy. Heaven forbid they actually DO something. Thank you for the well wishes. I need it today.
I figured a driver would be cumbersome. Of course, I've been surprised before. Sometimes the easiest things are the things you assume are going to be difficult and vice versa.
An email sounds interesting and I could easily implement it. However, it would be the same number of steps. This system is replacing a complicated duct-tape and bailing wire scenario. Right now, they are using a print driver to generate and save the pdf's to a network location, never to be seen again...especially if they didn't put them in the correct location in the first place (not that it ever happens...cough, cough). Filling out a web form, remembering where they saved their file, selecting the files, and then deleting them? That's just "too much work".
I move mountains with the holy spirit of perl and it's not good enough. I'm dumbfounded right now...
| [reply] |
|
|
<mode="funny"> Perhaps in this case, "users" is synonym for "issues"? </mode>
| [reply] |
|
|
