+1 to this: I think it's a clearer statement of what I was saying. The -print command line option actually uses the awt renderer and not the pdf renderer [pause while I check this - yes, PrintStarter$PrintRenderer extends AWTRenderer].
You can choose printers by making sure that pj.printDialog() gets called: this invokes the native OS print dialog box. You do this in PrintStarter by setting a system property called dialog to some value (cf PrintStarter line 70). ref quality, I've found that borders are fairly poor. Dvorak: fo is a format, pdf is a format, AWT is a format. Your xsl makes a document in fo format. All FOP does is translate from the fo format to another format of your choosing: all the user cares about is the piece of paper they end up holding, they don't care how many or which formats it passes through so long as it looks right. Alistair -----Original Message----- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 13, 2001 1:48 PM To: [EMAIL PROTECTED] Subject: quo vadis - RE - launch Acrobat Reader invisible Hi all, I'm a little confused about this exchange -- and wondering what is driving the interest in directly launching AcrobatReader ? We run fop and generate printouts directly using the -print option all the time and get 100% fidelity viz-a-viz producing pdf files from fop and then (manually) printing them. (Checked with a light table even!) We happen to be doing our production work via a shell command since the spawning application is in smalltalk, but we've also verified the approach runs just fine when we invoke fop directly via method calls from within a Java app (We simply inspected the command processor source and mimic'd what it does for -print.) We use standard fonts, as it turns out, but do embed gif's, generate 2 column text layouts with in-line column-spanning tables (whose contents include some column spanning data) and the results are just fine. I concede that -print only goes to the default printer and I'll admit that we needed to tweak the xslt to workaround certain "sensitivities"; but we're OK with that. We have a 100% cross platform solution and it isn't sold by micro$oft. >I think that all this system calling is a bit dodgy if you don't control the >target environment: I looked at it for a while but felt that I couldn't >prevent things going badly confusing for the user if they had any deviance >in their setup. > >And it obviously throws away the cross-platform nature of things. > >Nobody interested in the AWTRenderer / PrinterJob pure java approach? Even >lets you do the print dialog thing... ' Best, -Ralph LaChance --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
