RE: ok, now it's JIMI time
Robert P. J. Day wrote:
oh, i'm *long* past the point of personal embarrassment here.
although i'm willing to admit that some of my difficulties were
my fault, i think i've also established that there are some definite
deficiencies in the docs for graphics support. where to start?
Sorry Robert, Joerg is right. There may be some deficiencies in the doc, and
I am considering what further changes we should make to clean it up, but the
bottom line is that you are asking us to make it stupid-proof, and I don't
think we can do that.
(first, since i made it clear that i was working with the CVS
tree, to clean that tree requires build.sh clean, not
build clean as you wrote above. a picky detail, but the sort
of thing that has been costing me time and forced me to dig
around when i didn't have to.)
Wrong. If you were running in a Windows environment, it would be
build.bat. Joerg's answer was the correct generic answer. The fact that
you are digging around is your fault. The fact that you blame it on Joerg
should be yet another cause for embarrassment.
next, and as i've already mentioned, there is *nothing* i can see
in the docs that suggest that, if you build in JAI support, JIMI
support is simply dropped. *that* really deserves a prominent
place in the docs.
Duly noted.
next, regarding a build, there's *nothing* that suggests you need
to do a build.sh clean to actually get a new fop.jar. early on,
as part of my tests, i explicitly deleted {fop}/build/fop.jar,
and watched the output from build.sh carefully to confirm that,
yes, the support i wanted was being built in. afterwards, i
verified that a new fop.jar had been created under {fop}/build.
was i really supposed to suspect that the messages being printed
by the build process didn't actually correspond to the new fop.jar
file? this is pretty thoroughly non-intuitive for anyone used to
the make system.
First, please see:
http://xml.apache.org/fop/compiling.html#Troubleshooting
Second, you seem to think that we should know that you are familiar with
make. That would be a documentation failure on your part. Third, you want
Ant to conform its behavior to make. That's not going to happen. You
embarrass yourself to suggest that it should.
but again, according to the online docs, SVG support is handled by
batik, which i definitely have on my CLASSPATH.
PCX files are not SVG, and can't be handled by Batik, therefore
the errors.
Take a closer look at the output.
and once i did a clean, and built with only JIMI support, here's
the output (or at least an excerpt of it):
[INFO] Failed to load JAI, using Jimi instead -- looks good ...
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.pcx)
[INFO] [30]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.pict)
[INFO] [31]
[INFO] [32]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.pnm)
[INFO] [33]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.psd)
[INFO] [34]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.ras)
[INFO] [35]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type
of image (file:xclock.tga)
[INFO] [36]
[ERROR] Error while creating area : Error while loading image
file:xclock.tiff : class java.lang.Exception - Image error
[INFO] [37]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type of image
(file:xclock.xbm)
[INFO] [38]
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type of image
(file:xclock.xpm)
and you can see that a number of formats that are documented as being
supported through JIMI failed to be rendered.
The messages being generated here probably need some work. The normal
approach with open source is to submit a patch.
i'm using, as my guide, http://xml.apache.org/fop/graphics.html, so if
something in that table suggests it's supported by JIMI, i figure i have a
right to be confused if it doesn't work.
Only if you follow the instructions everywhere else. You still have a
problem either in your build or in your runtime environment. I frankly will
not take the time to help you find it.
while i appreciate your assistance thus far, i could really do without
the smug, condescending tone about how i'm
RE: ok, now it's JIMI time
sorry about the length of this, but i have at least a little
honor left to defend ...
On Sun, 11 May 2003, Victor Mote wrote:
Robert P. J. Day wrote:
oh, i'm *long* past the point of personal embarrassment here.
although i'm willing to admit that some of my difficulties were
my fault, i think i've also established that there are some definite
deficiencies in the docs for graphics support. where to start?
Sorry Robert, Joerg is right. There may be some deficiencies in the doc, and
I am considering what further changes we should make to clean it up, but the
bottom line is that you are asking us to make it stupid-proof, and I don't
think we can do that.
i was not suggesting making it stupid-proof, since such a thing is
clearly infeasible. what was becoming frustrating was asking a question
regarding why something didn't work, and told, ah, you have to do X,
when X was not at all clearly spelled out in the docs.
and after i did X, and it still didn't work, i was told, ah, once
you do X, you have to do Y.
(first, since i made it clear that i was working with the CVS
tree, to clean that tree requires build.sh clean, not
build clean as you wrote above. a picky detail, but the sort
of thing that has been costing me time and forced me to dig
around when i didn't have to.)
Wrong. If you were running in a Windows environment, it would be
build.bat. Joerg's answer was the correct generic answer. The fact that
you are digging around is your fault. The fact that you blame it on Joerg
should be yet another cause for embarrassment.
note that i *did* admit right up front that it was a picky detail,
all i noted was that joerg told me to build clean, so i had to
realize that what he really meant was build.sh clean for my
circumstances.
but i'm totally baffled by the accusation that it's my fault
that i'm digging around. this so-called digging around is
nothing more than trying to figure out what it takes to build a
new fop.jar, which as we've established by now is something i
*have* to do.
how is it that you (and joerg) can, on the one hand, be adamant that
i have to build a new fop.jar, then chide me for digging around
when i try to do exactly that?
next, and as i've already mentioned, there is *nothing* i can see
in the docs that suggest that, if you build in JAI support, JIMI
support is simply dropped. *that* really deserves a prominent
place in the docs.
Duly noted.
thank you. now we're making progress which, i should point out,
is a direct result of my digging around.
next, regarding a build, there's *nothing* that suggests you need
to do a build.sh clean to actually get a new fop.jar. early on,
as part of my tests, i explicitly deleted {fop}/build/fop.jar,
and watched the output from build.sh carefully to confirm that,
yes, the support i wanted was being built in. afterwards, i
verified that a new fop.jar had been created under {fop}/build.
was i really supposed to suspect that the messages being printed
by the build process didn't actually correspond to the new fop.jar
file? this is pretty thoroughly non-intuitive for anyone used to
the make system.
First, please see:
http://xml.apache.org/fop/compiling.html#Troubleshooting
Second, you seem to think that we should know that you are familiar with
make. That would be a documentation failure on your part. Third, you want
Ant to conform its behavior to make. That's not going to happen. You
embarrass yourself to suggest that it should.
and i quote from http://xml.apache.org/fop/compiling.html:
The most useful targets are:
...
clean: Cleans the build directory. This is useful for making sure
that any build errors are cleaned up before starting a new
build. ***It should not ordinarily be needed***, but may be
helpful if you are having problems with the build process itself.
[emphasis mine]
now, this is a fascinating description of the clean operation. note
carefully how it first suggests that it is not ordinarily needed, unless
you are having problems. but how does one realize that one is having
problems?
as i described in an earlier post, when i tried to change whether
JIMI or JAI support was built in, the build step ran without error,
the confirmation during that process did indeed confirm the support
i thought i was building in, and a new fop.jar appeared as i expected
in the build directory.
given that all of that happened smoothly and without incident, at what
point exactly was i supposed to suddenly realize that the build had
in fact failed? there was not a single notification, warning or error
that the new fop.jar was, in fact, not what i was expecting.
this has nothing to do with whether the Ant package should emulate
make. it has to do with, when a program runs, confirms everything you
selected and, in the end, produces an executable just as you expected
it would, it's reasonable to expect that that
RE: ok, now it's JIMI time
Robert P. J. Day wrote: Only if you follow the instructions everywhere else. You still have a problem either in your build or in your runtime environment. I frankly will not take the time to help you find it. in the first place, the major problem here is that those instructions are, in some critical cases, misleading or just plain missing. In no material respect is this true, at least after the patches that have already been made to CVS and provided to you through this mailing list. more to the point, as you may recall, one of your earlier pieces of advice was to not run FOP directly, but to invoke it through fop.sh, which turned out to make no difference whatever and was a script you turned out not to fully understand anyway. Well, here is the very first response to your graphics questions: http://marc.theaimsgroup.com/?l=fop-userm=105254830813143w=2 in which I state: So, you can hack fop.sh if you wish, but if you do, then make sure you hack build.xml as well, because otherwise if you try to build FOP from source down the road, you will do so without JIMI or JAI support. Based on the subsequent history, your next response should be Oops. I have already done that. Then we move forward to get it built properly. Instead what we got was: http://marc.theaimsgroup.com/?l=fop-userm=105256848322848w=2 a rant about how cumbersome and awkward it was for FOP to require installation in a specific spot. As for my advice about fop.sh, a standard practice when debugging a problem similar to yours is to isolate the differences between an environment that works and one that doesn't. So I stand by my advice to go back to stuff that we know works until we find the piece that caused the problem. I know fop.sh well enough, but am and should be embarrassed for my misreadings of how the CLASSPATH was being built. In fairness to myself I must point out that if there is nothing wrong with the compile-time environment, then I must look for something in the runtime environment that explains the fact that your system doesn't work when so many others do. The only other parts of your posting that require a response from me: any time you want some help improving the documentation, let me know. i've written a *lot* of documentation and courseware in my time, and i'm pretty good at it. We're glad for any help that you can offer. Just understand that this is *really* cumbersome and awkward is not nearly as helpful as a patch to the code and/or doc that makes it less cumbersome and awkward. but i have no interest in writing anything along the lines of, just do it this way and don't ask questions. FOP user doc is written for a general audience. I don't care whether they just do it this way and don't ask questions or whether they know what they are doing and proceed from there. You cannot be persuaded to join either group. I humbly and sincerely beg forgiveness from this group for my participation in these threads. I regret all of it. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: clarifications about using JAI/JIMI with FOP
As Jörg has already shown: The jars in {fop}/lib are automatically added
to the classpath by the Ant build script (build.xml) and by the
fop.sh/fop.bat scripts. They are not depending on the CLASSPATH env
variable. If you have your own mechanism you have to add the jars to the
classpath yourself.
On 10.05.2003 23:35:53 Robert P. J. Day wrote:
in short, for the clueless like me, what is so magical about copying
those two files under {fop}/lib?
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Duplex Printing
Is there a way of psecifying whether pages are duplex when producing a pdf? Matthew Lancashire IT Project Manager Initial Electronic Security Ltd Tel: +44 1282 473554 Fax: +44 1254 267552 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on wrapping
From: Ben Galbraith [EMAIL PROTECTED] snip/ I can't have the first line be in column 1 and the second line be in column 2 under any circumstances. Folks, how do I do this! Help! I've thought about creating a table-row that's 1pt high and using keep with next on each item's table-row; sound viable? Are there other options I'm not aware of? I dont see how a table-row thats 1pt high will help? Cant you just put each item into its own table-row and set keep-together=always _ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplex Printing
You need different borders for odd and even page numbers? fo:layout-master-set fo:simple-page-master master-name=right [..] margin-left=3.5cm margin-right=1.5cm [..] /fo:simple-page-master fo:simple-page-master master-name=left [..] margin-left=1.5cm margin-right=3.5cm [..] /fo:simple-page-master fo:page-sequence-master master-name=alternating fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=right odd-or-even=odd/ fo:conditional-page-master-reference master-reference=left odd-or-even=even/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set On 12.05.2003 10:22:16 Matthew Lancashire wrote: Is there a way of psecifying whether pages are duplex when producing a pdf? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplex Printing
I don't quite understand what you have said. :) Also I only want certain pairs of pages printed as duplex -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 09:28 To: [EMAIL PROTECTED] Subject: Re: Duplex Printing You need different borders for odd and even page numbers? fo:layout-master-set fo:simple-page-master master-name=right [..] margin-left=3.5cm margin-right=1.5cm [..] /fo:simple-page-master fo:simple-page-master master-name=left [..] margin-left=1.5cm margin-right=3.5cm [..] /fo:simple-page-master fo:page-sequence-master master-name=alternating fo:repeatable-page-master-alternatives fo:conditional-page-master-reference master-reference=right odd-or-even=odd/ fo:conditional-page-master-reference master-reference=left odd-or-even=even/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set On 12.05.2003 10:22:16 Matthew Lancashire wrote: Is there a way of psecifying whether pages are duplex when producing a pdf? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplex Printing
And I obviously don't understand what you're trying to do. Duplex printing can also mean embedding a command to a printer telling him to print on both sides of a sheet, although that doesn't apply to PDF. So, duplex printing can mean several things. So please try again to explain what you need. On 12.05.2003 10:38:33 Matthew Lancashire wrote: I don't quite understand what you have said. :) Also I only want certain pairs of pages printed as duplex Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplex Printing
When someone prints a pdf I have produced using FOP I want certain pages to print on the reverse of the previous page. eg Front of page would show a Contract and the reverse of that page would show Terms and Conditions Page. I only want this to happen on certain pages and when it is printed. As far as the pdf is concerned I am do not want to alter that presentation. Do I have to embed printer commands or something? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 09:41 To: [EMAIL PROTECTED] Subject: Re: Duplex Printing And I obviously don't understand what you're trying to do. Duplex printing can also mean embedding a command to a printer telling him to print on both sides of a sheet, although that doesn't apply to PDF. So, duplex printing can mean several things. So please try again to explain what you need. On 12.05.2003 10:38:33 Matthew Lancashire wrote: I don't quite understand what you have said. :) Also I only want certain pairs of pages printed as duplex Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Duplex Printing
As far as I know you can't do that with basic PDF. The thing you're trying to do would be part of a job ticket, but FOP doesn't support any job ticket functionality. The only way to print a PDF in duplex is to do it manually. Even if you can embedd a job ticket that supports specifying duplex information you still have to make sure that the party finally printing the PDF can interpret the job ticket format. With PostScript this would be simpler at the moment because you would be able to add in duplex commands relatively easily by patching the PostScript file after it is generated by FOP. On 12.05.2003 10:48:57 Matthew Lancashire wrote: When someone prints a pdf I have produced using FOP I want certain pages to print on the reverse of the previous page. eg Front of page would show a Contract and the reverse of that page would show Terms and Conditions Page. I only want this to happen on certain pages and when it is printed. As far as the pdf is concerned I am do not want to alter that presentation. Do I have to embed printer commands or something? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplex Printing
Thanks for your help -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 09:59 To: [EMAIL PROTECTED] Subject: Re: Duplex Printing As far as I know you can't do that with basic PDF. The thing you're trying to do would be part of a job ticket, but FOP doesn't support any job ticket functionality. The only way to print a PDF in duplex is to do it manually. Even if you can embedd a job ticket that supports specifying duplex information you still have to make sure that the party finally printing the PDF can interpret the job ticket format. With PostScript this would be simpler at the moment because you would be able to add in duplex commands relatively easily by patching the PostScript file after it is generated by FOP. On 12.05.2003 10:48:57 Matthew Lancashire wrote: When someone prints a pdf I have produced using FOP I want certain pages to print on the reverse of the previous page. eg Front of page would show a Contract and the reverse of that page would show Terms and Conditions Page. I only want this to happen on certain pages and when it is printed. As far as the pdf is concerned I am do not want to alter that presentation. Do I have to embed printer commands or something? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: fo-pdf header content and alternative headers
Steve Guo wrote: 1. Maybe a dumb question Since the content of the header is specified by, fo:static-content element does it mean the content cannot be 'dynamic'?, such as pulling from the chapter_title element? If it cannot be 'dynamic', then I guess it has to be hard-coded? I got into XSL-FO with "XSL-FO", Dave Pawson, O'Reilly, ISBN 0-596-00355-2 and his explanation of fo:static-content clarifies this nicely, including the fact that it is the layout that is static, not the content. See his section on running headers, beginning on page 152. However, this was what gave me the problem I posted recently against 0.20.5rc, where J. Pietschmann pointed me to the fix in later versions. John Marshall Accurate SoftwareThe Courtyard, Denmark Street, Wokingham, Berkshire, RG40 2AZ, UK.Tel: +44 (0)118 977 3889Fax: +44 (0)118 977 1260http://www.accuratesoftware.com The UK office of Accurate Software will be moving offices from May 19th to the following new location: 80 Peach Street, Wokingham, Berkshire, RG40 1XH. The existing telephone and fax numbers will remain unchanged. Accurate Software [EMAIL PROTECTED] www.accuratesoftware.com Europe . North America . Australasia . Africa The information in this email is confidential and privileged and is intended only for the use of the individual or entity listed above. If you are neither the intended individual, or entity listed above, nor the person responsible for the delivery of this email to the intended recipients, you are hereby notified that any unauthorised distribution, copying or use of this email is prohibited. If you have received this email in error, please notify the Accurate system manager at [EMAIL PROTECTED] or on +44 (0)118 977 3889. The views expressed in this communication may not necessarily be the views held by the Accurate Group.
RE: ok, now it's JIMI time
I have just spent half an hour reading how three guys gave up their Sunday for free to be bombarded with self-righteous abuse. In a new environment for me, I have posted two questions to this list. In the first case my syntax error was politely pointed out and in the second I was politely pointed towards the bugs list. The short time between complaints in this thread shows that not much research was done on the responses. As I understand this list, the sequence should be (1) try to understand and solve your problem (2) ask for help when you get stuck (3) make useful contributions to help others like yourself. I do not know what JAI or JIMI are, or whether they will ever concern me, but if the new one works, then complaining about the old one is a waste of everybody's time and sheer bad manners. John Marshall Accurate Software The Courtyard, Denmark Street, Wokingham, Berkshire, RG40 2AZ, UK. Tel: +44 (0)118 977 3889 Fax: +44 (0)118 977 1260 http://www.accuratesoftware.com http://www.accuratesoftware.com The UK office of Accurate Software will be moving offices from May 19th to the following new location: 80 Peach Street, Wokingham, Berkshire, RG40 1XH. The existing telephone and fax numbers will remain unchanged. Accurate Software [EMAIL PROTECTED] www.accuratesoftware.com Europe . North America . Australasia . Africa The information in this email is confidential and privileged and is intended only for the use of the individual or entity listed above. If you are neither the intended individual, or entity listed above, nor the person responsible for the delivery of this email to the intended recipients, you are hereby notified that any unauthorised distribution, copying or use of this email is prohibited. If you have received this email in error, please notify the Accurate system manager at [EMAIL PROTECTED] or on +44 (0)118 977 3889. The views expressed in this communication may not necessarily be the views held by the Accurate Group. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Duplex Printing
I dont know whether I am making any sense here If we are talking about printing from client (in web or otherwise), it is better for the user to do the duplex stuff... since not all printers support the duplex mode. and u as a developer has no idea what the user has access to... Here we do printing mode manipulations and all only when we are doing server side printing (For eg: Printing Airline tickets). In all other cases it is better to give the user the choice - printer dialog. :-) Matthew LancashireTo: [EMAIL PROTECTED] [EMAIL PROTECTED]cc: es.uk.com Subject: RE: Duplex Printing 05/12/03 02:18 PM Please respond to fop-user When someone prints a pdf I have produced using FOP I want certain pages to print on the reverse of the previous page. eg Front of page would show a Contract and the reverse of that page would show Terms and Conditions Page. I only want this to happen on certain pages and when it is printed. As far as the pdf is concerned I am do not want to alter that presentation. Do I have to embed printer commands or something? -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 09:41 To: [EMAIL PROTECTED] Subject: Re: Duplex Printing And I obviously don't understand what you're trying to do. Duplex printing can also mean embedding a command to a printer telling him to print on both sides of a sheet, although that doesn't apply to PDF. So, duplex printing can mean several things. So please try again to explain what you need. On 12.05.2003 10:38:33 Matthew Lancashire wrote: I don't quite understand what you have said. :) Also I only want certain pairs of pages printed as duplex Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANN] First release of Krysalis Barcode (version 0.9)
Krysalis Barcode released = The Krysalis Team is proud to announce the first release the Krysalis Barcode (0.9) which is a barcode generation package written in Java. About Krysalis Barcode == Krysalis Barcode is a barcode generation package written in Java and available under The Krysalis Patchy Software License (which is based on the Apache Software License Version 1.1). Krysalis Barcode currently supports the following barcode symbologies: - Interleaved 2 of 5 - Code 39 - Codabar - Code 128 - EAN-8 and EAN-13 (with supplementals) - UPC-E and UPC-A (with supplementals) Krysalis Barcode currently generates SVG barcodes only but the package is designed to be easily extended, for example to provide additional output formats such as EPS, bitmaps or AWT. The package also contains a barcode generator servlet (and a demo web application) as well as an extension for Apache Xalan to generate SVG barcodes for use in XSL-FO documents (tested with Apache FOP). For more information about Krysalis Barcode, please visit: http://www.krysalis.org/barcode Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: ok, now it's JIMI time
On Mon, 12 May 2003, John Marshall wrote: I do not know what JAI or JIMI are, or whether they will ever concern me, but if the new one works, then complaining about the old one is a waste of everybody's time and sheer bad manners. i apologize for your having had to wade through that, but to address that issue: * JIMI and JAI are two different image libraries you can download from Sun that allow you to embed graphics images in various formats into your PDF document (that is, images whose formats are not already natively supported by FOP). so if you get around to working with graphical images, i suspect you'll need one of them sooner or later. see www.apache.org/fop/graphics.html for more details. * it is not strictly true that if the new one works, it's not worth complaining about the old one. as has been explained to me, if FOP is built with JAI support, JIMI support will not be invoked even if it's necessary for rendering a particular format that JAI does not handle. which seems to suggest that you have to choose between one or the other, as you can't have both at the same time, that's all. i'm hoping that explanation is reasonably accurate. again, sorry for the earlier bandwidth. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
testing support for various graphics formats
in order to clarify which graphics formats are supported under what circumstances, i invoked (under red hat linux) a small xclock client, and used import to take a snapshot of that window and save it in every format supported by that command that seemed to be relevant. the results of embedding all of those formats depending on compiled support: neither JIMI nor JAI: BMP, GIF, JPG JIMI only: BMP, GIF, JPG, PNG JAI only: BMP, GIF, JPG, PNG, TIFF observations: 1) since GIF and JPG are supported natively, it's not surprising that they render no matter what. it's more surprising that BMP renders in the first case, since it's listed as requiring either JIMI or JAI support. curious. 2) a number of formats that claim to be supported via JIMI (e.g., PCX, PICT, etc.) are not rendered, although the online docs do admit that the listed support is only theoretical. still, it's not clear why some should work and others not, given that their listed support is identical. in all those cases, the error message printed during the processing was of the form: [ERROR] Could not load external SVG: Content is not allowed in prolog. [ERROR] Error while creating area : No ImageReader for this type of image (file:xclock.xbm) it's not clear what trying to load an external SVG has to do with these other formats. 3) EPS doesn't render, although the table does state that this native support is still limited for PDF output. (also, there is a CUR format listed in the table of type unknown, but on my host, the resulting file appears to be identical to an EPS file. at least, it's the same size and the file command describes them identically. are these really the same formats under different names? again, just curious.) rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Support for various graphics formats
I tried a jpeg then saved as a gif.
Jpeg worked, gif did not.(could not find XObject Im2)
It is there (honest)
Any ideas. What are the limitations/rules for image rendering?
fo:block text-align=end
fo:external-graphic
src=url('http://ntsysdev/sop/reports/001/images/cw3.gif')
content-height=100%
content-width=100%/
/fo:block
-Original Message-
From: Robert P. J. Day [mailto:[EMAIL PROTECTED]
Sent: 12 May 2003 12:15
To: FOP users list
Subject: testing support for various graphics formats
in order to clarify which graphics formats are supported under what
circumstances, i invoked (under red hat linux) a small xclock client,
and used import to take a snapshot of that window and save it in
every format supported by that command that seemed to be relevant.
the results of embedding all of those formats depending on compiled
support:
neither JIMI nor JAI:
BMP, GIF, JPG
JIMI only:
BMP, GIF, JPG, PNG
JAI only:
BMP, GIF, JPG, PNG, TIFF
observations:
1) since GIF and JPG are supported natively, it's not surprising that
they render no matter what. it's more surprising that BMP renders
in the first case, since it's listed as requiring either JIMI or JAI
support. curious.
2) a number of formats that claim to be supported via JIMI (e.g., PCX,
PICT, etc.) are not rendered, although the online docs do admit that
the listed support is only theoretical. still, it's not clear why
some should work and others not, given that their listed support is
identical.
in all those cases, the error message printed during the processing
was of the form:
[ERROR] Could not load external SVG: Content is not allowed in prolog.
[ERROR] Error while creating area : No ImageReader for this type of
image (file:xclock.xbm)
it's not clear what trying to load an external SVG has to do
with these other formats.
3) EPS doesn't render, although the table does state that this
native support is still limited for PDF output.
(also, there is a CUR format listed in the table of type
unknown, but on my host, the resulting file appears to be
identical to an EPS file. at least, it's the same size and
the file command describes them identically. are these
really the same formats under different names? again,
just curious.)
rday
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
attachment: cw3.jpgattachment: cw3.gif-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for various graphics formats
On Mon, 12 May 2003, Matthew Lancashire wrote: I tried a jpeg then saved as a gif. Jpeg worked, gif did not.(could not find XObject Im2) It is there (honest) Any ideas. What are the limitations/rules for image rendering? as i mentioned, i created mine using linux's import command and taking a snapshot of a simple X client. running the file command on that GIF file told me it was a GIF image data, version 89a. beyond that, i'm not sure. i notice you're using a URL reference. can you copy that file into the local directory to see if that makes a difference? (grasping at straws here, admittedly.) rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: PostScript
Well, that is pretty much the big picture. Java has an API defined for implementing a PrintService and DocPrintJobs. Java's default PrintServices rely on lpr. I have build a true IPP client that fits into Java's PrintService Architecture. In doing this I would like to support the DocFlavor SERVICE.FORMATTED.PRINTABLE and PAGEABLE. For the interface Printable and Pageable I have to provide a Graphics Object for the user to draw into to format the print document. I tried to use PDFDocumentGraphics, but could not control the number of pages. Also, PDFGraphics2D does not support all drawing functions into PDF. THe SVGGraphics2D object supports way more functions. Also the way I designed, I could control the number of pages generated. I will try the SVG.text suggestion. I have tried the fo:external suggestion, and will try again, cause of an error I have found recently in my code. I will also look back into the PS way of formatting. But this is the big picture, provide a true IPP client using Java's pre-defined print architecture. -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, May 09, 2003 3:28 PM To: [EMAIL PROTECTED] Subject: Re: PostScript On 09.05.2003 18:26:11 Leet, Ethan C wrote: fo:external-graphic src=someimage.png blah blah/ Does it have to be a png ? No. That was just an example. I am creating the SVG with the SVGGraphics2D. Not sure, but why don't you try to render directly with PDF(Document)Graphics2D or PS(Document)Graphics2D? Maybe it would help if you gave us the full context of what you're trying to do. Maybe we can come up with a good suggestion. I am supporting a 2D Graphics print formatter. I wanted to format the graphics into PDF, but the images are not clear or text is jumbled. Can you be more specific? It may help if we knew how this jumbled text looks like. Can you post a small one-page example? So I am trying to render to PS. ...which is likely to be of lesser quality than the PDF way. The SVG document is created in live mememory, I used the instream-foriegn-object, cause I could dump the created SVG into the XSL-FO document I was building. So you actually have other content than bitmap images in that SVG you generate? Somehow I don't get it, yet. If I want to use the fo:external-graphic then I must first dump the SVG to a tmp file so the PSRender will load it, right ?? I can't tell. Let's have the big picture first. Like I said, when I tried this FOP locks up ?? The tmp file is closed. Basically I need a way to provide a Graphics2D object for the Printable of Pageable interfaces for printing, then format this data to some printer language, PDF, PS, PCL. Any ideas or help or advice ?? Some people use PDFDocumentGraphics2D to create PDF. That would make the intermediate step over SVG superfluous. See PDFTranscoder.java for an example. I would try the code from the redesign because it's probably better. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Apply-templates
Again, Elmar, this is not the right mailing list for XSLT-related questions. Please understand. See http://xml.apache.org/fop/resources.html#mailing-lists-xslt-mulberry On 12.05.2003 13:36:23 Elmar.Hurni wrote: I use the Function xsl:apply-templates to Apply a set of Template. Because the calls are dynamic, i built the Node/Nodepaths up as follows: xsl:apply-templates select=layout/page-setup/*[$nodeNr]/ It does not work. The Nodes to be execute are all Template are linked with the Nodes underneath page-setup... xsl:apply-templates select=layout/page-setup/*[3]/ does work! If i generate first a Variable, then i get the following error: - NOT A NODE OR NODESET Is there a Function, with which i can convert a String into a Node/Nodeset? Or Is there another possibility? Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Unexpected FOP behaviour (using fop-0.20.4)
Hi fopper, considering the following code: fo:block-container height=4.23332275mm width=30.0mm top=15.0mm left=30.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=black background-color=red fo:blockHello/fo:block /fo:block-container fo:block-container height=4.23332275mm width=30.0mm top=19.22mm left=40.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=blue background-color=green fo:blockWorld/fo:block /fo:block-container There are two things of which I expected a different representation: 1. If you examine the border of the two block-containers in the resulting PDF document you will realize that the background is actually larger than the border. Is that the proper behaviour?? I need to exactly put a block-container under the other. The result is that the background of one block-container always hides a bit of the border of another container. The only workaround i found is to set the background-color to transparent, which works fine as long as you need no background-color of course. Is my XSL-FO inappropriately, or what's to correct solution to the problem ? 2. As you can see in the PDF document the text is always on the very top of the block-container? What's the best solution to make the text appear in the middle (vertically) of the block-container? Any suggestions will be highly appreciated. Thanks, Markus Schäffler I attached a complete (ready to transform) XSL-FO file which contains the above block-containers and shows the problems. -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!?xml version=1.0 encoding=utf-8? fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master master-name=first page-height=297.0mm page-width=210.0mm fo:region-body region-name=xsl-region-body/ /fo:simple-page-master fo:page-sequence-master master-name=psmA fo:repeatable-page-master-alternatives maximum-repeats=no-limit fo:conditional-page-master-reference master-reference=first page-position=any blank-or-not-blank=any odd-or-even=any/ /fo:repeatable-page-master-alternatives /fo:page-sequence-master /fo:layout-master-set fo:page-sequence master-reference=psmA fo:flow flow-name=xsl-region-body fo:block-container height=4.23332275mm width=30.0mm top=15.0mm left=30.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=black background-color=red fo:blockHello/fo:block /fo:block-container fo:block-container height=4.23332275mm width=30.0mm top=19.22mm left=40.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=blue background-color=green fo:blockWorld/fo:block /fo:block-container /fo:flow /fo:page-sequence /fo:root - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Background image
Hi everybody. I have a very simple question (which has been already answered I presume) : How do i display a background image (my company's logo) in the center of the page, without having it being repeateted through the document (I don't know if I should use the background-repeat property of region-body, and what's the value it should be set to). Thanks for your feedback Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
From: Robert P. J. Day [EMAIL PROTECTED] snip/ the results of embedding all of those formats depending on compiled support: neither JIMI nor JAI: BMP, GIF, JPG JIMI only: BMP, GIF, JPG, PNG JAI only: BMP, GIF, JPG, PNG, TIFF observations: 1) since GIF and JPG are supported natively, it's not surprising that they render no matter what. it's more surprising that BMP renders in the first case, since it's listed as requiring either JIMI or JAI support. curious. 2) a number of formats that claim to be supported via JIMI (e.g., PCX, PICT, etc.) are not rendered, although the online docs do admit that the listed support is only theoretical. still, it's not clear why some should work and others not, given that their listed support is identical. J.Pietschmann explained this to you earlier. See http://marc.theaimsgroup.com/?l=fop-userm=105266547708310w=2 in all those cases, the error message printed during the processing was of the form: [ERROR] Could not load external SVG: Content is not allowed in prolog. [ERROR] Error while creating area : No ImageReader for this type of image (file:xclock.xbm) it's not clear what trying to load an external SVG has to do with these other formats. The way I understood J.Pietschmann's response (and I may be wrong in this), is that GIF and JPG are handled easily, then PNG, TGA, EPS and TIFF actually get passed to Jimi for processing and all other formats are assumed to be SVG. Hence why the SVG processor errors on the other formats. _ Express yourself with cool emoticons http://www.msn.co.uk/messenger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Background image
If it to be shown on the first page only you could define two page-masters and set up your page-sequence-master so it contains 2 conditional-page-master-references The first one would have a condition of page-position=first The second with page-position=rest -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 14:08 To: [EMAIL PROTECTED] Subject: Background image Hi everybody. I have a very simple question (which has been already answered I presume) : How do i display a background image (my company's logo) in the center of the page, without having it being repeateted through the document (I don't know if I should use the background-repeat property of region-body, and what's the value it should be set to). Thanks for your feedback Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Background image
Thanks for your support, but my document consists in a single page. -Message d'origine- De: Matthew Lancashire [mailto:[EMAIL PROTECTED] Date: lundi 12 mai 2003 15:19 À: [EMAIL PROTECTED] Objet: RE: Background image If it to be shown on the first page only you could define two page-masters and set up your page-sequence-master so it contains 2 conditional-page-master-references The first one would have a condition of page-position=first The second with page-position=rest -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 14:08 To: [EMAIL PROTECTED] Subject: Background image Hi everybody. I have a very simple question (which has been already answered I presume) : How do i display a background image (my company's logo) in the center of the page, without having it being repeateted through the document (I don't know if I should use the background-repeat property of region-body, and what's the value it should be set to). Thanks for your feedback Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Background image
I think I see what you mean now. You have a single page document and you want the background image displayed once in the middle. Yes? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 14:19 To: [EMAIL PROTECTED] Subject: RE: Background image Thanks for your support, but my document consists in a single page. -Message d'origine- De: Matthew Lancashire [mailto:[EMAIL PROTECTED] Date: lundi 12 mai 2003 15:19 À: [EMAIL PROTECTED] Objet: RE: Background image If it to be shown on the first page only you could define two page-masters and set up your page-sequence-master so it contains 2 conditional-page-master-references The first one would have a condition of page-position=first The second with page-position=rest -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 12 May 2003 14:08 To: [EMAIL PROTECTED] Subject: Background image Hi everybody. I have a very simple question (which has been already answered I presume) : How do i display a background image (my company's logo) in the center of the page, without having it being repeateted through the document (I don't know if I should use the background-repeat property of region-body, and what's the value it should be set to). Thanks for your feedback Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On Mon, 12 May 2003, Chris Bowditch wrote: From: Robert P. J. Day [EMAIL PROTECTED] in all those cases, the error message printed during the processing was of the form: [ERROR] Could not load external SVG: Content is not allowed in prolog. [ERROR] Error while creating area : No ImageReader for this type of image (file:xclock.xbm) it's not clear what trying to load an external SVG has to do with these other formats. The way I understood J.Pietschmann's response (and I may be wrong in this), is that GIF and JPG are handled easily, then PNG, TGA, EPS and TIFF actually get passed to Jimi for processing and all other formats are assumed to be SVG. Hence why the SVG processor errors on the other formats. (just as an aside, that last post was not meant to be a response to *anything* that came earlier -- i decided the most constructive thing i could do was to just test every format under different circumstances to see what worked and what didn't, and i just summarized my findings.) and you are of course correct -- all those other formats are, as j. pietschmann reported, categorized as SVG. but that suggests that the online docs should say so, and not list them as being supported thru jimi, at least for the time being, until that support is available. SVG: and on the bright side, just so i can prove i can be chipper and upbeat, i tossed a reference to an SVG file into my docbook test document, and it rendered nicely. very colorful batik logo. see? now, that's the manic half of my manic-depressive personality. rday p.s. i just looked more closely and, in contrast to what you wrote above, according to my tests, neither TGA nor TIFF was rendered properly by JIMI, although TIFF *was* rendered properly by JAI. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On 12.05.2003 13:15:06 Robert P. J. Day wrote: in order to clarify which graphics formats are supported under what circumstances, i invoked (under red hat linux) a small xclock client, and used import to take a snapshot of that window and save it in every format supported by that command that seemed to be relevant. the results of embedding all of those formats depending on compiled support: neither JIMI nor JAI: BMP, GIF, JPG JIMI only: BMP, GIF, JPG, PNG JAI only: BMP, GIF, JPG, PNG, TIFF observations: 1) since GIF and JPG are supported natively, it's not surprising that they render no matter what. it's more surprising that BMP renders in the first case, since it's listed as requiring either JIMI or JAI support. curious. Ok, let's go over this. I'm looking at the code: GIF, JPEG, BMP, EPS and SVG are supported without any additional library: - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. - BMP is directly implemented. - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. - SVG is supported through Batik and FOP's own code. TIFF is a special case. TIFF images with JPEG or CCITT content will be rendered to PDF as with plain JPEGs: simple embedding without decompressing. Other TIFF subformats will be handled by JAI. TIFFs don't seem to be handled with JIMI installed (technical: since it is derived from JAIImage). So it seems like TIFF is totally unsupported if JAI is not present. PNG images are supported through either JAI or JIMI whichever is present. 2) a number of formats that claim to be supported via JIMI (e.g., PCX, PICT, etc.) are not rendered, although the online docs do admit that the listed support is only theoretical. still, it's not clear why some should work and others not, given that their listed support is identical. in all those cases, the error message printed during the processing was of the form: [ERROR] Could not load external SVG: Content is not allowed in prolog. [ERROR] Error while creating area : No ImageReader for this type of image (file:xclock.xbm) it's not clear what trying to load an external SVG has to do with these other formats. As Jörg already said, FOP falls back to SVG mode if it cannot identify an image. Since an unsupported image format is not SVG an error like above occurs. That's the reason for the first message. The second message tells something about ImageReaders. For each image format supported by FOP an ImageReader must exist. It's responsible to identify a particular image format and to extract some header information such as resolution and image size. Basically FOP tries through all ImageReaders until it finds a format it recognizes. The last to try is always SVG. So even if JAI or JIMI support additional format, if there's no corresponding ImageReader, the format is not supported. 3) EPS doesn't render, although the table does state that this native support is still limited for PDF output. See above. EPS doesn't show in Acrobat Reader. (also, there is a CUR format listed in the table of type unknown, but on my host, the resulting file appears to be identical to an EPS file. at least, it's the same size and the file command describes them identically. are these really the same formats under different names? again, just curious.) Since ICO (Windows Icon) is supported by Jimi, CUR will most probably be a Windows cursor file. Not an EPS. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
To my explanations, I have to add that they apply to PDF only. Other renderers have different abilities. For example, TIFF's may not work properly in the PostScript renderer since the CCITT embedding has not been implemented. On 12.05.2003 15:36:58 Jeremias Maerki wrote: GIF, JPEG, BMP, EPS and SVG are supported without any additional library: - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. - BMP is directly implemented. - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. - SVG is supported through Batik and FOP's own code. TIFF is a special case. TIFF images with JPEG or CCITT content will be rendered to PDF as with plain JPEGs: simple embedding without decompressing. Other TIFF subformats will be handled by JAI. TIFFs don't seem to be handled with JIMI installed (technical: since it is derived from JAIImage). So it seems like TIFF is totally unsupported if JAI is not present. PNG images are supported through either JAI or JIMI whichever is present. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for various graphics formats
Both your JPEG and GIF image worked fine on my machine without JIMI or
JAI (0.20.5 from CVS). Check if there were any error messages.
On 12.05.2003 13:41:28 Matthew Lancashire wrote:
I tried a jpeg then saved as a gif.
Jpeg worked, gif did not.(could not find XObject Im2)
It is there (honest)
Any ideas. What are the limitations/rules for image rendering?
fo:block text-align=end
fo:external-graphic
src=url('http://ntsysdev/sop/reports/001/images/cw3.gif')
content-height=100%
content-width=100%/
/fo:block
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unexpected FOP behaviour (using fop-0.20.4)
I can reproduce but I'm not in the mood to investigate and I don't think it is proper behaviour. The PostScript renderer doesn't paint the background beyond the border but on the other side doesn't paint the borders correctly. A work-around could be to use a single block-container and use SVG within. On 12.05.2003 14:31:42 m.schaeffler wrote: Hi fopper, considering the following code: fo:block-container height=4.23332275mm width=30.0mm top=15.0mm left=30.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=black background-color=red fo:blockHello/fo:block /fo:block-container fo:block-container height=4.23332275mm width=30.0mm top=19.22mm left=40.0mm position=absolute line-height=12.0pt border-width=0.05mm border-style=solid border-color=blue background-color=green fo:blockWorld/fo:block /fo:block-container There are two things of which I expected a different representation: 1. If you examine the border of the two block-containers in the resulting PDF document you will realize that the background is actually larger than the border. Is that the proper behaviour?? I need to exactly put a block-container under the other. The result is that the background of one block-container always hides a bit of the border of another container. The only workaround i found is to set the background-color to transparent, which works fine as long as you need no background-color of course. Is my XSL-FO inappropriately, or what's to correct solution to the problem ? 2. As you can see in the PDF document the text is always on the very top of the block-container? What's the best solution to make the text appear in the middle (vertically) of the block-container? Any suggestions will be highly appreciated. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Support for various graphics formats
how would I do that (I am a novice at this FOP lark)
-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED]
Sent: 12 May 2003 14:53
To: [EMAIL PROTECTED]
Subject: Re: Support for various graphics formats
Both your JPEG and GIF image worked fine on my machine without JIMI or
JAI (0.20.5 from CVS). Check if there were any error messages.
On 12.05.2003 13:41:28 Matthew Lancashire wrote:
I tried a jpeg then saved as a gif.
Jpeg worked, gif did not.(could not find XObject Im2)
It is there (honest)
Any ideas. What are the limitations/rules for image rendering?
fo:block text-align=end
fo:external-graphic
src=url('http://ntsysdev/sop/reports/001/images/cw3.gif')
content-height=100%
content-width=100%/
/fo:block
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Support for various graphics formats
What? Reading error messages? Run FOP on the command line (best with the -d option) and check if there's an error message somewhere in the output. I suspect FOP didn't find the GIF image. On 12.05.2003 16:10:38 Matthew Lancashire wrote: how would I do that (I am a novice at this FOP lark) -Original Message- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Both your JPEG and GIF image worked fine on my machine without JIMI or JAI (0.20.5 from CVS). Check if there were any error messages. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
ok, this goes a long way to clearing up my confusion ... On Mon, 12 May 2003, Jeremias Maerki wrote: Ok, let's go over this. I'm looking at the code: i'll probably break down one of these days and do the same ... GIF, JPEG, BMP, EPS and SVG are supported without any additional library: welll ... semantically, i'd say that SVG *does* require the additional batik stuff, but that's being pedantic. - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. so far, so good. - BMP is directly implemented. ahhh ... the online docs claim that BMP is supported through JIMI or JAI, not via native support. good, that clears up *that* point. - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. ahhh again. i was viewing the final PDF through xpdf on linux. perhaps that's why i saw nothing in the way of EPS output. i'll test that shortly, and see if xpdf has the same limitation. - SVG is supported through Batik and FOP's own code. yup, been there, done that, got my SVG output. TIFF is a special case. TIFF images with JPEG or CCITT content will be rendered to PDF as with plain JPEGs: simple embedding without decompressing. Other TIFF subformats will be handled by JAI. TIFFs don't seem to be handled with JIMI installed (technical: since it is derived from JAIImage). So it seems like TIFF is totally unsupported if JAI is not present. i think that's definitely worth noting on the graphics page, since TIFF is curerntly listed as supported by *either* JAI or JIMI. PNG images are supported through either JAI or JIMI whichever is present. yup, that's what i saw. As Jörg already said, FOP falls back to SVG mode if it cannot identify an image. Since an unsupported image format is not SVG an error like above occurs. That's the reason for the first message. The second message tells something about ImageReaders. For each image format supported by FOP an ImageReader must exist. It's responsible to identify a particular image format and to extract some header information such as resolution and image size. Basically FOP tries through all ImageReaders until it finds a format it recognizes. The last to try is always SVG. So even if JAI or JIMI support additional format, if there's no corresponding ImageReader, the format is not supported. just to make sure i understand this part, FOP is not responsible for processing the image in its entirety, just for perhaps recognizing the image type and invoking the correct library, right? after all, by saying that FOP supports an image format through JIMI or JAI, i'm assuming that all FOP has to do is call the appropriate routine for processing that image. that means that all that has to be done for FOP is to add the additional ImageReaders. is this even remotely close to accurate? 3) EPS doesn't render, although the table does state that this native support is still limited for PDF output. See above. EPS doesn't show in Acrobat Reader. i'll check to see if this is why nothing shows up in xpdf. thanks. slowly but surely, i'm filling out my little cheat sheet. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On Mon, 12 May 2003, Jeremias Maerki wrote: - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. just another data point in a long list of data points. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
On 12.05.2003 16:06:04 Robert P. J. Day wrote: ok, this goes a long way to clearing up my confusion ... On Mon, 12 May 2003, Jeremias Maerki wrote: Ok, let's go over this. I'm looking at the code: i'll probably break down one of these days and do the same ... GIF, JPEG, BMP, EPS and SVG are supported without any additional library: welll ... semantically, i'd say that SVG *does* require the additional batik stuff, but that's being pedantic. Well, I'm well known to be imprecise from time to time. :-) - GIF is supported through JDK classes. - JPEG is implemented directly because it can be more or less embeded 1:1 in a PDF. so far, so good. - BMP is directly implemented. ahhh ... the online docs claim that BMP is supported through JIMI or JAI, not via native support. good, that clears up *that* point. - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. ahhh again. i was viewing the final PDF through xpdf on linux. perhaps that's why i saw nothing in the way of EPS output. i'll test that shortly, and see if xpdf has the same limitation. Probably. GhostScript/GhostView works because it is a PostScript interpreter and can additionally understand PDF. - SVG is supported through Batik and FOP's own code. yup, been there, done that, got my SVG output. TIFF is a special case. TIFF images with JPEG or CCITT content will be rendered to PDF as with plain JPEGs: simple embedding without decompressing. Other TIFF subformats will be handled by JAI. TIFFs don't seem to be handled with JIMI installed (technical: since it is derived from JAIImage). So it seems like TIFF is totally unsupported if JAI is not present. i think that's definitely worth noting on the graphics page, since TIFF is curerntly listed as supported by *either* JAI or JIMI. PNG images are supported through either JAI or JIMI whichever is present. yup, that's what i saw. As Jörg already said, FOP falls back to SVG mode if it cannot identify an image. Since an unsupported image format is not SVG an error like above occurs. That's the reason for the first message. The second message tells something about ImageReaders. For each image format supported by FOP an ImageReader must exist. It's responsible to identify a particular image format and to extract some header information such as resolution and image size. Basically FOP tries through all ImageReaders until it finds a format it recognizes. The last to try is always SVG. So even if JAI or JIMI support additional format, if there's no corresponding ImageReader, the format is not supported. just to make sure i understand this part, FOP is not responsible for processing the image in its entirety, just for perhaps recognizing the image type and invoking the correct library, right? Right. Although some image formats are implemented directly by FOP (JPEG, for example). Just being pedantic myself now. :-) after all, by saying that FOP supports an image format through JIMI or JAI, i'm assuming that all FOP has to do is call the appropriate routine for processing that image. that means that all that has to be done for FOP is to add the additional ImageReaders. is this even remotely close to accurate? It is. Although I think that the whole image thing could be improved. Actually, it should be possible to do an additional fallback after SVG to using JIMI or JAI directly to identify the image format and to extract header information. But that's something for the redesign. 3) EPS doesn't render, although the table does state that this native support is still limited for PDF output. See above. EPS doesn't show in Acrobat Reader. i'll check to see if this is why nothing shows up in xpdf. thanks. slowly but surely, i'm filling out my little cheat sheet. Jeremias Maerki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: testing support for various graphics formats
FYI ghostscript v8.00++ (and naturally ghostview) doesn't render postscript/eps inside pdf by default, unless you set -dDOPS flag on command line or ghostsview config. Reason for that is a security problem with postscript, which has file access to the client, who is interpreting the postscript file, like other programming languages. This will allow to embed postscript viruses into pdf documents invisible for the user. cu Torsten -Original Message- From: Robert P. J. Day [mailto:[EMAIL PROTECTED] Sent: Montag, 12. Mai 2003 16:12 To: [EMAIL PROTECTED] Subject: Re: testing support for various graphics formats On Mon, 12 May 2003, Jeremias Maerki wrote: - EPS is similar to JPEG. EPS images get embedded 1:1 in the PDF. Acrobat Reader cannot display them (blank output) but looking at the PDF in GhostView or printing it on a PostScript printer shows the EPS content. just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. just another data point in a long list of data points. rday - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Background image
Frederic, FOP now only supports background-image and non of the other related properties (like background-repeat). If you want your logo once on the center of the page, create a page size image with the logo in the middle other space should be white. Use this as your background image. Hope this helps, Harm Diderot Track B.V. [EMAIL PROTECTED] wrote: Hi everybody. I have a very simple question (which has been already answered I presume) : How do i display a background image (my company's logo) in the center of the page, without having it being repeateted through the document (I don't know if I should use the background-repeat property of region-body, and what's the value it should be set to). Thanks for your feedback Frédéric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question on wrapping
I can't have the first line be in column 1 and the second line be in column 2 under any circumstances. I dont see how a table-row thats 1pt high will help? Cant you just put each item into its own table-row and set keep-together=always Hey wow, there's a working keep-together that accomplishes just what I'm asking for? Thanks for the info, mate -- you should have just replied with RTFM. :-) Ben - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Help with JAI, TIFF, and FOP
I am using the fop 0.20.4 binary distribution on Windows.
I have a couple of questions Im hoping that others
can help me with.
1) I am unable to get FOP to invoke JAI to handle a TIFF or
PNG. I have copied the jai_core.jar and jai_codec.jar files to {fop-install-lib}\lib.
Here is my FO:
fo:external-graphic
src="">
When I invoke FOP with the JAI libraries in the path I get
the following error:
[ERROR] Error while creating area : Error creating FopImage
object (file:/C:/image.tiff) : Jimi image library not available
Why would I get the Jimi image library not available if
Im trying to use JAI?
2) I read through the thread on clarifications about
using JAI/JIMI with FOP and it appears that those who successfully used
JAI had to build FOP themselves. Does the binary distribution really support
JAI as described or do I need to actually built FOP myself to support it? Also,
should I be using a different version of FOP?
3) I cannot render a TIFF in a PDF with the JIMI library
If I invoke FOP with the JIMI library in the path I get the
following
[ERROR] Error while creating area : Error while loading
image file:/C:/image.tiff : class java.lang.Exception - Image error
Any thoughts?
Thank you in advance,
Steve
Re: Help with JAI, TIFF, and FOP
Comments inline.
On 12.05.2003 20:02:18 Steve Albin wrote:
I am using the fop 0.20.4 binary distribution on Windows.
I have a couple of questions I'm hoping that others can help me with.
1) I am unable to get FOP to invoke JAI to handle a TIFF or PNG. I have
copied the jai_core.jar and jai_codec.jar files to
{fop-install-lib}\lib.
Here is my FO:
fo:external-graphic
src=url('file:///C:/image.tiff')/
When I invoke FOP with the JAI libraries in the path I get the following
error:
[ERROR] Error while creating area : Error creating FopImage object
(file:/C:/image.tiff) : Jimi image library not available
Why would I get the Jimi image library not available if I'm trying to
use JAI?
This happens when only JIMI support is compiled in and JIMI is not in
the classpath. See 2) for more.
2) I read through the thread on clarifications about using JAI/JIMI
with FOP and it appears that those who successfully used JAI had to
build FOP themselves. Does the binary distribution really support JAI as
described or do I need to actually built FOP myself to support it? Also,
should I be using a different version of FOP?
0.20.4 binary seems to have been compiled without JAI support. But it
contains JIMI support. You have two choices:
1. Use the 0.20.4 source dist and compile yourself.
2. Use 0.20.5rc or 0.20.5rc2 binary dist.
3) I cannot render a TIFF in a PDF with the JIMI library
If I invoke FOP with the JIMI library in the path I get the following
[ERROR] Error while creating area : Error while loading image
file:/C:/image.tiff : class java.lang.Exception - Image error
0.20.4 still contained support for TIFF though JIMI but JIMI being old
software may not support all subformats. I think you're trying to open a
TIFF image to supported by JIMI.
A comment to those who love details: In 0.20.5xxx TIFF support through
JIMI got indirectly disabled by the addition of the TIFFImage class
which derives from JAIImage. This made direct embedding of JPEG and
CCITT subformats in PDF possible but at the same time disabled TIFF when
JIMI is used.
Jeremias Maerki
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: testing support for various graphics formats
Robert P. J. Day wrote: just FYI, linux's xpdf command will not display an EPS image, but it does show up in printed output. This is fairly obvious, as it is well known that xpdf is not a complete PS interpreter. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with JAI, TIFF, and FOP
Jeremias Maerki wrote: 0.20.4 binary seems to have been compiled without JAI support. But it contains JIMI support. You have two choices: 1. Use the 0.20.4 source dist and compile yourself. Contrary to the documentation, JAI support in 0.20.4 requires nontrivial code changes. Simply dropping in the JAI API jar isn't sufficient. J.Pietschmann - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Rendering GIF images to PDF?
Hi, I have been evaluating FOP for the past couple of weeks. Basically, I have a java wrapper program which calls the FOP libraries, which reads in an XSLT style sheet and an XML file with data, then produces PDF for each XML file read in. I have set my program to read in 1000 XML files and produce 1000 PDFs. The sole purpose of this is to get some performance timings on different operating systems/machines. One of the tests I ran consisted of producing PDFs which where 4 pages long, that contained a large table, somet text formatting, some SVG and two GIF images. Comparing this test on the Windows 2000 environment to the Windows XP environment came as a shock. The test on Windows 2000 completed in around 7 minutes, whereas on Windows XP it was closer to 20 minutes. The Windows 2000 machine has a P4 1.8Ghz CPU, 256mb RAM. The Windows XP machine much more powerful, a P4 3 Ghz, 1Gb RAM. This is why these results were disturbing. Does anyone know why GIFs take so long to render under Windows XP? My guess is, as GIF is patented, Windows 2000 seems to easily convert the GIF into another format prior to rendering (maybe using a windows tool). However, in XP, this tool may no longer be present, hence the process maybe follows another path which seems to be more expensive? I don't know, this is just a guess. Also note that under XP, the CPU usage while running this hovers around the 20% mark. I tried converting the GIFs to JPGs and the test completed in 4 minutes under XP (CPU usage was close to 100%), so I am certain the problem lies with GIFs alone. Could anyone please help me out here with some insight? Regards, Ozhan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
