RE: Java 1.1.x
It is really old, but you could try this one: http://xml.apache.org/dist/fop/old/fop-0_14_1_jdk11.jar If you want to try building a version from CVS, you could try to get a version from just before Batik was added. There used to be an option on the build script package-jdk11 I think that got most of the way to a functioning version with JDK 1.1 (with limitations). You may need to fix some things, but it is a start. Art -Original Message- From: Kendall Adkins [mailto:[EMAIL PROTECTED]] Sent: Monday, May 06, 2002 2:18 PM To: [EMAIL PROTECTED] Subject: Java 1.1.x I have a client who is using a Domino server. Domino only supports the Java 1.1.8 SDK. I have been unable to find a version of FOP that will run with this SDK. Does anyone have any suggestions? Thank you in advance, Kendall Adkins [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FW: PCLRenderer
I sent
this directly to Yvonne, but I have received error messages from materna.de
indicating that it may not have gone through. Maybe it will be more successful
through the FOP list... and it could be interesting to others using the
PCLRenderer.
Art
-Original Message-From: Art Welch Sent:
Friday, April 26, 2002 12:09 PMTo: 'Moebius,
Yvonne'Subject: RE: PCLRenderer
Hi
Yvonne,
Unfortunately trying to pass control codes (either for font changes or
image data) is not likely to work very well. What I have done in the past when I
wanted a different font was to use one of the existing fonts that had metrics
similar to the font I wanted. This would allow the layout to work. Then
postprocess the PCL output and do a search and replace on the control codes.
This of course would be problematic if you want to use several non-standard
fonts. In my case I just needed to use alternate fonts for Helvetica and Times.
The alternates had almost identical metrics. This worked quite
well.
If you
are open to building your own custom version of FOP. The PCLRenderer uses a
function to map the font names to PCL control codes. You could add your fonts to
this function. This may work. I am assuming that the fonts are resident in the
printer and you have added the fonts to FOP. At one time I was actually thinking
that I would add all the standard PCL mappings to this function. If you do this,
I would be happy to commit your changes to CVS. Of course the larger case
includes support for fonts not resident on the printer. Supporting font download
looked a bit icky. Since the font names can be a bit fussy, another option may
be to add some kind of mapping (FOP font to printer font). But this all starts
getting complex.
Dithering is a technique to increase the apparent color depth of an
image. Basically you define a region of the image and use the available colors
to visually approximate a greater range of colors. The simplest way to do this
is to use pixel expansion to do this - essentially resolution is traded for
color depth. For example if you wanted to represent four shades of gray on a
device that can only set individual pixels to black or white you could use four
pixels to represent each source image pixel (doubling the size of the image).
The four shades could look like this ('.'=off, '#'=on):
.
.
.
.
.
#
#
.
.
#
#
#
#
#
#
#
This
is the idea anyway. A simple mapping does not really give the best results.
There are sophisticated algorithms that produce much better results. To
complicate things, the algorithm that produces the best visual results varies
with the source image, resolutions, color depths, etc. I would use an image
processing application to translate the images. There may be functionality in
the JDK to do this. I am on a "graphically challenged" platform, so generally
avoid the graphics APIs.
I hope
this helps,
Art
-Original Message-From: Moebius, Yvonne
[mailto:[EMAIL PROTECTED]]Sent: Thursday, April 25, 2002
3:04 AMTo: Art WelchSubject:
PCLRenderer
Hello
Art,
I am not sure if I
should send this e-mail to the FOP mailing list, but as youoffered me to
inform you about my main problems with the PCLRenderer, I am writing to you
directly.
The most important
thing for me is to include fonts, which are not included in the Adobe base 14
font package. But the limitation is that with the PCLRenderer only the
original fonts built into FOP are supported.
As long as the
PCLRenderer has got this limitation, I am thinking of a kind of workaround, to
tell the printer which fonts I want to use.I tried to sendthe font
information as PCL commands to my printer as unparsed CDATA. But these font
information contain the control character ESC, and this is not allowed
in CDATA.
Maybe you have got
any indeas for a better workaround?
The other thing I
find onerousare the fo:external-graphics, they only appear in
black and white, and I am missing the grey shades.On the output format
site (http://xml.apache.org/fop/output.html)
is written :"If you need to print a non-monochrome image you should dither it
first. " I don't know excectly what is meant with "dither" in this context.
Does it mean that there is any way to make the grey shades of my image
visible?
In this case, too,
I am thinking of including my images as unparsed PCL commands, but again there
is the problem with the control characters.
I would be
thankful if you have any ideas of how to work around these problems, or if you
can tell me if it will be possible to remove these
limitations.
Bye,
Yvonne
RE: PCL renderer limitations
Hmmm.
These are interesting.
On the
table problem, could it be that the part that appears to not be printing is
actually outside of the printer's printable area?
How
much is the image off center? If it just appears to be a little off center it
may be because the PCLRenderer only supports images scaled in discrete steps.
FOP's layout is unaware of this, so it may be placing the image based on what it
thinks the actual scaled size is - not the size the PCLRenderer will produce.
IIRC images are placed by the upper left corner - so this could cause an image
to appear off center.
HTH,
Art
-Original Message-From: Bruno Verachten
[mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002
5:35 AMTo: [EMAIL PROTECTED]Cc: Art
WelchSubject: Re: PCL renderer limitationsArt
Welch wrote:
[EMAIL PROTECTED]"
type="cite">
I
am the person who is mostly to blame for the PCLRenderer. Unfortunately I
have not been able to work on it for a while - and I do not know when I will
be able to do so. Of course anyone else is free to work on it - but I have
not seen many others doing much on it.
If
there are some particular limitations that you find most onerous, perhaps I
can take a look at them... especially if they are easy to fix. However the
main limitations that I am aware of will require significant effort. These
are restoring SVG support, adding font support, adding color support,
etc.
At
present I think that it is unlikely that any significant limitations in the
PCLRenderer will be addressed in the short term. It is quite possible that
this could change. Next week I am planning on trying to get more resources
committed to XML reporting at my employer. If successful, I may be able to
spend more time on FOP.Well, that's fine
;-)Hi, I have problems too with the PCL renderer. The PDF renderer works
fine for: -handling tables aligned right in the footer
("Page N°1/5" for exemple in a one cell table
aligned right). -handling images centered inside a
fo:block.I just can't do that with the PCL renderer, which doesn't
produce the whole thing in the footer(stops to "Page N°" and then ...
nothing more in the footer...). If I ever use a single fo:block aligned
right, this does work... Si this problem is not really urgent for
me.But the image centering is quite important, and I still haven't
found a new way of getting it centered.Can you help?Thanks a
lot!Bruno Verachten.
RE: PCL renderer limitations
If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Art -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:01 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitationsArt Welch wrote: [EMAIL PROTECTED]" type="cite"> Hmmm. These are interesting. On the table problem, could it be that the part that appears to not be printing is actually outside of the printer's printable area?Maybe... [EMAIL PROTECTED]" type="cite"> How much is the image off center? Totally ;-) [EMAIL PROTECTED]" type="cite"> If it just appears to be a little off center it may be because the PCLRenderer only supports images scaled in discrete steps. FOP's layout is unaware of this, so it may be placing the image based on what it thinks the actual scaled size is - not the size the PCLRenderer will produce. IIRC images are placed by the upper left corner - so this could cause an image to appear off center.I'm sorry, but what are IIRC images? Here is the fo code I have:fo:block text-align="center" text-indent="1em" space-before="0.6em" space-after="0.6em" font-size="10pt" display-align="center"fo:external-graphic src="Logo.gif" content-height="53px" content-width="88px" scaling="uniform" scaling-method="auto"//fo:blockThanks.Bruno Verachten
RE: PCL renderer limitations
Sorry, I'm American and my grammar is pretty bad. I think that your english is probably still better than mine... -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 1:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitationsRhett Aultman wrote: [EMAIL PROTECTED]" type="cite"> IIRC == "If I recall correctly." The statement would thus read, "If I recall correctly, images are placed by the upper left corner..."Oopss... Sorry, I'm french AND my english is pretty bad...Thanks for your necesseray help ;-)Later,Bruno Verachten
RE: PCL renderer limitations
If the PDFRenderercenters the image properlyand the PCLRenderer does not then it is probably a bug in FOP (likely the PCLRenderer) not a problem with the FO code. Art -Original Message-From: Bruno Verachten [mailto:[EMAIL PROTECTED]]Sent: Friday, April 26, 2002 2:11 PMTo: [EMAIL PROTECTED]Subject: Re: PCL renderer limitations [EMAIL PROTECTED]" type="cite"> If the image is totally off center, then the problem is probably not related to scaling. "IIRC images", sorry I should have included a comma in there as in: "If I remember correctly, images..." It seems a bit odd to me that the PDF renderer would center the image properly and the PCL renderer would not center it at all. I have not looked at the code in a long time, but I thought that FOP did all the layout before calling the renderer. So it should just be saying "put the image here" and supplying the appropriate coordinates to the renderer. But it is entirely possible that this had changed - or perhaps even more likely - I am not remembering correctly. I have not looked at FOP code much since the redesign started. Okay... If you have time on your hands next week, I can send my fo code to the list.I have to leave now (8pm here), so ... have a nice week-end.Thanks for the answers, including the ones about shorthands ;-)Bruno Verachten.
RE: PCL renderer limitations
Hi Yvonne, I am the person who is mostly to blame for the PCLRenderer. Unfortunately I have not been able to work on it for a while - and I do not know when I will be able to do so. Of course anyone else is free to work on it - but I have not seen many others doing much on it. If there are some particular limitations that you find most onerous, perhaps I can take a look at them... especially if they are easy to fix. However the main limitations that I am aware of will require significant effort. These are restoring SVG support, adding font support, adding color support, etc. At present I think that it is unlikely that any significant limitations in the PCLRenderer will be addressed in the short term. It is quite possible that this could change. Next week I am planning on trying to get more resources committed to XML reporting at my employer. If successful, I may be able to spend more time on FOP. Art -Original Message-From: Moebius, Yvonne [mailto:[EMAIL PROTECTED]]Sent: Tuesday, April 23, 2002 5:19 AMTo: Fop Dev (E-Mail)Subject: PCL renderer limitations Hi, can you tell me if the PCL renderer will be improved? There are a lot of limitations, will they (or some of them) be abolished in the next release? Can you make a rough estimate how long it will take to abolish all these PCL-renderer limitations? Y. Moebius
RE: [Vote] New committers: Peter West, Joerg Pietschmann?
This is way cool - more committers. I am sure that they will be more productive than myself. A big +1 for all three (did I miss the e-mail for Jeremias?). Art -Original Message- From: Christian Geisert [mailto:[EMAIL PROTECTED]] Sent: Thursday, April 11, 2002 6:29 PM To: [EMAIL PROTECTED] Subject: Re: [Vote] New committers: Peter West, Joerg Pietschmann? Keiron Liddle wrote: I propose that we offer Peter West and Joerg Pietschmann to become committers. +1 and while we are at it in addition I would like to propose Jeremias Märki as committer (I'll send an extra mail) Christian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Images and JDK 1.1
I do not think that FOP 0.20.3 will work with JDK 1.1. I think that it requires JDK 1.2 or above. Sorry, Art -Original Message-From: Marco Fabbri [mailto:[EMAIL PROTECTED]]Sent: Saturday, April 06, 2002 10:24 AMTo: [EMAIL PROTECTED]Subject: Images and JDK 1.1 Hi all, I haven't found FAQ about it so... Sorry in advance for the poor question. I need to use fo:external-graphic on a JDK 1.1 and FOP 0.20.3 environment. What I have to do? I've added the jimi1-0.jar on the classpath but it wasn't enough... Marco Fabbri
RE: How format to dot-matrix printers (ESC/P)
My first suggestion would be to use Acrobat or something to print the PDFs. Second (or maybe it should be first) would be to use the AWT based print renderer to print to the printer. I have not used this, but shouldn't AWT be able to print to any printer for which it has a suitable driver. Maybe this works better under M$ Windows. Most of my work these days is with Unix and until recently on our systems AWT did not work well and when it did I think that it would only print PostScript. YMMV. Next if the formatting is not very fancy then I would suggest generating the text/ESCP using just XSLT (with an extension function for the special characters). The TXTRenderer assumes that the font for output does not change. Last time I checked ESC/P printers should accept plain ASCII text without the need for additional control codes (other than CR,LF). This is what the TXTRenderer produces. The problem is that with the exception of some special cases, the output produced by the TXTRenderer is UGLY. As to CHR(18) and CHR(27), I guess that may depend on how the XML parser interprets legal characters of Unicode and ISO/IEC 10646 (from the XML W3C Rec). Being below CHR(32) I suspect that they will probably be rejected as not a valid XML character. If you want pretty output and can not post process one of the current output formats then you are probably looking at a new renderer. Art -Original Message- From: Clóvis Wichoski [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 12:59 PM To: [EMAIL PROTECTED] Subject: How format to dot-matrix printers (ESC/P) Hi FOP team, I'm using FOP for generating PDF's, but now I need use FOP to generate text files (txt) for dot-matrix printers using Epson ESC/P, and I have following questions: 1) I need create my own Renderer? if yes, what I need to share this with FOP-DEV 2) Can I do this with TXTRenderer? if yes, How put chars like CHR(27) CHR(18) in txt? Best regards Clóvis Wichoski Supridatta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: How format to dot-matrix printers (ESC/P)
If all you need to do is set compressed mode and the TXTrenderer produces acceptable output for you then you could open the output stream, send the desired escape sequence then call FOP with the TXTRenderer passing it the stream. Another idea if you are using M$ Windows may be to use a different printer driver. Windows used to have a plain text driver. If they still do (I just checked on my Win2K workstation and they have Generic/Text Only in the driver list), maybe Acrobat could print to this. A Renderer for Epson printers would be interesting, although I suspect that ESC/P2 would probably be more popular. Targeting Epson's popular color ink jet printers vs. the dot matrix. It would probably be better to start with the PCL renderer as a base for an ESC/P renderer. Art -Original Message- From: Clóvis Wichoski [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 4:00 PM To: [EMAIL PROTECTED] Subject: RE: How format to dot-matrix printers (ESC/P) I'm already using PDFs to print, but some dot-matrix printers are too slow to print graphics. the question about chars, it is because I need print in condensed mode CHR(18) and 8 lines per inch CHR(27)+CHR(0) the question about new Renderer it is because we can make a standard for print in ESC/P using FO also. Would be interresting implement this? Or Extend TXTRenderer to make this? Clóvis Original Message On 21/03/02, 16:08:40, Art Welch [EMAIL PROTECTED] wrote regarding RE: How format to dot-matrix printers (ESC/P): My first suggestion would be to use Acrobat or something to print the PDFs. Second (or maybe it should be first) would be to use the AWT based print renderer to print to the printer. I have not used this, but shouldn't AWT be able to print to any printer for which it has a suitable driver. Maybe this works better under M$ Windows. Most of my work these days is with Unix and until recently on our systems AWT did not work well and when it did I think that it would only print PostScript. YMMV. Next if the formatting is not very fancy then I would suggest generating the text/ESCP using just XSLT (with an extension function for the special characters). The TXTRenderer assumes that the font for output does not change. Last time I checked ESC/P printers should accept plain ASCII text without the need for additional control codes (other than CR,LF). This is what the TXTRenderer produces. The problem is that with the exception of some special cases, the output produced by the TXTRenderer is UGLY. As to CHR(18) and CHR(27), I guess that may depend on how the XML parser interprets legal characters of Unicode and ISO/IEC 10646 (from the XML W3C Rec). Being below CHR(32) I suspect that they will probably be rejected as not a valid XML character. If you want pretty output and can not post process one of the current output formats then you are probably looking at a new renderer. Art -Original Message- From: Clóvis Wichoski [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 21, 2002 12:59 PM To: [EMAIL PROTECTED] Subject: How format to dot-matrix printers (ESC/P) Hi FOP team, I'm using FOP for generating PDF's, but now I need use FOP to generate text files (txt) for dot-matrix printers using Epson ESC/P, and I have following questions: 1) I need create my own Renderer? if yes, what I need to share this with FOP-DEV 2) Can I do this with TXTRenderer? if yes, How put chars like CHR(27) CHR(18) in txt? Best regards Clóvis Wichoski Supridatta - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Using FOP with xmlspy
Is that XMLSpy that only works with Win2k? FOP most definitely is NOT limited to Win2k. FOP should work on any platform with full JDK 1.2+ and AWT support. -Original Message- From: Joe Sytniak [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 6:19 PM To: [EMAIL PROTECTED] Subject: Re: Using FOP with xmlspy According to tech support, FOP only works with Win2k - Original Message - From: Savino, Matt C [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, March 18, 2002 6:11 PM Subject: RE: Using FOP with xmlspy I know FOP through XMLSpy doesn't work on NT, I think that may apply to Win98/95 as well. Matt Savino -Original Message- From: Malcolm Sinclair [mailto:[EMAIL PROTECTED]] Sent: Monday, March 18, 2002 3:08 PM To: [EMAIL PROTECTED] Subject: Using FOP with xmlspy Please excuse my asking this question on a developer's forum -- I realise it's off-topic. Can you give me some hints, or can you put me in touch with someone who has successfully produced PDFs from .xml files in xmlspy? I have done this quite satisfactorily with fop-0.20.3 from the command line, but not from WITHIN xmlspy. A few details: + I'm using the evaluation version of xmlspy, + I'm in touch with Altova's support people; they are trying to help, but as yet nothing resolved, + I'm a tech writer (novice in XML and no Java knowledge whatsoever) I suspect the root of the problem is my unfamiliarity with XML; however, your suggestions could be very helpful just now Thank you for your time Malcolm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Print Option
Of course if the PCL or PS renderers met your needs then the solution could be trivial. For example under AIX (IBM Unix) I do something like: proc = Runtime.getRuntime().exec(lp -d + print_queue + -o -dp -); out = proc.getOutputStream(); And give the OutputStream (out) to the PCLRenderer and it happily sends the PCL to the AIX print queue. I have also done something similar under Windows, but admittedly have not done this in a long time, so I do not recall the syntax off hand. IIRC it was as simple as opening a FileOutputStream to a network printer URL (or something like that). Of course if you need fancy things like SVG or user fonts then the PCLRenderer may not work for you (PS may do more, but I have not tried it). FWIW, I suspect that PCL or PS would be MUCH faster printing than AWT. Art -Original Message- From: Jim Urban [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 5:13 PM To: [EMAIL PROTECTED] Subject: RE: FOP Print Option That is what I thought, but I was hoping there may have been some progress made in this area. :) Jim -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 3:34 PM To: [EMAIL PROTECTED] Subject: Re: FOP Print Option At 03:53 PM 3/8/02, you wrote: I need to use the FOP print option (-print) to print a FO directly to a printer. The problem is, I need to tell FOP which printer (by name, port or UNC name) to print to. Displaying the preview window (-awt) or printer dialog is not an option. I will be embedding this code in an application which will run unattended. The application will wake up, check for FOs to print and print them automatically without any user intervention and then go back to sleep. The print out must go to a specified printer containing a special paper which will most likely NOT be the default printer. Any ideas how to do this? This was answered previously, please check the archives. The short answer is that you cannot in any straightforward fashion programmatically assign a printjob to a specific printer pre-Java 1.4. There new JavaPrintService facility in 1.4 is promising, but I think you might have trouble trying to run fop in 1.4 yet. If someone wishes to refine this answer, please jump in; Alex -- another topic for the faq? ' 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: java.util.HashMap to com.sun.java.util.collections.HashMap
Prior versions of FOP used to support JDK 1.1 (with reduced functionality). However some time back, JDK 1.1 support was dropped. I have not looked at this in a while, but I suspect that HashMap may be the least of the problems. I suspect that supporting JDK 1.1 with the current FOP would require dropping image and SVG support as well as significant coding changes. FOP has come a long way since the last version that supported JDK 1.1, so it would probably make a lot more sense to apply your efforts to getting a JDK 1.2+ environment for your COM DLL. But if you are doing with FOP does not require the latest and greatest FOP. There should be an old version of FOP around somewhere. I think (but am not sure) that 0.19.1 may have been the last (or one of the last) versions to support JDK 1.1. May require a rebuild. The build script had an option to build for JDK 1.1 (IIRC it was package_jdk11 or something like that). Art -Original Message- From: David B. Bitton [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 11:43 AM To: fop-dev Subject: java.util.HashMap to com.sun.java.util.collections.HashMap Has it come up where anyone has attempted to use FOP w/ JDK 1.1. The is no HashMap class. Sun has made available the collections classes for use in 1.1. This requires changing every import of java.util.HashMap to com.sun.java.util.collections.HashMap. I plan on doing this on my copy of the codebase, because I am rolling FOP up into a COM DLL for use from an ASP page, and J++ (the only way to build a COM DLL, as far as I know) uses 1.1. Any thoughts? -- David B. Bitton [EMAIL PROTECTED] www.codenoevil.com Diversa ab illis virtute valemus. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Adobe Acrobat Reader 4.0 vs. 5.0
Is Web Browser Integration checked under the General Preferences? -Original Message- From: Lewis, Bobby [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 05, 2002 2:09 PM To: Fop-Dev (E-mail) Subject: Adobe Acrobat Reader 4.0 vs. 5.0 We have an odd problem. When we go to a JSP that generates the PDF, on a machine with Acrobat Reader v.5.0 installed, everything works fine (the plugin is activated and the PDF shows up in the browser). If we go to the same page on a machine with Acrobat Reader v.4.0 installed, we get a Save as popup box for the JSP page. Anyone else have this problem? Does 4.0 not have a browser plug-in? I thought it did. Bobby Lewis Solutions Architect Aivia 3100 McKinnon Suite 1000 Dallas, TX 75201 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
I will try to commit this sometime in the next few days.
I have not looked at the code yet, should this be the main branch or the
maintenance branch?
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 8:36 PM
To: [EMAIL PROTECTED]
Subject: Re: i18n in TXTRenderer
Hi, Art.
I attach the most simplest changes to this mail.
I created a new org.apache.fop.render.txt.TXTStream class and
modified the TXTRenderer class.
A difference of behavior with an existing code is that a
generated text is written by UTF-8 encoding (not ISO-8859-1).
It maybe more better that users can specify a charset encoding
at anywhere. However I also think that most users will not need
a function more than current TXTRenderer. So I think that this
changes are enough to view the text.
By the way, a generated text is very dirty :)
---
Satoshi Ishigami VIC TOKAI CORPORATION
On Mon, 28 Jan 2002 12:01:54 -0500 , Art Welch wrote:
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would
handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components)
to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
I have added this to fop-0_20_2-maintain. Looks things are a bit different
in the main branch. Without doing a bit of research, I do not see at the
moment how that works. Of course it is possible that at the moment, it does
not work.
Art
-Original Message-
From: Art Welch
Sent: Thursday, January 31, 2002 12:06 PM
To: '[EMAIL PROTECTED]'
Subject: RE: i18n in TXTRenderer
I will try to commit this sometime in the next few days.
I have not looked at the code yet, should this be the main branch or the
maintenance branch?
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, January 30, 2002 8:36 PM
To: [EMAIL PROTECTED]
Subject: Re: i18n in TXTRenderer
Hi, Art.
I attach the most simplest changes to this mail.
I created a new org.apache.fop.render.txt.TXTStream class and
modified the TXTRenderer class.
A difference of behavior with an existing code is that a
generated text is written by UTF-8 encoding (not ISO-8859-1).
It maybe more better that users can specify a charset encoding
at anywhere. However I also think that most users will not need
a function more than current TXTRenderer. So I think that this
changes are enough to view the text.
By the way, a generated text is very dirty :)
---
Satoshi Ishigami VIC TOKAI CORPORATION
On Mon, 28 Jan 2002 12:01:54 -0500 , Art Welch wrote:
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would
handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components)
to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: i18n in TXTRenderer
You are probably correct. The TXTRenderer probably should not use the same
add method as the PCL renderer. Since it should just generate plain text,
there probably is not a reason that it should not be able to support i18n.
As coded however, it may be more aptly named the ASCIIRenderer (or maybe
that should be PC-8).
Without looking at the code, I am not sure how the TXTRenderer would handle
chars instead of bytes. My guess is that some (simple) code changes would
need to be made.
Personally I do not know that the TXTRenderer is useful enough to be worth
spending much effort on. But if the changes are simple and useful to
someone... Certainly it would be good for FOP (and all of its components) to
support i18n.
Art
-Original Message-
From: Satoshi Ishigami [mailto:[EMAIL PROTECTED]]
Sent: Sunday, January 27, 2002 6:35 PM
To: [EMAIL PROTECTED]
Subject: i18n in TXTRenderer
Hi .
I hacked the TXTRenderer for i18n.
Currently the org.apache.fop.render.pcl.PCLStream class is
used as OutputStream in TXTRenderer. The add method in
PCLStream calss is as below:
public void add(String str) {
if (!doOutput)
return;
byte buff[] = new byte[str.length()];
int countr;
int len = str.length();
for (countr = 0; countr len; countr++)
buff[countr] = (byte)str.charAt(countr);
try {
out.write(buff);
} catch (IOException e) {
// e.printStackTrace();
// e.printStackTrace(System.out);
throw new RuntimeException(e.toString());
}
}
I think that this algorithm is wrong for the character 127.
This reason is that the literal length of char is 2 bytes and
the literal length of byte is 1 byte. To avoid this problem,
I think that the following algorithm is better than now.
public void add(String str) {
if (!doOutput) return;
try {
byte buff[] = str.getBytes(UTF-8);
out.write(buff);
} catch (IOException e) {
throw new RuntimeException(e.toString());
}
}
This algorithm may be not good for PCLRenderer because
I don't know whether the PCL printer supports the UTF-8
encoding or not.
However I think that the TXTRenderer could use the
multilingualable encoding because it is possible to include
some languages in a same single fo file.
Therere I consider that the TXTRenderer should not use the
PCLStream and had better use original OutputStream (such as
TXTStream).
Will my thought be wrong?
Best Regards.
---
Satoshi Ishigami VIC TOKAI CORPORATION
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: [VOTE] Re: Who does this stuff? and Christian
Sounds good to me. Art -Original Message- From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] Sent: Wednesday, January 23, 2002 7:22 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Re: Who does this stuff? and Christian We now have 4 +1 votes I believe. I doubt that we'll get any -1's. :-) Unless any of the other committers (who have not voted yet) have any objections, I'll ask Brian B. tomorrow AM to set Christian up as a committer. Sound good? Arved -Original Message- From: Tore Engvig [mailto:[EMAIL PROTECTED]] Sent: January 23, 2002 5:11 PM To: [EMAIL PROTECTED] Subject: RE: [VOTE] Re: Who does this stuff? and Christian I was thinking about this, because after seeing a long stream of contributions from Christian over the past several weeks, it occurred to me that if he is not already a committer, he should probably be one. Maybe I missed it, but I do not recall a vote on this or anything - but maybe it is just my memory failing me. I think we still need two positive committer votes. I've added [VOTE] to the subject for better visibility. :-) +1 Tore Cheers, Jeremias Märki mailto:[EMAIL PROTECTED] OUTLINE AG Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Question or request for extension
Off hand I do not know of a way to have FOP print when it was rendered, but it should certainly be possible to have the FO include this information. For example if you are using Xalan you could call a Java function (via extension) to get the date and time and include that in the input for FOP. HTH, Art -Original Message-From: Dunning, John [mailto:[EMAIL PROTECTED]]Sent: Friday, January 11, 2002 6:23 PMTo: '[EMAIL PROTECTED]'Subject: Question or request for extension Is there a way to get the time a document was rendered and put that in text, e.g., " printed on 11.01.2001 10:16:02 AM " If not, where might a relative java-newbie attempt to add this? Any help always appreciated, John
RE: please help...PCL renderer not formatting properly
This was a known problem. I believe that a fix has been committed to CVS, but I do not think that it has been incorporated into a distribution. There was talk of another distribution (last I heard it was planned for early in the new year). The fix should be in CVS, so if you can build from CVS you should be able to get the tables to work correctly. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Tuesday, January 08, 2002 6:10 AM To: [EMAIL PROTECTED] Subject: please help...PCL renderer not formatting properly Has anyone else had any problems with the PCL renderer not formatting tables and borders correctly? In PDF the render works great, but as soon as i take the same .FO doc and try transform to PCL, it messes up the borders on my tables...any ideas? ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [vote] Merging JFor with FOP
OK, I did this backwards... Does not change my vote, but I just took a look at the jfor site. I saw a couple of phrases that concerned me a bit. These are: jfor uses a simple mapping from XSL-FO to RTF without any layout computations, which means that the conversion is much faster than with FOP, for example (because jfor has much less to do - there's no magic here) and jfor attempts to preserve the structure of the document (a table is a table, a list is a list, etc.), which can cause some loss of presentation information (distances between elements, etc.) My concerns are that if jfor excels at speed at the expense of presentation. 1. Are jfor users going to be happy with jfor integrated with FOP which seems to favor presentation over speed? 2. Would FOP users be happy with the RTF generated if it loses presentation information? Of course hopefully when they are merged the whole will be greater than the sum of the parts. I do not know though. Assuming that the FOP architecture does not change significantly - my experience with the renderers is that they account for something like maybe 5 - 10 percent of the processing time (maybe less, don't have the numbers in front of me right now). Still I think that it is a good idea (especially for FOP users). Inexact presentation should not necessarily invalidate a renderer - after all - I am to blame for the TXTRenderer (talk about loss of presentation information). Just thought that I would mention it. Art -Original Message- From: Art Welch Sent: Thursday, October 18, 2001 4:44 PM To: '[EMAIL PROTECTED]' Subject: RE: [vote] Merging JFor with FOP Sounds like a good idea to me. The more renderers the better. +1 Art -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 18, 2001 8:58 AM To: FOP Cc: Bertrand Delacretaz Subject: [vote] Merging JFor with FOP Hi people, recently, some code was donated to the Apache Cocoon project in order to connect it with JFor (www.jfor.org) which is a FO-RTF processor. It appeared evident to me (and to others, as I discovered later) that jfor and FOP are doing different things but could be an advantage for both jfor developers, jfor users, FOP users and FO visibility in general to join forces. ... - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
PCLRenderer border problem
I have just committed a change to the PCLRenderer that should correct the incorrectly printed borders. Unfortunately because I am stuck with JDK 1.1.8 I can not easily test the changes. I implemented a change to the CVS version that I had done to a modified version that we have been running for a while. I believe that this corrects the problem, but I would appreciate feedback from people using the PCLRenderer if it is actually fixed. Thank You, Art - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Performance and java 1.1
I was not sure if we were actually taking a vote yet... Anyhow my vote is: +1 to change the minimum required JVM version to 1.2. As has been mentioned previously, FOP already does not work with JDK 1.1 anymore (since Batik). I am one of the poor souls stuck with JDK 1.1 (at least until next year anyway). We have been able to make a version of FOP that works under JDK 1.1 using some 0.20 code and some old SVG stuff, but it was a royal pain. (Actually Badri R did most of the work on this for me). But I agree that at this point FOP needs to move ahead. Art (works for EastPoint Technologies - what a joke) -Original Message- From: Karen Lease [mailto:[EMAIL PROTECTED]] Sent: Friday, September 21, 2001 5:19 PM To: [EMAIL PROTECTED] Subject: Re: Performance and java 1.1 Keiron Liddle wrote: Hi All, I have been doing some performance testing so we can get an idea of how things might be improving (or getting worse) with changes to the code. [snip] So the question is: can we drop java 1.1 support and use better data structures? Interesting results! With java 1.4 just around the corner, I think we can and should byte the bullet and stop trying to keep FOP compilable with Java 1.1. I know there are a few loyal Fop users out there whose corporate structures are still several versions behind. It's too bad for them, but FOP _is not_ legacy software and should be able to move quickly. It's also hard for us to keep the code compatible since I suppose almost all of us are developing on at least Java 1.2. So +1 for me. Karen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
FW: cvs commit: xml-fop/src/org/apache/fop/render/xml XMLRenderer.java
Keiron,
I wonder if NULLing _source, _stream, and _reader in Driver.reset() is such
a good idea. For my own use with the PCLRenderer I take advantage of the
stream staying open to concatenate multiple invocations into one output. I
suppose that the desired things could be saved off before calling reset
(since thankfully you do not call close() or anything) and then put them
back after. But this seems like a bit of a nuisance. But maybe I am the only
one that does this. I know that for most of the other renderers it is not
currently possible to concatenate multiple invocations in FOP. Just a
though.
Art
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Monday, September 17, 2001 9:30 AM
To: [EMAIL PROTECTED]
Subject: cvs commit: xml-fop/src/org/apache/fop/render/xml
XMLRenderer.java
keiron 01/09/17 06:29:53
Modified:src/org/apache/fop/apps AWTStarter.java
CommandLineOptions.java Driver.java
src/org/apache/fop/render AbstractRenderer.java
PrintRenderer.java
src/org/apache/fop/render/awt AWTRenderer.java
src/org/apache/fop/render/mif MIFRenderer.java
src/org/apache/fop/render/ps PSRenderer.java
src/org/apache/fop/render/xml XMLRenderer.java
Log:
fixed a few awt render problems and a bit more render refactoring
...
Index: Driver.java
===
RCS file: /home/cvs/xml-fop/src/org/apache/fop/apps/Driver.java,v
retrieving revision 1.34
retrieving revision 1.35
diff -u -r1.34 -r1.35
--- Driver.java 2001/08/22 08:29:17 1.34
+++ Driver.java 2001/09/17 13:29:52 1.35
@@ -1,5 +1,5 @@
/*
- * $Id: Driver.java,v 1.34 2001/08/22 08:29:17 keiron Exp $
+ * $Id: Driver.java,v 1.35 2001/09/17 13:29:52 keiron Exp $
* Copyright (C) 2001 The Apache Software Foundation. All rights
reserved.
* For details on use and redistribution please refer to the
* LICENSE file included with these sources.
@@ -230,6 +230,9 @@
*/
public synchronized void reset() {
_areaTree = null;
+_source = null;
+_stream = null;
+_reader = null;
_treeBuilder.reset();
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 3655] New: - Driver.reset() does not function properly
Ah... I see that this is probably why Keiron added the null'ing to Driver.reset(). I still think that nulling the output stream is not really appropriate - especially since the output stream is not really an internal structure of Driver (IIRC). I think that Driver does not create the output stream. If this is correct then it probably should not null it. Actually I think that this is a bit gray. Certainly it should not close it. But setting it's reference to it to null... mainly I do not like it because it is inconvenient for me and if we wanted to support concatenation in the renderers this could be in the way. Again... just a thought... Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 3655] New: - Driver.reset() does not function properly DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3655 Summary: Driver.reset() does not function properly Product: Fop Version: 0.17 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We use FOP to generate pdf reports. A Driver is instantiated to render the pdf, after which the driver is reset. When the same driver is reused to render another pdf, one document is created containing the first and the new pdf. So both reports are appended. So I presume the reset method does not reinitialize the internal datastructures properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: DO NOT REPLY [Bug 3655] New: - Driver.reset() does not func tion properly
Also if no other action is taken - like creating a new output stream or something - aren't we asking for a NPE? -Original Message- From: Art Welch Sent: Monday, September 17, 2001 12:41 PM To: '[EMAIL PROTECTED]' Subject: RE: DO NOT REPLY [Bug 3655] New: - Driver.reset() does not func tion properly Ah... I see that this is probably why Keiron added the null'ing to Driver.reset(). I still think that nulling the output stream is not really appropriate - especially since the output stream is not really an internal structure of Driver (IIRC). I think that Driver does not create the output stream. If this is correct then it probably should not null it. Actually I think that this is a bit gray. Certainly it should not close it. But setting it's reference to it to null... mainly I do not like it because it is inconvenient for me and if we wanted to support concatenation in the renderers this could be in the way. Again... just a thought... Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Monday, September 17, 2001 11:46 AM To: [EMAIL PROTECTED] Subject: DO NOT REPLY [Bug 3655] New: - Driver.reset() does not function properly DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3655. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3655 Summary: Driver.reset() does not function properly Product: Fop Version: 0.17 Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Normal Priority: Other Component: general AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] We use FOP to generate pdf reports. A Driver is instantiated to render the pdf, after which the driver is reset. When the same driver is reused to render another pdf, one document is created containing the first and the new pdf. So both reports are appended. So I presume the reset method does not reinitialize the internal datastructures properly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PCL Problems on HP Deskjet 400
I think that everything that has been said is correct. However, I think that banding would only come into play for graphic elements. It has been a very long time since I last coded for an old DeskJet (or any DeskJet for that matter - the last ones being the original DeskJet and the DeskJet Plus). IIRC since the DeskJets have a very small buffer, everything needs to be sent to the printer in the order that it will be printed. On a Laser printer generally the whole page is produced in printer memory and then printed. So on a laser printer things can be sent for a page in any order. Perhaps the newer DeskJets are endowed with bigger buffers - and enhanced PCL support. How did the text print? I was concerned that even if the PCL could be made to print properly. The printer would be unable to use the desired fonts. It may be possible to modify the PCLRenderer to create a DeskJetRenderer by using a buffer in the renderer to sort everything on the page into the proper order. Graphic banding could also be done - but this is nontrivial. You may want to take a peek at the TXTRenderer as this uses a buffer to order the output (it also fills as necessary). If it is just an ordering problem. Then perhaps an intermediate renderer could be added that would do the sorting and then call the PCLRenderer (for non-graphic stuff anyway). I do not know if this will be any help. My memory of DeskJet programming is quite foggy. I hope that what I have said is mostly correct. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:45 AM To: [EMAIL PROTECTED] Subject: RE: PCL Problems on HP Deskjet 400 Correct, it is rendered as PCL 5, but it seems almost all of the Deskjets only go up to PCL 3. I have a Deskjet 820 that has a pretty good result from the same document. HP told me that the older printers can't adapt as well as the newer ones to the more complex PCL. -Tony -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 9:21 AM To: [EMAIL PROTECTED] Subject: Re: PCL Problems on HP Deskjet 400 I've had a quick look at the HP website. Your DJ 400 is a PCL 3 printer. Art Welch said the PCL renderer produces PCL5, so this might actually be the real problem. Concerning my comment about banding, unfortunately, I haven't found any information at the HP website. On Thu, 13 Sep 2001 08:44:55 -0400 avespa wrote: Interesting how might I go about testing this? Could I change the renderer and how would I do it? Could I test this by re-arranging PCL code in the document I produce? I render an XML stream into a PCL document, then I send it to the printer in a separate step. How could I 'band' this? -Tony -Original Message- From: Jeremias Maerki To: [EMAIL PROTECTED] Sent: 9/13/01 2:34 AM Subject: Re: PCL Problems on HP Deskjet 400 Hi I don't know much about PCL, but I know this: PCL laser printers usually build a whole page in memory and then print it to paper. They normally have a decent amount of memory. Especially older ink jet printers like yours only have a small buffer, so the page has to be delivered in bands (I think). That's probably what causes your problems. Maybe the PCL renderer would have to be changed so it can output a page as a sequence of bands. To visualize, see here: +-+ | Band 1 | +-+ | Band 2 | +-+ | Band 4 | +-+ | etc.| +-+ | | +-+ I think this is really what messes up your headers and footers. On Wed, 12 Sep 2001 17:32:48 -0400 avespa wrote: Question - I am testing a PCL generated file on an HP DeskJet 400 Printer, circa 1995 with Windows 95. I am seeing rather funky behavior, with the headers and footers being messed up (it looks like a few of the lines were written and then written over - perhaps a page break issue in our XSL)- our XSL is quite heavy and complex, so I am not sure where to start. I am wondering if I need to take the approach of looking at our XSL and seeing where it can be tuned or tweaked to change this behavior, or do I need to go to the PCL itself? I'm wondering if someone could nudge me in a certain direction? The output looks fairly decent on an HP8000 or HP820. I called HP and they weren't much help. Thanks for any help or input, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] Freundliche Grüsse OUTLINE AG Jeremias Märki mailto:[EMAIL PROTECTED] Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029 Internet http://www.outline.ch - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED
RE: PCL Problems on HP Deskjet 400
Another thought... I am not sure if it has been suggested before, but perhaps it may be better (easier) to just have a stylesheet generate plain text and not use FOP at all. We have done this for some of our more simple reports (that do not need to look pretty). This has the added benefit of processing much faster (in our case anyway). You may even be able to add some extension functions to your XSLT processor to enhance the plain text output somewhat. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:21 PM To: [EMAIL PROTECTED] Subject: RE: PCL Problems on HP Deskjet 400 Very interesting and helpful information. My understanding was that the renderer would render the page as it is laid out in the XSL file, and since the header is near the top (with text and graphics) I find it odd that it is rendered and appears at the bottom of the page. The text itself looks like it is in a much smaller font, but the sizes on the page on relative to each other. My main concern now is getting things to appear in the proper order - either with or without an image. If I take out the header portion, things seem to work better. Thanks again for the help, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: PCL Problems on HP Deskjet 400
If you are using Xalan, it would be fairly simple to add an extension function to spit out hard coded PCL3 commands to print a small bitmap (IIRC just RLE of the pixels to print with some escape sequences) when called (could even be more sophisticated and generate the PCL dynamically). Also could do a function to output the PCL escape sequences to change the font/size as desired. Of course changing font spacing could greatly complicate the layout. Remember that without FOP the stylesheet would need to do all the layout (perhaps with assistance from extension functions). For our purposes, the reports we did this with were fairly simple tables. We did an extension function to pad the passed value to a certain width (number of characters) and just stacked the columns in the table. Worked quite well. We did not need anything fancy like font changes or images. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 1:34 PM To: [EMAIL PROTECTED] Subject: RE: PCL Problems on HP Deskjet 400 Hrm...plain text might be ok if we could have a small image and some variable size text - any idea of I could use extensions for this? -Original Message- From: Art Welch [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:58 PM To: '[EMAIL PROTECTED]' Subject: RE: PCL Problems on HP Deskjet 400 Another thought... I am not sure if it has been suggested before, but perhaps it may be better (easier) to just have a stylesheet generate plain text and not use FOP at all. We have done this for some of our more simple reports (that do not need to look pretty). This has the added benefit of processing much faster (in our case anyway). You may even be able to add some extension functions to your XSLT processor to enhance the plain text output somewhat. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 13, 2001 12:21 PM To: [EMAIL PROTECTED] Subject: RE: PCL Problems on HP Deskjet 400 Very interesting and helpful information. My understanding was that the renderer would render the page as it is laid out in the XSL file, and since the header is near the top (with text and graphics) I find it odd that it is rendered and appears at the bottom of the page. The text itself looks like it is in a much smaller font, but the sizes on the page on relative to each other. My main concern now is getting things to appear in the proper order - either with or without an image. If I take out the header portion, things seem to work better. Thanks again for the help, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: FOP Speed
In our application we have found FOP to be a bit slow. In the previous version that had distinct format and render steps, the render phase was very rapid. My preliminary performance analysis indicated that something like 90% of the time was spent handling the properties. I do not know if I would call this low hanging. More like a great big juicy one - way up top. This analysis was also done on a bit older version of the code. We have recently updated some of the code to include Mark's changes, etc. We need to look at the performance again. But at this point I do not think that there are any big gains to be had with minimal effort. I had some ideas about enhancing the property stuff - but I am going to re-analyze performance before I do anything else. Art -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Thursday, September 06, 2001 9:02 AM To: [EMAIL PROTECTED] Subject: FOP Speed Hello, I am rendering a two page document in PDF/PCL using FOP. I notice that the actual loading and render steps of the stylesheet take a rather long time (close to 10 seconds on a large server) I'm wondering if there are any XSL guidelines for FOP, best practicies, things to not do etc, or are there any low hanging fruits per se that I thought look for and fix? -Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Borders not lining up
The View settings should not have any impact on how the PDF is printed. What I was referring to was the Fit to page checkbox on the print dialog. Art -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Wednesday, August 22, 2001 10:00 AM To: [EMAIL PROTECTED] Subject: RE: Borders not lining up Art, I just took a pdf file I used for a test I reported yesterday and 1-by-1 set Acrobat 4.0 (on NT) to ViewActual size, ViewFitWidth, ViewFitVisible and View FitInWindow and printed each. In all cases the printouts were identical, specifically, several tables' on 1 page are all rendered 6-7% undersize compared to running fop -print or fop -awt (and pressing the Print button) At 05:25 PM 8/21/01 -0400, you wrote: I just thought that I would mention that I had problems with Acrobat not printing PDFs in the size that I expected, until I discovered (and turned off) the fit to page option. ' 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]
RE: Borders not lining up
Hi, I just thought that I would mention that I had problems with Acrobat not printing PDFs in the size that I expected, until I discovered (and turned off) the fit to page option. Art -Original Message- From: Ralph LaChance [mailto:[EMAIL PROTECTED]] Sent: Tuesday, August 21, 2001 10:54 AM To: [EMAIL PROTECTED] Subject: Re: Borders not lining up Which renderer are you using i.e., in your command line are you using -awt, -pdf, -print ? I just ran a quick test on 0.20.1 on a test case that renders several 6 inch-wide tables on a single page. In cases, the source is xml, transformed via xslt within fop. The results (apologies to all you metric folks) bot fop -awt (and pressing using the print button) and fop -print both yield a page with all the tables exactly 6 inches wide. running -pdf and printing the resulting pdf file via Acrobat 4.0, the tables are all 5 5/8 inches. These results pretty much agree w/ Steve's results. These results on WinNT. (I regret to say we noticed this a month ago, but since it didn't affect our needs, we didn't report it. tsk tsk) At 02:26 PM 8/21/01 +0100, you wrote: Hi, Firstly, ... am I in the right place for queries of this nature ? (I've tried fop-dev-help fop-dev-info already !) I'm completely new to FOP and just getting to grips with the examples provided, so I'm probably going to sound really dumb. I've been running through the samples provided in the FOP directories and I've noticed that, in the example border.fo, there seem to be a few anomalies: * the measurements do not seem to add up either horizontally or vertically; * in the section which defines the address/Sold To/Ship To etc., once I've established where I think the zero edge is, the left or top edges of the block definitions just don't seem to measure up ! * in the table definitions, the 4 column widths add up to 19cm but physically they only print about 17.9cm ! * the text in some of the columns (of the table) seem to creep over to the left even though end alignment is specified; I've used the white-space-collapse=false option to see if that makes any difference - but that doesn't help; It seems to be affected by the length of the text in an earlier column (Description); padding the shorter descriptions with spaces seems to help a bit, but not totally; and using the monospace font doesn't seem to have made any difference either. So, am I doing something incredibly stupid or this a feature that I have to work around ? Thanks, Steve McCardle - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] ' 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]
RE: PDF serialization
FWIW the PCL renderer should not be keeping much in memory. BTW earlier you had mentioned that the buf option slowed things down. I would expect that pipelining things would improve performance, has this been the case? If so, how much? It seems to me that with the exception of a few details (like ID References, etc) FOP would be an ideal application for pipelining. Keep up the good work, Art -Original Message-From: Mark [mailto:[EMAIL PROTECTED]]Sent: Monday, July 16, 2001 7:26 AMTo: [EMAIL PROTECTED]Cc: [EMAIL PROTECTED]Subject: PDF serializationHi ho fops and fopettes,I have had a look at the memory use of my modified-for-streaming FOP executable and determined that the primary memory constraint is now in the PDF renderer. Basically, because the PDF renderer keeps all objects in memory until the end, this obviously limits the size of the output document. I can't say if other renderers have this issue because I haven't looked.I have had a look at the PDF renderer and I think it should be possible to serialize it with only a minimal amount of data being kept in RAM. However this will require extensive changes to the PDF renderer, because there doesn't seem to be a single point at which I can cleanly introduce the changes. Presumably these changes will be backwards-compatible with the current FOP since I don't want to actually change the code path, just make it so that the results are written earlier.So I was wondering if there was someone I should be speaking with directly about the changes that I want to make, or if I should just barge on ahead and make them, damn the torpedoes pip pip old chap? I would prefer some guidance about this because I don't actually know anything about PDF, but the code is well commented.Obviously my primary interest is in the PDF renderer at this stage, but I'm interested to know if other renderer writers are interested in my work?As an aside: is there a style guide for FOP code? I must say I find the style and layout very confusing and I'm happy to clean things up as I go. At the moment I can't even work out what tab stop size people are using. (In my own work I use 8 character tabs with 2 character indenting).CheersMark
RE: Help in XML Rendering to PostScript
The code looks correct to me. I am just about out of ideas on this. If other applications are able to print to this printer successfully, then this should work. Have you tried the PS renderer yet? The JDK printing API should not come in to play on this. We are sending the print data directly to the printer. I am still a little suspicious that something between FOP and the printer is filtering the stream. As a sanity check I would try connecting the printer locally to see if it works any better. Sorry I could not be more helpful, Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Tuesday, June 26, 2001 3:58 AM To: [EMAIL PROTECTED] Subject: Re: Help in XML Rendering to PostScript I tried setting the PJL ENTER LANGUAGE = PCL and then sending the output to the printer but the printer printed the same old junk characters it was doing earlier Here is my piece of code: -- -- FileOutputStream fos = new FileOutputStream(Melstar\\Melprn); fos.write(\033%-12345X@PJL ENTER LANGUAGE = PCL\r\n.getBytes()); Driver driver = new Driver(); driver.setRenderer(Driver.RENDER_PCL); driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.addPropertyList(org.apache.fop.fo.StandardPropertyListMapping); driver.addPropertyList(org.apache.fop.svg.SVGPropertyListMapping); driver.setOutputStream(fos); driver.buildFOTree(parser, new InputSource(args[0])); driver.format(); driver.render(); fos.write(\033%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT\r\n.getBytes()); fos.close(); I used the jdk 1.4 beta which has much better printing support than it's predecessors and used it's new java printing service API to query my printer. Whichever way I query my printer it always tells me that the supported file format to print is gif, jpeg and png. If I try to set the DocFlavor as POSTSCRIPT or PDF it throws me an exception. I hitting a dead end it seems. Thanks, Hitesh Art Welch wrote: I think that it is probably most likely that something is altering the escape characters in the print stream before the printer gets it. The text renderer of course has no escape characters in it's output. If your printer was PS only then the plain text output would not have printed correctly either (unless something interpreted it for the printer). PCL however will print plain text properly (depending on line feeds and form feeds being appropriate). OK! I just did some more looking on the HP site and it looks like the 6MP should support both PCL and PostScript. If the default is PS and you want to leave the printer that way then you may need to use the PJL commands to switch the language in software (see http://www.hp.com/cposupport/printers/support_doc/bpl01378.html). If you want to try this, after you open the file output stream you would write the enter language PCL command \033%-12345X@PJL ENTER LANGUAGE = PCL\r\n to the output stream before giving the stream to Driver. After Driver has rendered the PCL you could reset the language to PS before closing the stream with \033%-12345X@PJL ENTER LANGUAGE = POSTSCRIPT\r\n. I hope that this solves the problem for you, Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Friday, June 22, 2001 3:56 AM To: [EMAIL PROTECTED] Subject: Re: Help in XML Rendering to PostScript also if I use driver.setRenderer(Driver.RENDER_TXT); and send the output to the printer straight away the printer is able to understand the output and is able to print the text output. But the quality of the output falls far short of what a pdf output can provide. Thanks, Hitesh Hitesh Bagchi wrote: I used the following piece of code to send the pcl output to the printer(HP Laser Jet 6P/6MP network printer): FileOutputStream fos = new FileOutputStream(Melstar\\Melprn); Driver driver = new Driver(); driver.setRenderer(Driver.RENDER_PCL); driver.addElementMapping(org.apache.fop.fo.StandardElementMapping); driver.addElementMapping(org.apache.fop.svg.SVGElementMapping); driver.addPropertyList(org.apache.fop.fo.StandardPropertyListMapping); driver.addPropertyList(org.apache.fop.svg.SVGPropertyListMapping); driver.setOutputStream(fos); driver.buildFOTree(parser, new InputSource(args[0])); driver.format(); driver.render(); And everything went smoothly. Only the printer printed a lot of junk characters like you would get if you write the pcl output to a file and send the file to a printer as a text file. Does it mean my printer do not understand pcl output. Thanks, Hitesh Art Welch wrote: I am not sure if I have the syntax exactly correct (and I do not have FOP installed on my
RE: Help in XML Rendering to PostScript
I thought that I had answered a question about direct printing PCL recently. If you will tell me what platform you are using (Windows/Unix) and how you are invoking FOP (application or command line). I will try to answer this. Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Saturday, June 16, 2001 1:50 AM To: [EMAIL PROTECTED] Subject: Re: Help in XML Rendering to PostScript Hello, Can somebody tell me how to stream PCL output to a network printer without writing to a file. Thanks, Hitesh [EMAIL PROTECTED] wrote: Hello, I am fairly new to FOP and to Java as well. I am wondering if anyone has written a rendering to convert an XML stream to Postscript with FOP (similar to the PCL or PDF renderer) - I am in desperate need of a mechanism to do this. We have a current Java app that converts an XML stream into PDF, but printing through Adobe Acrobat is too resource intensive on the lower end machines. I have tried converting to PCL and then streaming to a port, which works pretty well, but is not a 100% compatibile (PCL beng only HP) If anyone knows of a way to convert an XML to PS format using a custom FOP piece they've written, or knows of a better mechanism, I'd be forever grateful! Thanks very much, Tony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: Printing PDF using FOP...
Actually the output goes to an output stream. Unfortunately sending the output stream is a little platform dependent. On Windows 2000 I just open an OutputStream to the desired printer. Under Unix I exec an lp command and get the output stream for that: proc = Runtime.getRuntime().exec(lp -d + output + -o -dp -); out = proc.getOutputStream(); Similar things can be done at the command line, but I do not remember the syntax off hand. For windows I think that specifying an URL for the printer works. I do not remember exactly how I got the command line to print directly under Unix - maybe specifying stdout for the file name and then piping the output to lp. I do not use the command line much. For my application FOP is invoked by a servlet. HTH, Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Friday, June 15, 2001 7:14 AM To: [EMAIL PROTECTED] Subject: Re: Printing PDF using FOP... I downloaded a fresh set of code from the fop cvs and did find the PCLRenderer and the other latest source code. But as far I could make out PCLRenderer does not print to a printer instead it prints to a file in pcl format. Now in case of pcl as well I do have to send the output to the printer. So my previous problem remains. I am actually not getting how can I send the output to the printer. I think if somebody can provide with a code fragment then it would be of great help. Thanks, Hitesh Art Welch wrote: To use the PCLRenderer you just need to tell the Driver to use the PCLRenderer either by passing the symbolic constant for this or by passing an instance of the PCLRenderer class. For example: fopDriver.setRenderer(Driver.RENDER_PCL); or fopDriver.setRenderer(new PCLRenderer()); If you are invoking FOP from the command line then you can use the -pcl switch to invoke the PCL Renderer. I am not sure what was in the various ZIP files. I would have thought that everything should be in there. Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 8:28 AM To: [EMAIL PROTECTED] Subject: Re: Printing PDF using FOP... I downloaded the 0.18 version of FOP (Fop-0.18.1-DEV-src.zip). In it I did find the PCLRenderer class but found no example explaining how to use it. Also the code I found in the src directory do not contain the org.apache.fop.render.pcl package and all the new packages of 0.18 although the javadocs has them. Did I downloaded the wrong zip file.? Can somebody provide me with a code snippet as to how to use PCLRenderer. Hitesh.. Art Welch wrote: I think that you will want to upgrade to a newer version of FOP. I believe that the PrintCommandLine/AWTRenderer were not functioning in earlier versions. The PCLRenderer is also a fairly recent addition. HTH, Art -Original Message- From: Hitesh Bagchi [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 13, 2001 8:04 AM To: [EMAIL PROTECTED] Subject: Printing PDF using FOP... Hi, I am new to fop and I am not sure whether this is the right place to post this question. Actually what I intend to do is: Write an application which will generate a pdf file using fop and then send it to the printer without user intervention. I am able to generate the pdf file using fop. It works perfectly. But I am struggling for the past few days as to how to print the pdf using fop. I went through the mailing list archives and found some references to AWTRenderer and PCLRenderer but I couldn't work out a solution. Moreover I didn't find the PCLRenderer in fop 0.17. Is it a new addition.? I tried running the PrintCommandLine program in fop but it always gives me an error: using SAX parser org.apache.xerces.parsers.SAXParser using element mapping org.apache.fop.fo.StandardElementMapping using element mapping org.apache.fop.svg.SVGElementMapping using property list mapping org.apache.fop.fo.StandardPropertyListMapping using property list mapping org.apache.fop.svg.SVGPropertyListMapping building formatting object tree WARNING: Unknown formatting object http://www.w3.org/1999/XSL/Transform^stylesheet FATAL ERROR: null Can somebody please help. My query is how to send the generated pdf document to the printer to print with the default options. Thanks, Hitesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED
RE: Printing on legal paper instead of letter
Could it be that the printer or print queue is defaulting to legal paper? If acroread is generating a generic PS file then it may not be specifying a paper tray and just accepting the default. -Original Message- From: Wabei [mailto:[EMAIL PROTECTED]] Sent: Thursday, June 14, 2001 4:11 PM To: [EMAIL PROTECTED] Subject: Printing on legal paper instead of letter Hello listers, I have been trying to figure out this problem and have given up after trying out several things. Problem. I have an xsl stylesheet, where I am specifying my page height, lengths, extents etc, in cm. I create a pdf file from an xml file using fop, and then convert the pdf file into ps using acroread (this is all on a unix platform). When I send this file to the printer it prints on legal instead of letter. I have tried changing my spec to mm, and also changed to inches, and nothing works. This is what I have for my page lenght in the different measurements in the xsl stylesheet. 27.9cm 279mm 11in (for inches) Any direction will be greatly appreciated. Wabei Walusiku __ Do You Yahoo!? Spot the hottest trends in music, movies, and more. http://buzz.yahoo.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
