Hi Bohdan,
On Tuesday, July 02, 2002, 5:33:39 PM, you wrote:
BoRL> I agree that PDF is more easily multiplatform, but sometimes you need the
BoRL> output to go directly to the printer without any additional human
BoRL> intervention.
That is absolutely true. However, users do not dislike to have a
screen preview of what they are going to print. At least, this has
not been a big problem to me, considering you are also giving the
user the ability so send the PDF via email etc. this way.
BoRL> It would be nice if Acrobat could be told via an external
BoRL> source (like REBOL) to print the current document.
Me and Gregg tried this using Window's ShellExecuteA; when asking
to print a PDF file, with something like:
win-lib: load/library %shell32.dll
execute: make routine! [
hwndParent [integer!]
Operation [string!]
File [string!]
Parameters [string!]
Directory [string!]
ShowCmd [integer!]
return: [integer!]
] win-lib "ShellExecuteA"
win-print-file:
func [file [file!]]
[ execute 0 "print" to-string to-local-file clean-path file "" "" 1]
we got inconsistent results unfortunately. I happened to me once
that win-print-file opened Acrobat and immediately sent the file
to the printer (without even showing it), but the first time I
tried it it only opened the file.
BoRL> Additionally, Acrobat
BoRL> loading on many machines is terribly slow.
That is true, too.
BoRL> It would be nice if REBOL had available printer support (kind of like
BoRL> Python, but better).
I agree, Bo. I just wanted to say that I've been able to live
without it, not that I wouldn't like to have it. ;-)
BoRL> Simple things should be simple to do.
Yes!
Regards,
Gabriele.
--
Gabriele Santilli <[EMAIL PROTECTED]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
--
To unsubscribe from this list, please send an email to
[EMAIL PROTECTED] with "unsubscribe" in the
subject, without the quotes.
