Re: Yellow pages
Wow. This looks very much like black magic -- or a FOP black belt trick :-)
Is there another deeper layer of magic in $x_left, $page_width.. ?
I tried with left=0 top=0 width=210mm height=297mm in the static
content area of the page header. But I guess the origin is the upper left
corner of that area so now I have the right and bottom margins colored yellow
but the top and left margins still white.
In a certain sense my problem is half solved but the page looks even more
strange.
Le 28 janv. 2010 à 15:22, Pascal Sancho a écrit :
Hi,
You can add a fo:block-container in a static region, and place it in
absolute-position:
fo:block-container absolute-position=absolute background-color=yellow
left={$x_left} top={$y_top} width={$page_width}
height={$page_height}
fo:block/
/fo:block-container
Pascal
Jean-François El Fouly a écrit :
Aviation regulation authorities state that certain pages of aircraft manuals
(maintenance, policy, etc.) must be printed on yellow paper.
I need to simulate that in PDF by painting the background of my FOP document
yellow.
I had no problem generating the blank pages with a 5-line iText program
(first page) but for the pages I generate with FOP the best I could do
(until now) is to add the background-color=yellow attribute to
fo:region-body, fo:region-before and fo:region-after. All in all the result
doesn't look that good (second page).
There must be a better/simpler solution.
If anyone could help me or give me a hint I'd be very grateful !
Jean-François El Fouly
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Yellow pages
I tried position=absolute instead but it doesn't help...
Le 28 janv. 2010 à 15:58, Jean-François El Fouly a écrit :
Wow. This looks very much like black magic -- or a FOP black belt trick :-)
Is there another deeper layer of magic in $x_left, $page_width.. ?
I tried with left=0 top=0 width=210mm height=297mm in the static
content area of the page header. But I guess the origin is the upper left
corner of that area so now I have the right and bottom margins colored yellow
but the top and left margins still white.
In a certain sense my problem is half solved but the page looks even more
strange.
Le 28 janv. 2010 à 15:22, Pascal Sancho a écrit :
Hi,
You can add a fo:block-container in a static region, and place it in
absolute-position:
fo:block-container absolute-position=absolute background-color=yellow
left={$x_left} top={$y_top} width={$page_width}
height={$page_height}
fo:block/
/fo:block-container
Pascal
Jean-François El Fouly a écrit :
Aviation regulation authorities state that certain pages of aircraft
manuals (maintenance, policy, etc.) must be printed on yellow paper.
I need to simulate that in PDF by painting the background of my FOP
document yellow.
I had no problem generating the blank pages with a 5-line iText program
(first page) but for the pages I generate with FOP the best I could do
(until now) is to add the background-color=yellow attribute to
fo:region-body, fo:region-before and fo:region-after. All in all the result
doesn't look that good (second page).
There must be a better/simpler solution.
If anyone could help me or give me a hint I'd be very grateful !
Jean-François El Fouly
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Yellow pages
Nice result !
It works that way.
Thanks Pascal and Jeremias for helping once more, I'm even more grateful to
both of you :-)
Jean-François
Le 28 janv. 2010 à 16:07, Jeremias Maerki a écrit :
Just replace absolute-position=absolute with absolute-position=fixed
(and leave the rest).
On 28.01.2010 15:58:10 Jean-François El Fouly wrote:
Wow. This looks very much like black magic -- or a FOP black belt trick :-)
Is there another deeper layer of magic in $x_left, $page_width.. ?
I tried with left=0 top=0 width=210mm height=297mm in the static
content area of the page header. But I guess the origin is the upper left
corner of that area so now I have the right and bottom margins colored
yellow but the top and left margins still white.
In a certain sense my problem is half solved but the page looks even more
strange.
Le 28 janv. 2010 à 15:22, Pascal Sancho a écrit :
Hi,
You can add a fo:block-container in a static region, and place it in
absolute-position:
fo:block-container absolute-position=absolute background-color=yellow
left={$x_left} top={$y_top} width={$page_width}
height={$page_height}
fo:block/
/fo:block-container
Pascal
Jean-François El Fouly a écrit :
Aviation regulation authorities state that certain pages of aircraft
manuals (maintenance, policy, etc.) must be printed on yellow paper.
I need to simulate that in PDF by painting the background of my FOP
document yellow.
I had no problem generating the blank pages with a 5-line iText program
(first page) but for the pages I generate with FOP the best I could do
(until now) is to add the background-color=yellow attribute to
fo:region-body, fo:region-before and fo:region-after. All in all the
result doesn't look that good (second page).
There must be a better/simpler solution.
If anyone could help me or give me a hint I'd be very grateful !
Jean-François El Fouly
Jeremias Maerki
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Yellow pages
You're probably right, I think I understand -- I didn't place the stanza in the
correct region.
I can try it that way, too.
Thanks !
Le 28 janv. 2010 à 16:13, Pascal Sancho a écrit :
If you leave precedence properties to default, the upper-left corner of
the page is within the region-start...
So, the (0,0) coordinates of the page is same as in the static region
that correspond to left margin, not page-header.
Pascal
Jean-François El Fouly a écrit :
Wow. This looks very much like black magic -- or a FOP black belt trick :-)
Is there another deeper layer of magic in $x_left, $page_width.. ?
I tried with left=0 top=0 width=210mm height=297mm in the static
content area of the page header. But I guess the origin is the upper left
corner of that area so now I have the right and bottom margins colored
yellow but the top and left margins still white.
In a certain sense my problem is half solved but the page looks even more
strange.
Le 28 janv. 2010 à 15:22, Pascal Sancho a écrit :
Hi,
You can add a fo:block-container in a static region, and place it in
absolute-position:
fo:block-container absolute-position=absolute background-color=yellow
left={$x_left} top={$y_top} width={$page_width}
height={$page_height}
fo:block/
/fo:block-container
Pascal
Jean-François El Fouly a écrit :
Aviation regulation authorities state that certain pages of aircraft
manuals (maintenance, policy, etc.) must be printed on yellow paper.
I need to simulate that in PDF by painting the background of my FOP
document yellow.
I had no problem generating the blank pages with a 5-line iText program
(first page) but for the pages I generate with FOP the best I could do
(until now) is to add the background-color=yellow attribute to
fo:region-body, fo:region-before and fo:region-after. All in all the
result doesn't look that good (second page).
There must be a better/simpler solution.
If anyone could help me or give me a hint I'd be very grateful !
Jean-François El Fouly
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: java.lang.OutOfMemoryError: PermGen space for FOP PDF generation from XML and XSLFO
The solution is simple, really: increase PermGen space.
In an app context that looks very much like yours (big app, full J2EE
stack, FOP, 250 pages with many images...) we use:
-XX:MaxPermSize=128m
Le 10 sept. 2009 à 14:09, SALPE Nilesh a écrit :
Hello ,
I am using FOP 0.95 in servlet for dynamic PDF generation .
It is of about 160 pages .and uses many images in background and
other things.
I give it XML and XSLT as file input and I write out put in response
using byte array
I get following error
Caused by: javax.faces.FacesException: #
{CatalogueBean.actionExtract}: java.lang.OutOfMemoryError: PermGen
space
Can you help me ?
After profiling I see that PDF generation takes about 8 MB of memory
of perm gen space and do not release it .
Nilesh Salpe
Software Engineer, Tools Development
nilesh_sa...@3dplmsoftware.com
3D PLM Software Solutions Limited
A Joint Venture of Geometric Dassault Systemes
T +91.20.22907074F +91.20.22932760M +9881466101www.
3dplmsoftware.com
image001.jpg
P Please consider the environment before printing this e-mail.
This e-mail communication and any attachments are privileged and
confidential and intended only for the use of the recipients named
above. If you are not the intended recipient, please do not review,
disclose, disseminate, distribute or copy this e-mail and
attachments. If you have received this communication in error,
please notify the sender immediately by email or telephone at
+91-20-2290-6641.
Re: Greek Chars
What kind of font do you use to print them ? Le 8 sept. 09 à 14:54, Reliquiem a écrit : Hello, I’ve got a a little problem with the printing of the alpha and beta characters. I am generating PDF-reports from a webinterface with XML and XSL-FO. On this reports are the Characters “Alpha” and “Beta” from the Greek alphabet. But if I print this form, then the Greek chars turn into # . Why? Thanks for help! - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Greek Chars
Then fo:inline font-family=Symbol#x03B1;/fo:inline (Unicode GREEK SMALL LETTER ALPHA) fo:inline font-family=Symbol#x03B2;/fo:inline (Unicode GREEK SMALL LETTER BETA) should do what you want. HTH... Jean-François - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Newbie question
Le 4 sept. 09 à 03:34, Dola Woolfe a écrit : I'm trying to put together several elements to build a PDF translator. 1. Load a PDF in a foreign language (???) 2. Translate the content (Google Translate) 3. Output the translated PDF (FOP) So I'm guessing step 1 is not part of FOP. Can you perhaps recommend what I can use for 1.? Thanks again! I think you should try iText. You will find an explanation of what you need near the end of iText in Action, the authoritative book by Bruno Lowagie, the guy who designed iText in the first place. And before proceeding in your project you *should* read the caveats in his book: extracting text content from an existing PDF may not be as straightforward as you think - in fact may be almost nonsense in certain situations. A PDF API will get you the text content in the order it was technically generated, which may not be the textual order (the order you read the elements in a book). My own experience in top of this is that it is very difficult to extract text content from non-European or large fonts (the CID-keyed fonts, roughly said, those who have more than WinAnsi or ISO-8859-1 characters). HTH, Jean-François - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Implementing Change bars
We're very interested in this feature ! We've emulated this feature with tables and borders so far but it is a much less-than-perfect solution. So we would be glad to discuss it (in the dev list ?) and are certainly willing to help test it. (Nevertheless, the little time I have to devote to fop-dev must be used to understand/implement table markers, that's why I'm not implementing this feature myself.) Good luck ! Le 14 août 09 à 08:53, Stephan Thesing a écrit : Hello, the company I work for will have the need for having change-bars in documents for easy difference tracking in our DocBook-FOP-PDF toolchain. Has anybody started to integrated support for the 1.1 fo:begin/end-change-bar elements into FOP? If yes, we would offer to help, if no, we would start that integration ourselves. In any case, pointers or advice would be greatly appreciated. Best regards Stephan Thesing -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Implementing Change bars
We're very interested in this feature ! We've emulated this feature with tables and borders so far but it is a much less-than-perfect solution. So we would be glad to discuss it (in the dev list ?) and are certainly willing to help test it. (Nevertheless, the little time I have to devote to fop-dev must be used to understand/implement table markers, that's why I'm not implementing this feature myself.) Good luck ! Le 14 août 09 à 08:53, Stephan Thesing a écrit : Hello, the company I work for will have the need for having change-bars in documents for easy difference tracking in our DocBook-FOP-PDF toolchain. Has anybody started to integrated support for the 1.1 fo:begin/end-change-bar elements into FOP? If yes, we would offer to help, if no, we would start that integration ourselves. In any case, pointers or advice would be greatly appreciated. Best regards Stephan Thesing -- Dr.-Ing. Stephan Thesing Elektrastr. 50 81925 München GERMANY Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Generating metrics
Erwan de FERRIERES a écrit : Hi all, I'm trying to generate font metrics in order to import them in a project. Generating start well, but then I've got some errors. I'm running debian and javai version is 1.6.0_07 Here is the line I type to launch the metric generation : java -cp fop.jar:avalon-framework.jar:commons-logging.jar:commons-io.jar org.apache.fop.fonts.apps.TTFReader FreeMono.ttf -d DEBUG Then the debug tells me : TTF Reader for Apache FOP 0.95 Parsing font... Reading FreeMono.ttf... sfnt version: OpenType 1.0 Reading 18 dir tables dir tables: [loca, post, FFTM, glyf, fpgm, hmtx, GPOS, hhea, prep, GSUB, GDEF, cvt , gasp, name, OS/2, cmap, head, maxp] unit per em: 1000 Number of glyphs in font: 2709 hhea.Ascender: 900 900 hhea.Descender: -300 -300 Number of horizontal metrics: 4 Exception in thread main java.lang.NoClassDefFoundError: org/apache/xmlgraphics/fonts/Glyphs at org.apache.fop.fonts.truetype.TTFFile.initAnsiWidths(TTFFile.java:444) at org.apache.fop.fonts.truetype.TTFFile.readFont(TTFFile.java:493) at org.apache.fop.fonts.apps.TTFReader.loadTTF(TTFReader.java:209) at org.apache.fop.fonts.apps.TTFReader.main(TTFReader.java:164) Caused by: java.lang.ClassNotFoundException: org.apache.xmlgraphics.fonts.Glyphs at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:276) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) ... 4 more I've been trying with other fonts, but got the same error. Thank you for your time and help ! Had the same error and, as I was in a hurry, got back to 0.94 which was somewhere around to generate the font metrics. Worked well. It looks like XML Graphics Commons is now somehow required to run TTF Reader but I'm afraid the online documentation does not state this clearly. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mixing Cyrillic and Roman characters - PDF output
Not sure Base-14 fonts are configured to support the full Unicode set. It looks dangerous to rely on default font settings when you want something special. I tried to specify a font-family (for which my system is properly configured !) and it works. ?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=master margin=1in fo:region-body region-name=main-body/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference=master fo:flow flow-name=main-body fo:block font-family=Verdana Russian spelling of Berkenblit: ÐеÑкенблиÑ. /fo:block /fo:flow /fo:page-sequence /fo:root a.pdf Description: Adobe PDF document - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mixing Cyrillic and Roman characters - PDF output (repost)
Jay Berkenbilt a écrit : I am using a Debian system. I've tested this both with the debian fop packages and by just downloading a binary distribution. I've also installed Type 1 Cyrillic fonts and run fop with the following configuration file: fonts directory/usr/share/fonts/X11/Type1/directory auto-detect/ /fonts but this had no effect. Perhaps I need to do more than that. I think you do. The latest versions of FOP have some font auto-detection functionalities but I used to rely on manual settings font by font as described in the documentation at http://xmlgraphics.apache.org/fop/0.95/fonts.html To build upon my previous answer to your previous post, this is the setting for Verdana that renders correctly with your .fo example : font metrics-url=verdana.xml kerning=yes embed-url=verdana.ttf font-triplet name=Verdana style=normal weight=normal/ /font If you use FOP in CLI and you tweak the FOP conf file don't forget (I did) to add -c fop.xconf or whatever name you used to the command line. HTH, Jean-François - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Issues related to Images printing too dark
Steffanina, Jeff a écrit : Last week there was some discussion of the issue that the images (.jpg, .gif, .png) were printing darker when they were processed through FOP. I deleted the messages and now I need to review them. How do I go about reviewing the ENTIRE old message library?? For instance, here: http://www.nabble.com/FOP---Users-f353.html Full list of archives available here: http://xmlgraphics.apache.org/fop/maillist.html#fop-user
Re: Memory issues
Richard Forrester a écrit : Hello, I have FOP 0.94 and I am running into some issues with Memory. I have a rather large XML file.. 2.5 MB. when I try to create a PDF from this file my memory usage spikes up to 700 MB when it starts converting. However it seems to stay there between 600 and 700 MB almost like it's frozen. I've waited 5 to10 minutes to see if it would finish, but never seems to. Is there something I can do to fix this memory usage issue and make it more manageable? Thank You! Not willing to play Mine is bigger than yours ;-) but the document I'm working on is 3.5 Mb source, 7.5 Mb FO and has 1200 rather large PNG screenshots inside. The whole thing fits easily with a full AS and a rather large management web app in 1 Gb. And all the memory we need is released at the end. So my best guess is: you should try to make your document more manageable for FOP by breaking it in severa fo:page-sequence (chapters, sections, whatever makes sense in your business). Between page-sequences, many resources are released. Anyhow, it helped us make it (we had such problems in the beginning). Jean-François El Fouly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issues
Luis Ferro a écrit : Interesting... And does those sequences share page-citations between them from and to? (like a global index) Yes, definitely. Global TOC, section TOC, chapter TOC, global index, list of revisions, bookmarks... (fo:page-sequence at the chapter level, but the chapter TOC in front is an fo:page-sequence in its own right). It works because they are in the same source document. Thanx for the tip... My workaround the memory limitations was to split the work in several individual documents, completely separated from each others, and managing a starting page reference to keep things continuous. We've been through this too at a certain point in the project, it has been a nightmare, as we just couldn't produce all the above artefacts we needed. It also worked... but at the cost of an harder build process. You solution would improve the build ten-fold! ;) Yes, it's so much easier right now than it has been :-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
XML font descriptors
Is there a documentation somewhere that would explain what's in the .xml font files generated by ttfreader ? I have a problem with some glyphs I've drawn, and understanding the infos in the descriptor could help me find out what's wrong in the TTF I've built. Thanks ! Jean-François El Fouly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: URI resolving for image access
In fact, the trailing slash was missing in the base URL as passed to the FOUserAgent, and believe it or not, it won't work without it :-( - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
URI resolving for image access
Monday morning newbie question #1: I have a document somewhere on my laptop with an FO file and quite a lot of images in the same directory. The images are included with a syntax such as src=0_014_001_SA_00.png thus an URI syntax that is implicitly relative. And OK I know the standard says no way. Yet, if I launch fop command-line, stand-alone, from FOP's own directory, giving on the command line the path of the source document, it works. Now if I upload this document to a Unix server running an application that has FOP embedded, it won't work (at least out-of-the box). So I change the code, init an FOUserAgent and set explicitly the base URL to file://var/static/temp/anything where the document and the images are. And it still does not work. I've seen there are changes in URI resolving in the latest stable version of FOP, since I have a few interesting (similar) test cases around, that work in 0.95 but won't work in a previous version. Can someone explain me what to do to make such a config work ? Thanks in advance, Jean-Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Font path setup in fop.xconf
Monday morning newbie question #2 (second and hopefully last one): I've downloaded to my Windows dev laptop a FOP 0.95 setup that works well on a linux production server. All fonts and their xml files, etc. Of course I need to change the font-base setting. On the linux server, I have base./base font-basehttp://server/some-apache-directory/font-base How do I setup the font-base to a Windows directory ? I had a short (and alas sleepy) look at the documentation sometime early last night and couldn't find the syntax. base./base font-baseD:\java\fop-0.95\conf/font-base font-basefile://D:\java\fop-0.95\conf/font-base don't seem to work. So I guess I miss something with forward and backslashes or escaping or who-knows-what Any idea welcome ! Jean-Francois (falling asleep) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using CHOOSE to control image in region-body
Steffanina, Jeff a écrit : FOP 0.95 / Redhat Linux / Java 1.5 When the tag send-fax does not exist print the lilly, when send-fax=Y, print the pebble. I always get the Lilly. Can you determine why? tag, do you mean an attribute of the current element ? I would write test=@sendfax='Y' I don't think I ever used a syntax like ./ I used ../ or nothing but can't understand what this is meant for (of course this can simply be a syntax I'm not used to). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using CHOOSE to control image in region-body
Steffanina, Jeff a écrit : Located in the XML file: send-faxY/send-fax Recently, in a reasonably similar problem (though a bit more complicated) I used xsl:if test=count(send-fax) = 0 Not very elegant but it did the trick for me, and it might do for you if the only thing you need is test the existence of send-fax. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using CHOOSE to control image in region-body
Jean-François El Fouly a écrit : Steffanina, Jeff a écrit : Located in the XML file: send-faxY/send-fax Recently, in a reasonably similar problem (though a bit more complicated) I used xsl:if test=count(send-fax) = 0 Not very elegant but it did the trick for me, and it might do for you if the only thing you need is test the existence of send-fax. And BTW if send-fax is not a direct child of the node you're processing but a remote descendant, you should write my condition with an axe: xsl:if test=count(//send-fax) = 0 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Font Issue (Helvetica)
Maximilian Gaerber a écrit : Hi, I am trying to produce a pre-press ready PDF document (with embedded fonts). But for some reason Helvetica will not be embedded correctly. The configuration is correct (see below), the document properties of Acrobat Professional 8 (see attached images) show that Helvetica is an embedded font but when I run the preflight, all my text occurrences are marked as not embedded. Unless you have very specific needs such as PDF/A compatibility requirements, you need not, and in fact you should not embed neither Helvetica nor any other Base14 font (Times, Courier, Zapf Dingbats). These are supposed to be available in all environments where you can read PDF (even if this implies a font substitution). Did you have a look at http://xmlgraphics.apache.org/fop/0.95/fonts.html#Base-14+Fonts Have a nice WE, Jean-Francois El Fouly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image not available
Well, As Far As I Understand It...
This *is *required and even so, it works by some kind of side-effect or
implementation tolerance.
If I refer to the XSL FO official documentation at http://www.w3.org/TR/xsl/
what you write in url(...) is an IRI in the sense of RFC3987, and
relative resource names are just not allowed there.
We had this very same problem (well, even a bit harder because the image
files where in an images subdirectory) and we came to the conclusion
that to be on the safe side, you need to build full URL's or fully
qualified path names if you use the file: access method.
Relative URL's or relative path just wouldn't work.
Nicolas a écrit :
Nicolas nicolas.baumann at externe.bnpparibas.com writes:
Hello,
I'm using fop 0.94.
I want to include an image that is only available through the classpath into
the PDF, because the application is launched by java web start. The FO file
contains a relative link to the image image.gif, which is in the
classpath.
It has worked well like that for a while, but now I can't identify what
causes
this message : Image not available: url('image.gif').
Thanks for help.
Hello,
Adding this code solved the problem but that shouldn't be necessary and has
never been necessary until now :
[code]
foUserAgent.setURIResolver(new URIResolver() {
public Source resolve(String href, String base) throws
TransformerException {
return new StreamSource(getClass().getClassLoader
().getResourceAsStream(href));
}
});
[/code]
Thanks for helping.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Error when using XSL with French Characters
There are four kinds of accent current in French (é è ê ë) so you should be more precise. None of them can possibly correspond to CHR(130) neither in UTF-8 nor in ISO-8859-1 On what kind of system/platform/OS are you working ? Mentioning vi makes me guess it should be some kind of Unix but at the same time the encoding used makes this improbable... I guess more information is needed here. Steffanina, Jeff a écrit : Manuel, We create the XML using a version of BASIC. To create this particular character, we send CHR(130) to the XML. When I open the XML in vi, I see the proper FRENCH symbol. */Jeff /* *From:* Manuel Mall [mailto:[EMAIL PROTECTED] *Sent:* Tuesday, September 02, 2008 10:51 PM *To:* 'fop-users@xmlgraphics.apache.org' *Subject:* RE: Error when using XSL with French Characters I am suspicious that although you declare the XML file as being in UTF-8 it actually isn't. How do you produce the XML file? Manuel *From:* Steffanina, Jeff [mailto:[EMAIL PROTECTED] *Sent:* Wednesday, 3 September 2008 10:23 AM *To:* fop-users@xmlgraphics.apache.org *Subject:* Error when using XSL with French Characters My Friends, Fop-0.95 My style sheet has been working perfectly. However, the user submitted some text in French. In the text was a letter e with an accent above it. That character caused the following error: Invalid byte 1 of 1-byte UTF-8 sequence. My .xml looks fine. The e with the accent above it is perfect. First line in my XML: ?xml version=1.0 encoding=UTF-8? Here is the first line of my XSL: ?xml version=1.0 encoding=UTF-8? I am confused over why the UTF-8 for the XML understands the character but the UTF-8 in the XSL does not? I found an article that suggests that the problem would be solved with: ?xml version=1.0 encoding=8859-1? Would this be a viable/recommended solution? Do you have a better idea? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?
Andreas Delmelle a écrit : I've set up a simple test case and, going through the stack trace, I guess it could be a simple bug fix, something like a bad or insufficient test in TablePart.java Oh, rest assured, it's going to take a bit more thought and effort... ;-) Yes, I've seen late in the evening that implementing the context attributes as defined in the W3C recommendation is probably going to be a tough task. I've got a more serious question but I'll ask in another post. Thanks for the moral support ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: I need fo:retrieve-table-marker example or how to implement continued label in FOP-95?
Jeremias Maerki a écrit : Hmm, that's one of the two remaining features that are available in 0.20.5 but not in 0.95. So far, nobody has had enough of an itch to implement this, I'm afraid. Hhmm... I've been quickly through the code and my first impression is that it IS implemented. I've set up a simple test case and, going through the stack trace, I guess it could be a simple bug fix, something like a bad or insufficient test in TablePart.java Will continue my quest tomorrow. I really need to fix this one by now. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to use glyphs from the Symbol font ?
Jeremias Maerki a écrit : No, the mapping is correct. You think in terms of one-byte encodings. XSL-FO and therefore FOP is a Unicode application. If you want the theta character (0x03B8, GREEK SMALL LETTER THETA) you need to put the 0x03B8 character in your XSL-FO file. 0x71 always represents a q for which the Symbol font doesn't have a glyph and therefore renders as #. Now I see it's high time for me to take a break :-( Of course it works, it didn't work because I had been stupid enough (or just too tired) to look at the mappings in the MS Windows Symbol font instead of using The Unicode Standard though it is on my desk. So #xF044; and #xF064; (I was looking for delta's) go nowhere. Now if I dare ask a second question about the other problem in my test sheet... paraPlus petit ou égal (Unicode 2264, LESS-THAN OR EQUAL): #x2264;/para paraPlus grand ou égal (Unicode 2265, GREATER-THAN OR EQUAL): #x2265;/para renders the symbol as #, with the following warnings in the logs: 2008-07-30 10:32:21,155 WARN [org.apache.fop.fonts.SingleByteFont] Glyph 8804 (0x2264, lessequal) not available in font Verdana 2008-07-30 10:32:21,157 WARN [org.apache.fop.fonts.SingleByteFont] Glyph 8805 (0x2265, greaterequal) not available in font Verdana Now the Verdana font that is used on the server has glyphs for the Unicode characters above (checked with TypeTool). And these are the correct character codes (this time I double checked against the book). So what did I miss ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
How to use glyphs from the Symbol font ?
We generate FOP documents from a *nix workhorse, a rather plain (bare) server that has very minimal graphics font equipment. The current setup works well for current fonts (say, Verdana) and custom-made technical fonts. Now, I would like to use some glyphs from the Symbol font but this raises a few interesting questions which I was not able to answer so far: - it is not quite clear from the documentation whether Base14 fonts need to be declared in fop.xconf [unless I did not look at the right place and missed a point, which is obviously quite possible] - the server certainly has no Symbol font of its own, I can provide a TTF but ttfreader will refuse to generate an XML descriptor (Unicode cmap table not present / Unsupported format - aborting.). - do I need to use the ASCII or Unicode codes for the glyphs; is 'alpha' simply a lowercase a or #xF061; ? I thought this would be a simple item in my todo list but it proves to be more difficult than I expected at first sight :-( Any help appreciated ! Jean-Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Font error messages
I searched the archives and did not find an entry for this problem. Please forgive me if I've been blind or stupid and should have found a previous thread on this topic. We have in the logs tons of error messages looking like: 2008-07-22 15:52:45,544 ERROR [org.apache.fop.fo.PropertyList] Ignoring property: font=Verdana (file:/var/data/static/aeroconseil/back/TS/temp/test%20recette%20234587/pub/merged-doc.xml.fo:2607:87: Invalid property value: font=Verdana; property:'font') (It's nothing new, it has always been so since we use FOP, I mean for a few months and since 0.94). This is weird, since the font is not ignored, it is correctly handled and used by FOP, and embedded in the PDF. So these messages look just like noise and fill the log files with information that seems irrelevant. What did I missed, what should I fix or improve to get rid of these messages ? Thanks ! Jean-Francois - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Font error messages
Andreas Delmelle a écrit : The font shorthand requires at least two components: font-size and font-family. So it should be either of the two following variants: font-family=Verdana font=10pt Verdana See: http://www.w3.org/TR/xsl/#font (style, weight, variant, line-height are optional; size and family are required) The reason that you don't see any effect in the output is most likely that the font-family is properly passed to the descendant nodes via inheritance (but I'd have to dive deeper into the related code and some examples to say for sure). Ha ha... So my XML stanza: fo:block font-weight=normal font-size=8 font-family=Verdana font=Verdana is wrong, and the last attribute font=Verdana does nothing and probably causes the error message ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Color Profile not applied
Jeremias Maerki a écrit : The work-around it seems is: - either to convert the PNG from 32bit to 24bit (removing the alpha channel) - or skip generating the alpha channel for PDF output. See ImageRenderedAdapter.setup(PDFDocument) (the line with this.softMask = can be commented and the colors appear as they should). The first work-around is alas not an option for us [I work with Dominique on this question] at least not in the general sense. Of course we could write some image preprocessor before the FOP generation (there is at least one other such process in the app) but the customer will want to keep the alpha channel in the PNG they generate. We output these images in PDF through FOP, thus on a white background, but we also generate the manuals in HTML format on a background that can be switched black or white (for reading in the cockpit or in an hotel room or according to anyone's particular preference). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Color Profile not applied
Jeremias Maerki a écrit : There's no treatment or the image itself, just evaluation of information inside the image being loaded. FOP reacts on the and tries to put the right information inside the PDF. This was not clear in our mind since I had a vague feeling I had seen things like gamma correction while browsing the code very quickly, but this may be somewhere else in a totally different context ? This hint helps us a lot. The key change is in org.apache.fop.render.pdf.ImageRenderedAdapter (in the case of PNG images) where you'd need to override the ColorSpace sent to the PDF library with the device-specific variant. This is second very, very helpful hint. I've been once more through the code of this class; not sure at the moment I grasp everything about the way it works or how it fits in FOP general picture, but at least now I know what to look for and where we should put the effort... Please note: I consider this a hack or a desperate measure if all else fails. Ignoring the color management is a way to fall back to device-specific colors which is known to produce the color fidelity you expect on screen. I'd rather find out if there's a bug in the way FOP handles color profiles. But if I see so many other programs fail at producing the colors you expect I have low hopes. Maybe your PDF gives me a clue. Well, I guess the customer is desperate to a point where a hack will do the job until in the long term someone (you / us / someone else) comes up with a clean solution. So that is not really a problem.
Re: Problem with asian language fonts
Rakesh Kumar S a écrit : Hi, Which is the encoding format that will support both asian language and western fonts? Thanks, Rakesh Kumar S Any Unicode-based encoding will do the job. One of the UTF-16 (Big Endian or Little Endian) is probably your best choice, since UTF-8 is a variable-length encoding that will use 3 bytes or more for Asian characters, while UTF-16 will use 16 bits flat for every character. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Color Profile not applied
Jeremias Maerki a écrit : FOP 0.95beta uses the sRGB color space by default (because XSL-FO defines all RGB colors in the sRGB color space). FOP always embeds an sRGB color profile. So specifying another sRGB color space explicitely doesn't have any effect. Can you elaborate on what you mean by an issue regarding color brilliance? Please also see my previous answers on similar questions: http://markmail.org/message/3tuims2gjbconya5 http://markmail.org/message/qithk3gcoyrane3a Well in fact Dominique and I work together on this question so this was yet another attempt to solve the color saturation issue in aircraft manuals. Since your detailed answer (a couple of months ago) I've learned quite a few things (reading the PDF Reference Manual, among others) so I realize now that there are a couple interesting points in your post which I missed at that time. One of them was a hint that rendering intents could be a solution. Well, FYI, I've tried a patch in PdfImageXObject to add /Intent /Saturation to the image dictionaries and well... it does not seem to change anything in the way Acrobat Reader renders the document. Now I understand also that sRGB is in a certain way part of the FO standard (another point I missed) and that's the reason why it is implemented this way in FOP. But I guess we'll need some kind of local patch, e.g. a rewrite of PNGImageDecoder / Encoder in xmlgraphics-commons, rendering our PNG's in /DeviceRGB, to achieve the result our customer needs. Thanks, any comment or suggestion welcome ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with fop 0.95 in Oracle Java VM
We had this kind of stack trace in 0.94 with a Sun JVM; you should check you have the write permission in the user home directory. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with Fonts
Rakesh Kumar S a écrit : Hi When i add want to render documents with a specific font, i am not able to do it. Instead i get a message : [ERROR] unknown font arial,normal,bold so defaulted font to any [ERROR] unknown font arial,normal,bold so defaulted font to any Please let me know how to fix this Probably because you need to configure (declare) the fonts you use. Did you read the friendly manual, for instance here: http://xmlgraphics.apache.org/fop/0.95/fonts.html ? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Multi and Single Column layout on same page
Laurent Yaish a écrit : Hi Folks, How would I go about creating a layout that uses mutiple columns on half of the page (i.e. using region-body column-count) and a single column on the other half? I need to content to automatically span the columns so a table wouldn't work... any ideas? Is it even possible? Thanks! I think it's impossible, and to quote a more authorized opinion on this very question (Dave Pawson, /XSL-FO,/ O'Reilly, 2002, Appendix A) : quote /Can I create a newspaper-style layout: part of the page with one column, the rest with multiple columns?/ Simply put, no. The present Recommendation focuses on content-driven layout, not layout-driven formatting. The former simply pours the content into predefined areas, the latter dictates where the content should go. It is a known issue that I hope will be addressed in the next version of the Recommendation. Presently, you can fix this by using tables for layout, as in HTML, but don't expect content to wrap from one fake column to another. /quote
Re: Memory issue
Jean-François El Fouly a écrit : So I hired the team member who's competent in profiler usage next week but I must say at the moment I'm still stuck :-( The sysadmins made a tarball from the staging server and copied everything to a similar server that has full profiling instrumentation (with JProfiler). And obviously there the application works and memory usage is quite normal. Completely different behaviour. Very, very strange. I'll try to understand what's happening (well, I badly need to) but it's probably not going to be easy :-(
Memory issue (was: Re: Major issue with image loading in FOP 0.95beta)
Jeremias Maerki a écrit : And my next problem is to find a way to force memory recycling after this long and hefty FOP processing, but until further investigated this is OT ;-) You probably didn't get my hint earlier but with the new image loading framework you should actually get away with lower memory settings. In my tests I have been able to produce PDF with little text and many images with 40MB of VM memory which wasn't possible with 0.94 and earlier. Well, I got the hint, but it seems in contradiction with what I read. So to take the picture from a bit higher: - all XSL-FO transformation + FOP generation now work OK. - this generates 20-30 documents (chapters) for a grand total of about 150 Mb, to be bound together by iText. - source XML is 1.5 Mb - 1011 PNG images for a total of 151 Mb, the largest image is 715 kb. Now the figures: - XML - XSL-FO transformation + FOP generation take 15 minutes on a pretty decent DELL Server (running Debian 4.0) having all the physical RAM possible (staging server for several customers) - JVM has 2000 Mb (which is BTW the grand max on this processor/server/OS/JVM architecture) - only one instance of FOP launched (one document generation) - the second next step in the publication process (opening the 150 Mb with iText to add the bookmarks) fails immediately (at file open) saying it cannot allocate memory If I try to investigate memory usage using Runtime.getRuntime().getFreeMemory() and logging the figures with log4j, these are the figures I get: - before XSLT + FOP: 1900 Mb free/2000 Mb - end of XSLT + FOP: 241 Mb free - set FopFactory instance to null as a desperate hint to the GC that FOP objects could be/should be recycled - I force garbage collection using System.gc()[OK, in an application server this is a brute force approach, but could not see a more clever maneuver ATM] - 350 Mb free/2000 Mb total - Bind all chapters with iText - 250 Mb free - Force another GC - 350 Mb free again (so the binding operation has no effect on the available memory). - the next iText step still fails. Now I don't take runtime.getXXXMemory() for bible word but at least it looks like the Xalan + FOP subsystem hogs 1500 Mb of RAM which I cannot recover. So I hired the team member who's competent in profiler usage next week but I must say at the moment I'm still stuck :-( Of course I've made my homework and read the f...riendly manual before daring to ask. Did I miss any important indication ?
Re: Memory issue
Andreas Delmelle a écrit : Which Java VM are you using? Practically every time someone tells us about memory/GC issues, it appears they are using an implementation other than Sun (IBM, GNU...) Up to now, we still have to find out why precisely non-Sun VMs have difficulties with FOP... Nope. I'll double check but I'm pretty sure it's a genuine Sun JVM 1.5.0_11, or maybe the very minor build after. How large would the resulting FO-files be if you dump them to the filesystem? The XML by itself says very little. From a 1.5MB XML, you could get a FO of a few KB or one of 26MB, depending on the stylesheet. 5.08 Mb. Does the stylesheet adhere to XSLT best practices? Does it generate a lot of redundant fo:blocks, fo:inlines? I hope not. It has been a complicated thing generated by StyleVision in the very beginning but it has been simplified and tweaked a lot. A nit, for the record: There is no such thing as 'forcing garbage collection'. The most you can do with System.gc() is indicate to the VM that it should run the GC as soon as possible. Admitted, most implementations do run the algorithm virtually immediately upon execution of the statement, but the Java spec does not mandate such behavior. In theory, if the VM is too busy, it could still postpone the actual GC-run, until it acquires the necessary resources... Indeed, but the log4j log has timestamps and they show that 20 seconds are spent around System.gc() so my guess is that something really happens at that time. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory issue
Andreas Delmelle a écrit : OK. Just curious: Any chance you could test it on another build or maybe even Java 6? Probably, if required or useful. Our sys admins are very cooperative ;-) In my personal experience, optimizing the stylesheet code usually does not offer much improvement in terms of global memory usage, but it could have a noticeable impact on the processing time. One of the things I've learned about generated XSL-FO stylesheets by Altova is that they add a lot of fo:inlines to specify, for example, font-properties on the lowest levels in the generated FO while, when comparing to the font-properties of the fo:inlines' parents nothing really changes, except for the size, style or weight. From FOP's point of view, that's somewhat of a waste. Much better to specify a global font-size on the page-sequence, and override on the lower levels only what is really necessary. After adapting the stylesheet manually, and removing the redundant fo:inlines, the stylesheet and the generated FO were reduced to not even half the original size. Yes. That is exactly what happened to the stylesheet we use. I've reduced it drastically. One issue with stylesheets generated by StyleVision is that you must be careful when you tweak them to avoid certain [fo-block inside fo:inline] combinations that make FOP crash with a stack trace and no really useful information about what's happening or where. This bug is mentioned in the FOP bug tracker, though in a rather raw, loose manner. I removed all such constructs and that made the XSLT much simpler and cleaner. Something else that bothered me, but I don't know if that was also generated by Altova, is that in one of the stylesheets I saw, the entire transformation was contained in one giant template... With the last version, or our XSLT ? this was no longer the case. AFAIU, this gives little opportunity for the XSLT processor to clean up anything. Java 1.5 uses Xalan XSLTC by default, which converts templates into Java objects. One giant template would then mean one very long-living object that may reference numerous others for the whole duration of the processing run. If you look at the chain, when using XML+XSLT input, FOP is always the first one to finish, then the XSLT processor, then the XML parser. If the XSLT processor cannot reclaim anything, this will give FOP less room to work with, so it ultimately runs slower. As the heap increases to reach the maximum, the points where the JVM will launch the GC by itself, will also increase. Since it cannot expand the heap anymore, it will try to clean up more frequently. Yep, that is why I've tried to be cautious not to accuse FOP publicly ;-) The problem is in the (Xalan + FOP) subsystem and the profiling could well show that the issue is Xalan-related. BTW, we've made the Xalan-FOP coupling a parameter so that we can use tight coupling (with Sax events) or loose coupling (writing the intermediate FO files on disk). We usually use the second option, since the possibility to read the FO intermediate code is helpful when you debug. And I guess without being really sure that not to have Xalan and FOP working at the same time should use less memory. This separation probably accounts for the long execution time, but that is not an issue since document generation does not occur often in the target system (you can generate chapters for proofreading but you generate the whole document once-twice a day). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
Jeremias Maerki a écrit : I've just re-read that and it suddenly made me think: could it be that you produce really large FO documents (not many smaller ones) with many images and the effect here is simply the timeout of the HTTP connection because it is kept open after preloading the image? I'll add a system property to the image loader framework so you can disable the stream reusage. That could work around the problem. For a longer-term solution I see two possibilities: 1. Add a hint to fo:external-graphic that a URL is dynamic and that the stream should be reused. Otherwise, it is closed immediately and reopened when the full image is read. That idea is not new but never got realized. 2. Add some intelligence to the stream cache so it closes the stream if it is not rerequested within a given time frame to avoid timeouts. In fact we produce a very large document but it used to make FOP explode (OutOfMemoryError) just to generate one section. So we generate each chapter separately and bind them using iText. Basically that is why we need 0.95beta to use the named destinations, otherwise we can't add bookmarks at the end. So the problem occurs generating just one chapter. Here are the figures: - That chapter has 174 images, 84 unique PNG's for a total of 14 Mb. The smallest image is 2 kb, the largest is 395 kb. The whole chapter generated with FOP 0.94 is 69 pages, for a PDF that weighs 14.8 Mb. The whole document is about 900 pages and currently weighs about 150 Mb. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
I'll dive but just to answer the simplest questions: Jeremias Maerki a écrit : Without being able to reproduce the behaviour it is difficult to help. Some further questions from my side: - How many different PNGs are being accessed? 84 - Are they smaller or bigger files? 2 kb to 395 kb. - Are you running FOP in a multi-threaded fashion? Or from many different machines against the SVN repository? No, the problem is fully reproductible with one instance of FOP (running in JBoss which is a multithreaded server but FOP is given one thread only, basically the document is generated as a response from a HTTP request). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[SOLVED] Re: Major issue with image loading in FOP 0.95beta
Jeremias Maerki a écrit : I've done that now: http://svn.apache.org/viewvc?rev=653704view=rev Jean-Fraçois, please download XG Commons Trunk, build it and switch to it. Then set -Dorg.apache.xmlgraphics.image.loader.impl.AbstractImageSessionContext.no-source-reuse=true (system property). Hopefully, this will change something. Please let me know if it does. Yes, your patch does the trick ! I've built my chapter successfully, then all the chapters of the document and it's OK. Congratulations and thanks very much ! Now I guess you all have to take a decision whether this patch belong to 0.95 release because it is probably needed in a number of situations... And my next problem is to find a way to force memory recycling after this long and hefty FOP processing, but until further investigated this is OT ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Major issue with image loading in FOP 0.95beta
Sorry, I guess in the strictest sense this is xmlgraphics-common related now, but it was discovered and investigated using FOP 0.95beta. We upgraded from 0.94 to use the new bookmarks features and our software became globally unstable, hanging randomly during PDF generation -- to be precise, getting all kinds of random problems during image loading. The images we use are stored in SVN and retrieved via their HTTP URLs from an SVN server. Reading the SVN logs, we see a very different behaviour between 0.94 (which worked fine and has been retested since) and 0.95beta: the FOP requests litteraly suffocate the SVN server, sending quite a lot of requests for images and taking way too long to consume the responses. So, after a (random) while, the SVN server gives up (timeout) and the FOP application on the other side crashes immediately after. At least that is how we understand the problem after testing and reading all sorts of server logs (with a sysadmin) for a whole day. This looks like a major regression and makes 0.95beta completely unusable for us -- though we badly need the new features :-( If anybody had an idea, I must say I'd be extremely grateful... Jean-Francois El Fouly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
Andreas Delmelle a écrit : On May 5, 2008, at 17:22, Jean-François El Fouly wrote: Hi Sorry, I guess in the strictest sense this is xmlgraphics-common related now, but it was discovered and investigated using FOP 0.95beta. We upgraded from 0.94 to use the new bookmarks features and our software became globally unstable, hanging randomly during PDF generation -- to be precise, getting all kinds of random problems during image loading. The images we use are stored in SVN and retrieved via their HTTP URLs from an SVN server. Reading the SVN logs, we see a very different behaviour between 0.94 (which worked fine and has been retested since) and 0.95beta: the FOP requests litteraly suffocate the SVN server, sending quite a lot of requests for images and taking way too long to consume the responses. So, after a (random) while, the SVN server gives up (timeout) and the FOP application on the other side crashes immediately after. At least that is how we understand the problem after testing and reading all sorts of server logs (with a sysadmin) for a whole day. This looks like a major regression and makes 0.95beta completely unusable for us -- though we badly need the new features :-( If anybody had an idea, I must say I'd be extremely grateful... Two questions, for the moment: Which image format(s) are you using? PNG only (but lots of them). Does the JAI/ImageIO implementation on the box where FOP runs, have a native codec to read that format? Will ask / investigate (it's a production server to which I don't have direct access). Debian 4.0 on JDK 1.5.0_11 and JBoss 4.2.1.GA. Thanks ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Major issue with image loading in FOP 0.95beta
Andreas Delmelle a écrit : For now, you also spoke about the requests suffocating the server. Do you mean that there are also a lot /more/ requests, or only that they take longer to process on the FOP-side? If you also have an increase in the total number of requests, this could mean that the image-loading framework (unnecessarily?) tries to access the same images multiple times, which may already provide a pointer as to where to start looking in the code. No, but the behaviour looks very different in the server traces. FOP 0.94: a sequence of : one request / one response / one request / one response etc. with constant (server) response time seen in the server logs. Same application with FOP 0.95beta: seems to launch a whole bunch of requests at the same time, say 5..10.15.. requests for different images seen at the same time in the logs. And more a few seconds later. Now the way we interpret the SVN server logs is that the corresponding responses are consumed slower and slower and the SVN server response time traced in the logs is growing in a linear way until it reaches the server timeout (300 s = 5 min. was the default). Then the SVN server supposes nobody's listening to an answer and somehow closes the connection. And then FOP on the other side crashes immediately. Looks somehow like someone very hungry ordering 10 plates at the same time in a restaurant and eating slowly. Until the waiter gives up. (If you forgive me the comparison.) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with rendering PNG images
Thanks very much for this detailed explanation. Converting the PNG's to JPEG with appropriate colorspace parameters is certainly an option if this solves the problem ? We're already manipulating these images in the different publication processes so if this could be the solution, why not ? After my first post I had a fairly detailed conversation with an in-house graphics designer. We tried direct export of a test image from Photoshop to PDF (using Photoshop so we stay in the Adobe realm all the way) and realized that even in this shortest possible process it's difficult to get the result we need in PDF (not quite impossible but difficult, you really have to change various options). A tough problem at the end. Thanks again ! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help in XSL:FO
Rakesh Kumar S a écrit : Hi Could any one share some ideas as to how to delete the first page of a generated PDF using XSL:FO. Basically after I render all the pages from the XML using XSL:FO I want to delete the first page of the PDF. Is it possible??? Can you share a code snippet. I think this is not possible but I would definitely do that with a couple lines of iText in post-processing.
Problem with rendering PNG images
I have a problem with the way PNG images are rendered. I'm writing tools to manage aircraft technical documentations. One of the documents is the Pilot's Guide, it has quite a lot of cockpit screens screenshots. The source image files are all PNG's, and they have very bright, fully saturated colours such as bright green (0,255,0) -- on black. Yet these images are rendered by FOP in the target PDF with dull colors, rather pale green, pale yellow, pale magenta -- and obviously the customer rejects the document as it is now. Adobe Acrobat Professional seems to tell in the properties that the generated PDF document is CMYK, while the source images are obviously RGB. But I'm not quite sure we understand and interpret this correctly, so take this hint with a pinch of salt. I've looked in quite a lot of directions such as manipulating source images and target resolutions to prevent image resizing (source = target = 300 dpi), or investigated JAI related questions but to no avail. My feeling, reading pieces of the FOP 0.94 source code (ImageFactory) is that JAI is not used at all for the processing of PNG images, it all seems to occur between ImageIO and a PNGImage class that use Apache xmlgraphics own codec. Could the problem be related to the gamma correction param.setPerformGammaCorrection(true); that is used in PNGImage ? By now, all in all, I'm puzzled and can't figure what's happening and how to find a solution to this problem. If someone has an idea I'd be soo grateful ;-) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with rendering PNG images
Peter Coppens a écrit : We have recently reported something similar (it might have been in private to Jeremias...can't remember) and he fixed that problem just this week. It was related to a color profile being truncated (or something like that). Might be the same issue. Perhaps you can try the trunk version of fop or post one of your images. Hth, Peter Great news ! Sounds interesting. I will try to generate an example source image and PDF document (I may not disclose the ones I use for real). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
