Re: First element must be the fo:root when upgrading to 0.93 from 0.20
Hi, Dabkoski, Derrill a écrit : I am attempting to upgrade to FOP 0.93 from 0.20. Unfortunately I am getting a ValidationException saying I need to put fo:root at the top. My first element is an xsl element, but the first fo: element is fo:root. This is exactly the same format as the examples in the fop examples package, for example: fop-0.93/examplesfo/fo-reference/xml2pdf.xsl This is an XSLT stylesheet and not an XSL-FO file. If you want to convert an XML file into PDF using your XSLT stylesheet, you must do the following: fop -xml file.xml -xsl stylesheet.xsl -pdf result.pdf HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with MathML/JEuclid
Hi Deryl, Deryl Seale a écrit : Hello, everyone. Apologies in advance if this has been answered elsewhere, but I have not been able to find a solution to my issue. I am trying to render PDF content that contains embedded MathML, a sample of which is contained in the message below. I found the JEuclid plugin, and have successfully integrated it with Apache FOP such that my MathML contained in instream-foreign-object blocks gets passed to the plugin -- the MathML is being rendered by JEuclid, albeit improperly. The issue I have seems to be with fonts; many of the valid escape sequences (e.g. #8722;) get rendered as # characters, as if the FOP renderer encountered a character that was not in the font family it was using. If I pass the exact same sample.fo file to the JEuclid MathViewer application at the following link (requires JDK 1.5 Web Start to run): http://jeuclid.sourceforge.net/jeuclid-webstart/mathviewer.jnlp .. the math renders perfectly. I have tried registering the JEuclid recommended fonts (e.g. DejaVu) with the FOP renderer, and while the fonts for the body text do change, the equation remains unchanged. I am not sure if this is an issue with the configuration for FOP or JEuclid -- the latter is pretty sparse -- so I am hoping someone has encountered this issue and might be able to give me some pointers. This is strange. If the aspect of the body text changes, I assume you properly configured the DejaVu fonts for FOP and didn't forget to specify the config file on the command line: fop -c config.xml math.fo math.pdf Are you sure the font used for the text really is DejaVu (check the properties of the PDF file in your viewer)? Have you tried the jeuclid-user mailing list? HTH, Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Overflow works in a strange way
Hi I'm not very experienced with FOP, so please be gentle ;-) The report I'm generating uses a historical view of events. Every event must be kept in an atomic block, otherwise the report looks very messy. For instance: 20th September 2006 Clinton wins soccer match bla bla bla bla 22nd September 2006 Bush wins baseball match xyz xyz xyz xyz xyz There must be no page break within such an event. To achieve this, I use ... xsl:template match=histData fo:table table-layout=fixed width=14.7cm fo:table-column column-width=2.5cm / fo:table-column column-width=12.2cm / fo:table-body fo:table-row keep-together=always ... This works well when the event's data is short. However, I have events which contain a lot of event data, and thus FOP tells me WARN Content of the region-body on page 6 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) WARN Content of the region-body on page 4 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) The resulting PDF shows the event data up to the last bit of the page - margins are ignored completely. Also, there's no overflow, the data just stops at the end of the page and is cut off. Am I doing something wrong or is this a FOP problem? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overflow works in a strange way
Hi Eric, keep-together=always on fo:table-row is probably what causes the warnings. You can try to remove this property. Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 13:39 Hi I'm not very experienced with FOP, so please be gentle ;-) The report I'm generating uses a historical view of events. Every event must be kept in an atomic block, otherwise the report looks very messy. For instance: 20th September 2006 Clinton wins soccer match bla bla bla bla 22nd September 2006 Bush wins baseball match xyz xyz xyz xyz xyz There must be no page break within such an event. To achieve this, I use ... xsl:template match=histData fo:table table-layout=fixed width=14.7cm fo:table-column column-width=2.5cm / fo:table-column column-width=12.2cm / fo:table-body fo:table-row keep-together=always ... This works well when the event's data is short. However, I have events which contain a lot of event data, and thus FOP tells me WARN Content of the region-body on page 6 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) WARN Content of the region-body on page 4 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) The resulting PDF shows the event data up to the last bit of the page - margins are ignored completely. Also, there's no overflow, the data just stops at the end of the page and is cut off. Am I doing something wrong or is this a FOP problem? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Overflow works in a strange way
Hi Pascal The problem is that if I use keep-together=auto, then the events are ripped apart, like 20th September 2006 Clinton wins soccer match -- Page break bla bla bla bla I want the events to be atomic, but still overflow into the next page, if necessary. Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 14:00 An: fop-users@xmlgraphics.apache.org Betreff: RE: Overflow works in a strange way Hi Eric, keep-together=always on fo:table-row is probably what causes the warnings. You can try to remove this property. Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 13:39 Hi I'm not very experienced with FOP, so please be gentle ;-) The report I'm generating uses a historical view of events. Every event must be kept in an atomic block, otherwise the report looks very messy. For instance: 20th September 2006 Clinton wins soccer match bla bla bla bla 22nd September 2006 Bush wins baseball match xyz xyz xyz xyz xyz There must be no page break within such an event. To achieve this, I use ... xsl:template match=histData fo:table table-layout=fixed width=14.7cm fo:table-column column-width=2.5cm / fo:table-column column-width=12.2cm / fo:table-body fo:table-row keep-together=always ... This works well when the event's data is short. However, I have events which contain a lot of event data, and thus FOP tells me WARN Content of the region-body on page 6 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) WARN Content of the region-body on page 4 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) The resulting PDF shows the event data up to the last bit of the page - margins are ignored completely. Also, there's no overflow, the data just stops at the end of the page and is cut off. Am I doing something wrong or is this a FOP problem? Best regards, Eric - 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]
space-before vs. margin-top
Hi, I am trying to upgrade from 0.20.5 to 0.93 and stumble over the lack of support for space-before which seems to refuse to work in certain conditions. Replacing space-before with margin-top (which has better support in the new version) seems to produce the expected output. Can anyone explain to me the difference between these both? Is there any? They seem to work exactly the same (at least on block-level elements). Is there hope for space-before being implemented soonish, or should I rather invest time in converting all the stylesheets? Thank you and best regards, Alex __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
start-indent correct behavior?
Hi, when I apply a start-indent to a fo:block containing a fo:table each and every fo:cell inherits this start-indent, producing very strange output. Is this a bug or correct behavior? This introduces a major incompatibilty for FO-Layouts written for 0.20.5 ... Any ideas? Best regards, Alex __ Alexander Lohse • Entwicklungsleitung Projektmanagement Tel +49 38374 752 11 • Fax +49 38374 752 23 http://www.humantouch.de Human Touch Medienproduktion GmbH Am See 1 • 17440 Klein Jasedow • Deutschland Geschäftsführung: Lara Mallien, Nele Hybsier, Alexander Lohse, Johannes Heimrath (Senior) Handelsregister Stralsund • HRB 4192 • USt-IdNr. DE128367684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Help with MathML/JEuclid
Are you sure the font used for the text really is DejaVu (check the properties of the PDF file in your viewer)? Yes, I am fairly certain it's DejaVu -- it visibly changes to what I'd expect the font to look like, and upon inspection in the file properties, I see the DejaVu font listed along with the other Acrobat internal fonts. Is there anything else I need to do to get JEuclid working besides installing the plugin, registering the proper font family with FOP, and making sure my FO input XML is properly set up? Has anyone else successfully run the JEuclid plugin? Have you tried the jeuclid-user mailing list? I will try them now, though it looks like a low traffic list. thanks. --Deryl - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overflow works in a strange way
Eric, you can use the property orphans on fo:table-rows, telling the minimum number of line in your row at bottom of page. HTH, Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:02 À : fop-users@xmlgraphics.apache.org Objet : AW: Overflow works in a strange way Hi Pascal The problem is that if I use keep-together=auto, then the events are ripped apart, like 20th September 2006 Clinton wins soccer match -- Page break bla bla bla bla I want the events to be atomic, but still overflow into the next page, if necessary. Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 14:00 Hi Eric, keep-together=always on fo:table-row is probably what causes the warnings. You can try to remove this property. Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 13:39 Hi I'm not very experienced with FOP, so please be gentle ;-) The report I'm generating uses a historical view of events. Every event must be kept in an atomic block, otherwise the report looks very messy. For instance: 20th September 2006 Clinton wins soccer match bla bla bla bla 22nd September 2006 Bush wins baseball match xyz xyz xyz xyz xyz There must be no page break within such an event. To achieve this, I use ... xsl:template match=histData fo:table table-layout=fixed width=14.7cm fo:table-column column-width=2.5cm / fo:table-column column-width=12.2cm / fo:table-body fo:table-row keep-together=always ... This works well when the event's data is short. However, I have events which contain a lot of event data, and thus FOP tells me WARN Content of the region-body on page 6 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) WARN Content of the region-body on page 4 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) The resulting PDF shows the event data up to the last bit of the page - margins are ignored completely. Also, there's no overflow, the data just stops at the end of the page and is cut off. Am I doing something wrong or is this a FOP problem? Best regards, Eric - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: space-before vs. margin-top
Hi, as the spec XSL-FO 1.1 says, there can be a difference between space-* and margin-* (see the .conditionality component, witch defaults to 'discard' with space-*): The space-before, and space-after properties (block-level formatting objects), space-start, and space-end properties (inline-level formatting objects) are handled in the same way as the properties immediately above, but the corresponding absolute properties are in the set: margin-top, margin-bottom, margin-left, and margin-right. The .conditionality component of any space-before or space-after determined from a margin property is set to retain. Pascal -Message d'origine- De : Alexander Lohse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:04 Hi, I am trying to upgrade from 0.20.5 to 0.93 and stumble over the lack of support for space-before which seems to refuse to work in certain conditions. Replacing space-before with margin-top (which has better support in the new version) seems to produce the expected output. Can anyone explain to me the difference between these both? Is there any? They seem to work exactly the same (at least on block-level elements). Is there hope for space-before being implemented soonish, or should I rather invest time in converting all the stylesheets? Thank you and best regards, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Overflow works in a strange way
Hi Pascal If I understand you right, you suggest something like fo:table-row keep-together=always orphans=5 I just tried it, but it doesn't solve the problem. The whole event is put into one table row, and the event data contains pseudo-HTML (like br and p) which is translated into FO blocks and carriage returns. So, showing one table row, it goes from +-+-+ | | | +-+-+ (for normal event data) to +-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+ (for my problem) But it's all still *one* table row. Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 14:19 An: fop-users@xmlgraphics.apache.org Betreff: RE: Overflow works in a strange way Eric, you can use the property orphans on fo:table-rows, telling the minimum number of line in your row at bottom of page. HTH, Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:02 À : fop-users@xmlgraphics.apache.org Objet : AW: Overflow works in a strange way Hi Pascal The problem is that if I use keep-together=auto, then the events are ripped apart, like 20th September 2006 Clinton wins soccer match -- Page break bla bla bla bla I want the events to be atomic, but still overflow into the next page, if necessary. Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 14:00 Hi Eric, keep-together=always on fo:table-row is probably what causes the warnings. You can try to remove this property. Pascal -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 13:39 Hi I'm not very experienced with FOP, so please be gentle ;-) The report I'm generating uses a historical view of events. Every event must be kept in an atomic block, otherwise the report looks very messy. For instance: 20th September 2006 Clinton wins soccer match bla bla bla bla 22nd September 2006 Bush wins baseball match xyz xyz xyz xyz xyz There must be no page break within such an event. To achieve this, I use ... xsl:template match=histData fo:table table-layout=fixed width=14.7cm fo:table-column column-width=2.5cm / fo:table-column column-width=12.2cm / fo:table-body fo:table-row keep-together=always ... This works well when the event's data is short. However, I have events which contain a lot of event data, and thus FOP tells me WARN Content of the region-body on page 6 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) WARN Content of the region-body on page 4 overflows the available area in block-progression dimension. (fo:page-sequence, no context info available) The resulting PDF shows the event data up to the last bit of the page - margins are ignored completely. Also, there's no overflow, the data just stops at the end of the page and is cut off. Am I doing something wrong or is this a FOP problem? Best regards, Eric - 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: start-indent correct behavior?
Ho Alex, There is no bug, but unexpected rendering... There is a very nice Wikipage that explain the *-indent inheritence behaviour: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance HTH, Pascal -Message d'origine- De : Alexander Lohse [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:04 Hi, when I apply a start-indent to a fo:block containing a fo:table each and every fo:cell inherits this start-indent, producing very strange output. Is this a bug or correct behavior? This introduces a major incompatibilty for FO-Layouts written for 0.20.5 ... Any ideas? Best regards, Alex - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overflow works in a strange way
-Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:32 Hi Pascal If I understand you right, you suggest something like fo:table-row keep-together=always orphans=5 Yes, but you should remove the keep-together property here I just tried it, but it doesn't solve the problem. The whole event is put into one table row, and the event data contains pseudo-HTML (like br and p) which is translated into FO blocks and carriage returns. So, showing one table row, it goes from +-+-+ | | | +-+-+ (for normal event data) to +-+-+ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | +-+-+ (for my problem) But it's all still *one* table row. Hmm, I don't understand what you say here. If you want to split a unique row in multiple rows, you should have look in your XSLT. If you want that short rows are not cutted at the end of page, then use orphans property. If you want that long rows don't overflow the body, then remove the keep-together property. Best regards, Eric HTH, Pascal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
AW: Overflow works in a strange way
Hi Pascal Sorry if I'm not clear enough, I'll try to explain using an example: Let's say that I have four events that I want to show. Every event represents one table row and must normally (!) be atomic. Thus, from this situation +-+-+ -- Page start | | | +-+-+ +-+-+ | | | | | | +-+-+ +-+-+ | | | | | | | | | | | | | | | | | | +-+-+ +-+-+ | | | | | | | | | -- Normal page end | | | | | | | | | +-+-+ I want this result: +-+-+ -- Page start | | | +-+-+ +-+-+ | | | | | | +-+-+ +-+-+ | | | | | | | | | | | | | | | | | | +-+-+ -- Page end +-+-+ -- Page start | | | | | | | | | | | | | | | | | | +-+-+ -- Page end As required, the table row containing one event is not split. However, if one table row is bigger than the page +-+-+ -- Page start | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- Normal page end | | | | | | | | | +-+-+ then FOP should split it, only because it can't possibly fit it on one page. But this should be the exception. +-+-+ -- Page start | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- Page end | | | -- Page start | | | | | | +-+-+ -- Page end Is this clearer? Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 14:45 An: fop-users@xmlgraphics.apache.org Betreff: RE: Overflow works in a strange way -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:32 Hi Pascal If I understand you right, you suggest something like fo:table-row keep-together=always orphans=5 Yes, but you should remove the keep-together property here I just tried it, but it doesn't solve the problem. The whole event is put into one table row, and the event data contains pseudo-HTML (like br and p) which is translated into FO blocks and carriage returns. So, showing one table row, it goes from +-+-+ | | | +-+-+ (for normal event data) to +-+-+ | | | | | | | | | | | | | |
Link on a graphic
Hi, I have the following problem. I need to place a link on a picture in my PDF. Is there a specific manner to do in order to have the link in the whole area of the picture. For the moment the link is just on the few last lines of the picture. I'm using FOP 0.93. Thanks for your answers. Cecile - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overflow works in a strange way
-Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 14:57 Hi Pascal Sorry if I'm not clear enough, I'll try to explain using an example: OK, this list is made for that ;) Let's say that I have four events that I want to show. Every event represents one table row and must normally (!) be atomic. Thus, from this situation +-+-+ -- Page start | | | +-+-+ +-+-+ | | | | | | +-+-+ +-+-+ | | | | | | | | | | | | | | | | | | +-+-+ +-+-+ | | | | | | | | | -- Normal page end | | | | | | | | | +-+-+ I want this result: +-+-+ -- Page start | | | +-+-+ +-+-+ | | | | | | +-+-+ +-+-+ | | | | | | | | | | | | | | | | | | +-+-+ -- Page end +-+-+ -- Page start | | | | | | | | | | | | | | | | | | +-+-+ -- Page end Well, here, you just need to tweek the orphans property, that defines the minimum size of a row at bottom of page As required, the table row containing one event is not split. However, if one table row is bigger than the page +-+-+ -- Page start | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- Normal page end | | | | | | | | | +-+-+ then FOP should split it, only because it can't possibly fit it on one page. But this should be the exception. +-+-+ -- Page start | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -- Page end | | | -- Page start | | | | | | +-+-+ -- Page end And here, you have to remove the keep-together property (if not, the row is not cutted at the bottom of page) Is this clearer? Yes Best regards, Eric Hope you will get what you want Pascal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Overflow works in a strange way
-Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 15:33 Hi Pascal Thanks! Now the only question I have is: How do I do it? ;-) I mean, how can decide beforehand when I need to change the 'orphans' and 'keep-together'? If there was some way that FOP would tell me Watch out, you're going to have an overflow, then I could switch to the table rows without 'keep-together', but how can that happen? In a perfect world, you should have the same set of properties on each fo:row (with orphans, and without keep-together). In the real world, you may have to tweek this... A possible approach is to get the characters number in a cell, Then choose what properties should be set or not, regarding this number... Or perhaps I'm just thinking in a non-FOP way? FOP is OK for that But XSLT size can grow and grow... Best regards, Eric Pascal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Link on a graphic
Pascal, I've already read that, but there is no real example, you talked about font-size or wrapper but I don't see these elements in the examples. So I try what I understood, mais this doesn't resolve my problem. Have you a real XML example that shows the solution ? Thanks Cecile Pascal Sancho a écrit : Hi Cecile This is a known bug (see [1]) And I have yet provided a workaround on this list last month: see [2] [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=42501 [2] http://marc.info/?l=fop-userm=117990908713295w=2 Pascal -Message d'origine- De : Cecile HENNER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 15:07 Hi, I have the following problem. I need to place a link on a picture in my PDF. Is there a specific manner to do in order to have the link in the whole area of the picture. For the moment the link is just on the few last lines of the picture. I'm using FOP 0.93. Thanks for your answers. Cecile - 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: Link on a graphic
Well,
Here is a short snippet that illustrates what I said.
You need to set both font-size and alignment-adjust properties elsewhere.
fo:basic-link external-destination=http://your.link.here;
fo:wrapper
font-size={$graphic_height}mm
alignment-adjust=after-edge
fo:external-graphic
src=url(your.image.here)
content-height={$graphic_height}mm
content-width=60mm /
/fo:wrapper
/fo:basic-link
HTH,
Pascal
-Message d'origine-
De : Cecile HENNER [mailto:[EMAIL PROTECTED]
Envoyé : mercredi 6 juin 2007 16:02
Pascal,
I've already read that, but there is no real example, you
talked about font-size or wrapper but I don't see these
elements in the examples.
So I try what I understood, mais this doesn't resolve my problem.
Have you a real XML example that shows the solution ?
Thanks
Cecile
Pascal Sancho a écrit :
Hi Cecile
This is a known bug (see [1])
And I have yet provided a workaround on this list last
month: see [2]
[1] http://issues.apache.org/bugzilla/show_bug.cgi?id=42501
[2] http://marc.info/?l=fop-userm=117990908713295w=2
Pascal
-Message d'origine-
De : Cecile HENNER [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin
2007 15:07
Hi,
I have the following problem. I need to place a link on a
picture in
my PDF. Is there a specific manner to do in order to have
the link in
the whole area of the picture. For the moment the link is
just on the
few last lines of the picture.
I'm using FOP 0.93.
Thanks for your answers.
Cecile
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Perfomance Issue need Help on generating PDF from XSL FO
Hi,
I created a code snippet to convert XML+XSL FO to PDF using FOP.
I am using OC4j as Application Server.
Here is the code:
FopFactory fopFactory = FopFactory.newInstance();
FOUserAgent foUserAgent = fopFactory.newFOUserAgent();
OutputStream out = new BufferedOutputStream(new FileOutputStream(new
file(/brodart.pdf)));
Try
{
System.setProperty(javax.xml.transform.TransformerFactory,org.apache.xalan.processor.TransformerFactoryImpl);
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF, foUserAgent,
out);
TransformerFactory factory = TransformerFactory.newInstance();
Transformer transformer = factory.newTransformer(new
StreamSource(new File(/Brodart.xsl)));
transformer.setParameter(versionParam, 2.0);
Source src = new StreamSource(new File(/brodart.xml));
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(src, res);
}
At the highlighted step seems to be taking a lot of time to execute (around
15 min).
Can any one please help on this issue? Here I attached the XML and XSL file
we are using.
Thanks
Manoj http://www.nabble.com/file/p10989960/XML_XSL.zip XML_XSL.zip
--
View this message in context:
http://www.nabble.com/Perfomance-Issue-need-Help-on-generating-PDF-from-XSL-FO-tf3878334.html#a10989960
Sent from the FOP - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
AW: Overflow works in a strange way
Hi Pascal Thanks for your help! I built in the following: fo:table-row xsl:choose xsl:when test=text and string-length(text) 1800 xsl:attribute name=keep-togetherauto/xsl:attribute /xsl:when xsl:otherwise xsl:attribute name=keep-togetheralways/xsl:attribute /xsl:otherwise /xsl:choose and this works perfectly. However, I still don't know whether it's a FOP bug that before, the text went down to the bottom of the page, ignoring margins and was partially lost. Best regards, Eric -Ursprüngliche Nachricht- Von: Pascal Sancho [mailto:[EMAIL PROTECTED] Gesendet: Mittwoch, 6. Juni 2007 15:45 An: fop-users@xmlgraphics.apache.org Betreff: RE: Overflow works in a strange way -Message d'origine- De : Lewis, Eric [mailto:[EMAIL PROTECTED] Envoyé : mercredi 6 juin 2007 15:33 Hi Pascal Thanks! Now the only question I have is: How do I do it? ;-) I mean, how can decide beforehand when I need to change the 'orphans' and 'keep-together'? If there was some way that FOP would tell me Watch out, you're going to have an overflow, then I could switch to the table rows without 'keep-together', but how can that happen? In a perfect world, you should have the same set of properties on each fo:row (with orphans, and without keep-together). In the real world, you may have to tweek this... A possible approach is to get the characters number in a cell, Then choose what properties should be set or not, regarding this number... Or perhaps I'm just thinking in a non-FOP way? FOP is OK for that But XSLT size can grow and grow... Best regards, Eric Pascal - 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: First element must be the fo:root when upgrading to 0.93 from 0.20
Hi Vincent, Thanks for responding. I was actually trying to get embedded java code to work... I used the code exactly as it was in ExampleXML2PDF.java and I got past that error. I'm not sure why my code didn't work since it was identical except my code had fopFactor.setUserConfig() and didn't use a foAgentUser. Perhaps there was something in my config file causing the issues. Thanks for your help! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
