Re: vertical-align=middle does not put content of table-cell in the middle
On Feb 28, 2007, at 14:55, Abel Braaksma wrote: Hi Abel, Andreas L Delmelle wrote: On Feb 28, 2007, at 13:45, Abel Braaksma wrote: ... The vertical-align shorthand does not apply to a fo:table-cell, and since it is non-inherited, specifying it there does not have any effect (unless a value of "inherit" or "from-nearest-specified ()" is used on the descendants). Thanks for your quick reply, Andreas. From http://www.w3.org/TR/2001/REC-xsl-20011015/ slice7.html#vertical-align it says: "Applies to: inline-level and 'table-cell' elements", which I interpreted as that it applies to fo:table-cell as well. Do I misinterpret the spec? No, but... This part of the property definition seems to have been removed in XSL 1.1, most likely to remove the inherent contradiction with http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#fo_table-cell where vertical-align is not mentioned as an applicable property. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: vertical-align=middle does not put content of table-cell in the middle
On Feb 28, 2007, at 13:45, Abel Braaksma wrote: Hi, I have a nicely formatted table but got stuck when trying to adjust the content of each cell to the middle of it. Perhaps this has been asked before, but I didn't find it in the archives. Here is the snippet: ... The vertical-align shorthand does not apply to a fo:table-cell, and since it is non-inherited, specifying it there does not have any effect (unless a value of "inherit" or "from-nearest-specified()" is used on the descendants). If I judge correctly, the property you're actually looking for is display-align : In addition: on the compliance page I found "[0.93] Percentages are not supported, yet." and on the history of changes (http:// xmlgraphics.apache.org/fop/0.93/changes_0.93.html) I found "Bugfix: Percentages in vertical-align property values were not correctly handled." which sounds to me that percentages should work now, is it not? This indeed sounds like an oversight. We'll have to check whether the testcases cover this and update the compliance page if necessary. Thanks for reporting this. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Header and Footer in new xsl
On Feb 27, 2007, at 14:22, Maheswaran wrote: Hi, I am doing a report generation. I am using FOP to generate PDF file. I am using xsl:fo for formatting.Presently i am defining the header, body, footer in the same page master as follows I need to seperate the header and footer in seperate file so that any change in the header and footer can be accomodated easily. is it possible to get the header and footer from seperate xsl file and import it to the main xsl file. Can u guide me in this regard?... If I understand the issue correctly, then I personally do something similar: * the part above --the page-master-- still remains in the main .xsl file * the fo:static-contents that will end up in those headers/footers are defined in named templates in a separate .xsl file, referenced by the main .xsl through xsl:include Example: In the separate stylesheet, name it 'headers-footers.xsl', you'll have some templates like: ... ... In the main .xsl, you'll then need something like: ... HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unicode?
On Feb 27, 2007, at 20:33, Thomas Zastrow wrote: Hi Thomas, I put some kyrillic letters in a document and in the resulting PDF- file they were replaced with #-signs. Is this just a problem of the used font? FOP supports unicode, am I right? FOP indeed supports Unicode --as is required of every XML- application--, but the standard fonts (Base14) do not have glyphs for every single character. The solution is to use a custom font that does contain glyphs for the characters you use (e.g. 'Arial Unicode' or 'Lucida Sans Unicode'...) For more info concerning font-embedding and configuration, see: http://xmlgraphics.apache.org/fop/0.93/configuration.html or http://xmlgraphics.apache.org/fop/0.93/fonts.html P.S.: My little project with FOP is going on well, I hope to show you something the next days :-) Cool! Only thing to keep in mind if you publish it, are font- licensing issues. To avoid possible problems, it's advisable to look for a free font, so this issue is sidestepped. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the level of standard support when compliance table says "yes"?
On Feb 26, 2007, at 18:21, Andreas L Delmelle wrote: ... note that the same goes for padding) Correction: I got this wrong. What's so special about padding is that the padding-* properties only apply to fo:table and fo:table-cell, but are not taken into account on fo:table when using border-collapse="collapse". The reason being that in the separate border model, the table border and the cell border are, well, separated. The space between them can be set through the border-separation property. This goes for the borders between neighboring cells as well. The distance between the outer cells' borders and the table borders then becomes: table-padding + border-separation. In the collapsing border-model, however, there is no 'space' in between two cells or between the outer cells and the edges of the table (~ the border segments are literally shared). Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the level of standard support when compliance table says "yes"?
On Feb 26, 2007, at 16:58, Vincent Hennebert wrote: You will get warnings from FOP that in the separate border model borders on table-column and table-row are not applicable, but in this particular case we want to take advantage of inheritance. You must still specify border="inherit" on table-cells because border properties are not inheritable by default, but that allows you to specify them only at one place. All of that leads to the following question: IIC the above is allowed by the spec, so the warning messages should not be displayed. Or is it not? What do others think? We could maybe remove them, if needed... OTOH, we haven't received any complaints (yet :/) about these warnings. They were more meant to avoid the scenario where someone uses borders on table-column or table-row with the separate border model, and wonders why it doesn't have any effect in the output. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the level of standard support when compliance table says "yes"?
On Feb 26, 2007, at 16:30, Abel Braaksma wrote: Andreas L Delmelle wrote: The reason is twofold: -> FOP 0.93 does not yet offer support for border- collapse="collapse" (nor "collapse-with-precedence") -> with border-collapse="separate", borders only apply to fo:table or fo:table-cell Aha, so, in other words: because "collapse" is not supported, the properties that depend on them (among others: all border-related properties of fo-table-row, fo:table-body, fo:table-column) are not supported either, because they only have meaning when "collapse" is set. This is according to the XSL-FO spec. Indeed. More generally, you could say that "the collapsing border model is not implemented", so that refers to the specific property on fo:table but also everything else related to this (like border- properties on columns/rows...; note that the same goes for padding) This "not being implemented" currently goes so far as to force the separate border model (with a warning) if you try to specify otherwise. 2. Is there a way, other than using borders on each cell, to get the borders for the column/row to work? Is there a shortcut way to just set all borders of table/rows/columns/cells to the same properties? Not unless someone gets around to implementing border- collapse="collapse", I'm afraid... :( Not exactly a complete answer, but because it is so easy to implement and does what I want, here's a solution: A good one. Another alternative was posted by Vincent: using the column/body/row as mere carriers of properties, and using a combination of border="inherit" with from-table-column() (and possibly from-parent()). At any rate, the big difference with the collapsing border model, is that there will be no more need to specify borders on the cells, and you can simply do: repeated="5" /> ... ... And all the cells will have the same border, while no border was specified directly on them. This is the closest one can get to the effect of "rules='all'" in HTML-tables. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is the level of standard support when compliance table says "yes"?
On Feb 26, 2007, at 15:05, Abel Braaksma wrote: Hi Abel, I was testing the FOP 0.93 the other day and worked through some samples and tried some myself. I was wondering why something like: does not give a border and style="solid"> does. That's because the initial value for the border-style property is "none". Or more correct: the individual properties for each side (border- before-style etc.) default to "none", and the border-style shorthand refers to the individual properties for the initial value. BTW, you can also use the border-shorthand: I had some more trouble getting the borders of fo:table-column and fo:table-row to work. The reason is twofold: -> FOP 0.93 does not yet offer support for border- collapse="collapse" (nor "collapse-with-precedence") -> with border-collapse="separate", borders only apply to fo:table or fo:table-cell As a result, I have two questions to the community: 1. If the compliance table says "yes" should I, or should we not, interpret that as being compliant to the spec? Should be compliant, apart from limitations mentioned in the last column. If you ever feel you have discovered a limitation that is not clear from the compliance page, feel free to post it here (or rather fop-dev@), so we can make the necessary changes. 2. Is there a way, other than using borders on each cell, to get the borders for the column/row to work? Is there a shortcut way to just set all borders of table/rows/columns/cells to the same properties? Not unless someone gets around to implementing border- collapse="collapse", I'm afraid... :( If (1) is answered with "yes", then I believe the above to be a bug in FOP 0.93. I know it is a work in progress, but if the answer is "no", it would perhaps save you, the programmers, and others some work, like answering questions like these, when you update the compliance table with accurate data (I volunteer to do a part of it). If you volunteer, even better! :) In that case, you'll find the base files in the FOP source distribution (or better: the repository) under: .../src/documentation/ content/xdocs. You can always submit a patch via Bugzilla. TIA! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page Slop
On Feb 25, 2007, at 21:40, Jim Tivy wrote: Hi Jim, Below is my further info. Any follow up on this? Sorry, missed this one the first time, it seems... -Original Message- From: Jim Tivy [mailto:[EMAIL PROTECTED] I had a look at these but they do not work. Unfortunatly we want the page layout engine to create the blanks as it renders the content of a page sequence. OK, I think I see why you're using a zero-height region-body... Someone suggested this might be illegal in XSL - but it is accepted in both .20 and .93. AFAICT from the Recommendation, what you're doing isn't illegal, and since it seems to be working in the general case, you may just have stumbled upon some kind of anomaly that would make a good testcase. If you can, try to trim it down to the smallest possible FO file that demonstrates the weird behaviour, and attach that to a Bugzilla entry. (even if 'the smallest possible' means an FO generating at least 8 pages) That would certainly help a lot in tracking this down further. TIA! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Footmnote-problem
On Feb 23, 2007, at 16:25, Luca Furini wrote: Andreas L Delmelle wrote: If 'minimum' is greater than optimum, it will be treated as if it had been set to 'optimum'. If 'maximum' is less than optimum, it will be treated as if it had been set to 'optimum'." Specifying only .optimum should lead to a resolved min=opt=max. ... or maybe min=0pt, opt=max? At least, this is what happens at the moment: the resulting space can shrink. It just occurred to me that using only the .minimum component for positive spaces (resp. the .maximum for negative spaces) will indeed lead to the problem Luca saw (IIC?) In that case, since the specified .minimum (.maximum) would be greater (less) than the implicit optimum, it would set to .optimum, leading to a resolved: min=opt=max=0 Just thought I'd share. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Linefeed and space before footnotes??
On Feb 24, 2007, at 20:12, Andreas L Delmelle wrote: ... how can I increase the space between the normal text on a page and the complete block of footnotes? IIC, then you can achieve that effect using an empty fo:block in a fo:static-content with flow-name="xsl-footnote-separator", so something like: Sorry, typed a bit too fast. Should of course be: Naturally, you could also use a block with a few preserved linefeeds... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Linefeed and space before footnotes??
On Feb 24, 2007, at 17:59, Thomas Zastrow wrote: Hi Thomas, I have two more problems :-) That's what we're here for :-) At first, how can I do a "double carriage return"? I mean, how can I simulate within a fo:block two \n in the resulting PDF-file? I googled around and found, hm, let me say, just confusing answers ... :-) If you're using FOP Trunk, you could do something like: In 0.93, the above will not yet produce empty lines, so you need to fill the line yourself with something like: fo:block> And second, my footnotes are working fine now, thanx to all! But how can I increase the space between the normal text on a page and the complete block of footnotes? IIC, then you can achieve that effect using an empty fo:block in a fo:static-content with flow-name="xsl-footnote-separator", so something like: HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem with text flow
On Feb 23, 2007, at 19:38, Miroslav Pukhalsky wrote: Hi, I want to do something like this (see in attachment), but I do not know how. What can I do for result like on the picture from attach? You would need to place the fo:external-graphic in an fo:float with float="start", IIC. Unfortunately, this is not yet supported by any released FOP version. IIRC, there is a branch that contains a basic implementation for floats, but AFAIK this branch has not yet been merged back into the trunk. No immediate workaround comes to mind. Sorry, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Footmnote-problem
On Feb 23, 2007, at 16:25, Luca Furini wrote: Andreas L Delmelle wrote: If 'minimum' is greater than optimum, it will be treated as if it had been set to 'optimum'. If 'maximum' is less than optimum, it will be treated as if it had been set to 'optimum'." Specifying only .optimum should lead to a resolved min=opt=max. ... or maybe min=0pt, opt=max? D'oh! Indeed, correct again. Obviously the implicit minimum is not greater than the optimum here... could be the case for negative spaces only. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: odd error from 0.93
On Feb 23, 2007, at 13:38, Andreas L Delmelle wrote: Arturo, I'll try to reduce the FO-file further, until it only contains a very small sample that we can add to our testcases. I'll open a Bugzilla entry as soon as I have a clear picture of what the cause is. After closer inspection of the FO, I don't think it is a bug. Strictly speaking, you weren't doing anything wrong, only something that the XSL-FO Recommendation leaves a bit vague IMO... You're specifying width="100%" on the fo:table-cells in question. Removing these seems to solve the problem. Can you try that on your end, and check if that does it? If not, then don't hesitate to report back. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] Fop 0.93 & Ant task: Assigning more memory?
On Feb 23, 2007, at 15:32, Paul Moloney wrote: Actually, the developer who updated the build files to upgrade from fop 0.20.5 to 0.93 changed how Fop was run from running as a Java task to using a Fop task because he found running as a Java task no longer worked, at least in the previous format. The original (from fop 0.20.5) was this: For Fop 0.93, do I simply replace the classname with "org.apache.fop.cli.Main" or is there more involved? Only slightly more, but not much: Be sure to update 'fop.lib.path' if it contains explicit references to jars that are in the FOP 0.20.5 distribution but not in 0.93 (resp. misses references to jars not present in 0.20.5 but required for 0.93) HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop 0.93 & Ant task: Assigning more memory?
On Feb 23, 2007, at 13:34, Paul Moloney wrote: Hi Paul, http://xmlgraphics.apache.org/fop/0.93/anttask.html doesn't specify any way that Fop can be assigned more memory. Is there anyway to pass in Xms/Xms arguments? Unfortunately, not by using the FOP anttask directly, but some users have reported that they use Ant's java task in that case. For example: HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: odd error from 0.93
On Feb 22, 2007, at 21:39, Andreas L Delmelle wrote: If you look at the first table, you can see that some of the text ends up outside the table-cell it's supposed to be within. Indeed, at first glance, it seems like a weird interaction between table-layout and list-layout. Correction: looking closer at where the related text is in the FO source, it seems to be related to nested tables. I'll try to reduce the FO-file further, until it only contains a very small sample that we can add to our testcases. I'll open a Bugzilla entry as soon as I have a clear picture of what the cause is. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP -Printing specified number of pages
On Feb 22, 2007, at 21:47, Ramakrishna wrote: Hi Ram, Thanks Andreas! FYI: I have opened a Bugzilla entry (41687) for this issue, so we don't lose track of it. If you want to be notified about changes in status, feel free to add yourself to the CC-list for that bug. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using custom EntityResolver with fop 0.92
On Feb 22, 2007, at 23:12, Arturo Perez wrote: On Thu, 22 Feb 2007 22:08:58 +0100, Andreas L Delmelle wrote: Before we go any further: Did you try Jeremias' suggestion and set the URIResolver on both the FopFactory and the TransformerFactory? During one iteration I put the URIResolver on every XMLReader created by that codepath. Same problem. Is that different than what you/Jeremy suggested? To follow Jeremias' suggestion to the letter, try adding: stf.setURIResolver(ArticleHelper.getURIResolver()); right after you get the SAXTransformerFactory instance. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using custom EntityResolver with fop 0.92
On Feb 22, 2007, at 21:55, Arturo Perez wrote:
Arturo,
I really need help on making this work with 0.92beta. I could
probably
upgrade to 0.93 if that works better. Please note that I have this
working
for a plain XSL that converts XML to HTML where FOP is not involved.
I put the URIResolver on the FOPFactory like this:
fopFactory.setURIResolver(ArticleHelper.getURIResolver());
The transforming code for the PDF looks like:
Transformer transformer = foFilter.getTransformer();
Templates psmiTemplates = TemplatesManager.getTemplates("psmi");
SAXTransformerFactory stf = (SAXTransformerFactory)
TransformerFactory.newInstance();
XMLFilter psmiFilter = stf.newXMLFilter(psmiTemplates);
Before we go any further:
Did you try Jeremias' suggestion and set the URIResolver on both the
FopFactory and the TransformerFactory?
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: odd error from 0.93
On Feb 22, 2007, at 20:15, Arturo Perez wrote: Hi Arturo, I am attaching an obfuscated .fo. It's obfuscated by random substitution of the text with random characters. The fo structure remains the same. One of these days I need to make my obfuscator use Lorem ipsum etc. Never mind that. Your sample is fine as it is to start the investigation, thanks! Just had to remove a couple of linefeeds that were inserted inside the attributes, and was good to go. If you look at the first table, you can see that some of the text ends up outside the table-cell it's supposed to be within. Indeed, at first glance, it seems like a weird interaction between table-layout and list-layout. This deserves closer attention. Unfortunately, I have no immediate fix except to seek an alternative to lists inside tables... Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP -Printing specified number of pages
On Feb 22, 2007, at 20:34, Ramakrishna wrote: Hi, I tried to print with the .fo file instead of giving the xml and xsl files but still it printed all the pages. There is slight variation in the command usage I gave the command as java -Dstart=2 -Dend=2 org.apache.fop.cli.Main infile.fo -print The following command gives Exception in thread "main" java.lang.NoSuchMethodError: main java -Dstart=2 -Dend=2 org.apache.fop.apps.Fop infile.fo -print From this we can tell that you use FOP 0.92b or higher. Unfortunately, it seems like this functionality was broken in the trunk code at some point. :( I'd try looking at it myself, but am currently focusing on other parts of the code, and don't feel much for switching context ATM, so it could take a while. In the meantime, a possible workaround for you could be to always render to PDF and print the desired pages from it with an external tool like GhostScript or pdftk. This has the benefit of the printed output matching the PDF much closer. While substantial efforts have been made to make the different renderers' outputs as close to each other as possible, this is not guaranteed to be the case for PDF and Print output (the PrintRenderer depends on Java AWT, the PDFRenderer does not; in borderline cases this could even lead to the printed result having slightly different page-breaks, although that should be very rare) If your printer understands PS, then you could also consider that format. The basis of the PDF and PS renderers are the same. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Footmnote-problem
On Feb 22, 2007, at 13:17, Luca Furini wrote: Hi Luca, Concerning the following: - there are a few space-before and space-after defined using just the .optimum component; I was wondering if this is correct (isn't the default value for .maximum and .optimum 0 points?) You are correct about the initial values for the other components, but it is also correct to use only the .optimum component. The answer is in the Rec's definition of the compound datatype (XSL 1.1 - 5.11) "A compound datatype, with components: minimum, optimum, maximum, precedence, and conditionality. ... If 'minimum' is greater than optimum, it will be treated as if it had been set to 'optimum'. If 'maximum' is less than optimum, it will be treated as if it had been set to 'optimum'." Specifying only .optimum should lead to a resolved min=opt=max. - there is always an empty block at the end of the foontote-body; at the moment it does not have any effect on the output, so they could maybe be avoided In this case, I'd say "Definitely to be avoided", and as mentioned recently in another thread, using empty blocks for no other reason than to force a line-break should be avoided whenever possible, due to the overhead of creating a corresponding Block and BlockLayoutManager. Using linefeed-treatment="preserve" is much more efficient. Too bad it has such weird effects in combination with hyphenate="true" :( Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spaces between calls to same template
On Feb 22, 2007, at 10:14, Daniel Schaedler wrote: Hi Daniel, Andreas L Delmelle wrote: Very quick way to check this is to try adding the following to your stylesheet: You are absolutely right :-) I wasn't aware that linebreaks and spaces do matter in my XML. This solved my problems - thank you!! Glad I could help. Be warned though: my suggestion will only work if the stylesheet *never* relies on the built-in template rule for text() (which corresponds to using *only* xsl:value-of to output CDATA content from the source XML). Just so you know where to look when text suddenly starts disappearing after my proposed change. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: spaces between calls to same template
On Feb 21, 2007, at 22:54, Daniel Schaedler wrote: Hi, I reduced the template to: *** *** and I still get the spaces. I'm also sure that the input for the 'value-of' does not contain any spaces. When I change the template to: *** *** Then I get every text doubled without a space between the doubletts - as expected. That's the reason why I believe it has something to do with the calling of the template itself (?) quite strange - I don't understand it... The explanation is probably that you have no explicit matching template for text() nodes (note: text(), not your text nodes). In the first case, a linefeed or space in between two text-nodes in your source XML will invoke the built-in template rule: When using default/initial values for white-space-treatment, white- space-collapse and linefeed-treatment, these will all be normalized into space characters by FOP. Very quick way to check this is to try adding the following to your stylesheet: HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] font-family="Arial Unicode MS" in rtf doesn't work
On Feb 21, 2007, at 14:37, Jeff Vannest wrote: Hi Jeff, I promised myself to ignore whatever spawned from the remainders of this thread, but decided to peek anyway, and I'm glad to have stumbled on this one: ... we're not nice people; or rather, it's irrelevant whether we are. That's certainly a /nice/ way to put it! I agree. :) I've only been reading for about a month now, and I find this group to be very reasonable and dedicated. Let's conclude with(*): one simply reaps what one sows here. Ask a straightforward question, and you will get a straightforward answer. Be smart, and you will get smart answers. Start off by irritating us, and... Well, from time to time, one of us will bite and irritate you back. That is: if you're lucky. ;) Mostly, irritating non-questions are simply ignored. What I find so peculiar in this case is that, on the one hand we are complimented on our website for giving the impression of 'FOP as a product' --All hail Web Maestro Clay, here--, which I take to be a good thing in Joe's eyes, unless we misunderstood each other there as well. On the other hand, it raises the question: Is our 'Getting Help' page really that hard to find, then? Here we have a user, who submits Bugzilla reports. OK, so he gets the usual treatment: a simple concise statement that a certain bug was fixed in the trunk in one case. A polite question to please attach a small FO that demonstrates the bug in the other. In yet a third there is even an intent to gather the information necessary to implement the missing feature. Oh well, I could go on for pages... As a tribute to Joe, I think I'm going to have a crack at implementing fo:inline-container very soon ;) Later Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Line breaking in tables
On Feb 21, 2007, at 20:03, Gilles Beaugeais wrote: Hi, I have downloaded the trunk version yesterday to check the correction for bug #41019. It works well now but another one appears. The "-" character seems not to be recognized as a legal break character (I use OFFO hyphenation files). In the following FO, the first cell is OK with the 0.93 version, KO with the trunk version the second cell is KO with the 0.93 version, OK with the trunk version This could be related to the UAX#14 Unicode-compliant linebreaking implementation, which was added to the trunk shortly after the 0.93 release. I'm hoping Manuel chimes in later, as he added this part and may already have an explanation at hand. In the meantime, I'll create a new Bugzilla entry, so we don't lose track of this. Stay tuned! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.93: Multi-page table Corrupted
On Feb 21, 2007, at 10:23, Chris Bowditch wrote: Andreas L Delmelle wrote: That's a little unfair. If the user wants help to analyse a problem then it's not unreasonable to expect them to provide the file in a convenient well formatted fashion. Sorry Chris, I was perhaps a bit too enthusiastic yesterday. It was not meant as reproach of any kind. It was more meant as a little laugh, and I certainly didn't question your skills --on the contrary. This just reminded me of a very skilled colleague of mine, who once reinvented the light-bulb as a matter of speaking. Of course, later on, the portion of code he wrote for that turned out to have quite a few bugs... Anyway, since this happened on fop-users@, I cc'ed the list as well, so everyone gets a clearer picture of what I meant by that remark. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] font-family="Arial Unicode MS" in rtf doesn't work
On Feb 20, 2007, at 22:16, József Németh wrote: Hey Joe, Let me start off by saying that I was very tempted to let your posting pass and not give you any more attention, but I just couldn't help myself, so here we go... I don't doubt that you, the FOP developers, are a group of good software professionals and a bunch of nice peaple. But the way you handle FOP as a product development project and relate to the user's of FOP is downright amateurish. And for me irritating, too. Apologies if it irritates you. That is certainly the opposite of what is intended. Yes, the style may be 'downright amateurish', as you call it, because Open Source --as I understand it-- is not governed by the same laws as your everyday professional commercial software development company. There is no such thing as a 'strict deadline' here. No contracts, no customers... Keep in mind that all FOP devs started out where you are right now: a FOP user. We too saw features missing, and tried to help out where we could, up to the point of diving into the code and implementing them ourselves. Let me take your answer: I wonder, how should I have known about the fix. It would have sufficed to read the first line of the message you got from Bugzilla, although I do realize now I forgot to paste the link to the revision that fixed the bug. Sorry. I specifically looked at the answers to my error report before I sent my reply and had not found any indication of it there. As a user I am equiped with the necessary environment to keep the softwares I am routinely using current. In this case using toroiseSVN I have checked out the complete FOP trunk just to find that, just as you suggest, if I want to use it I should build it myself. I didn't. (To state it slightly I wasn't in the right mood.) [In fact I had already installed a different workaround before I submitted the bug report.] OK, so that means that you can easily synchronize the fop.jar in your project with a scheduled Subversion checkout, followed by a build and deployment... What are you complaining about? On the FOP Download page I found this: "Fixme (jeremias) Reenable the link to the SVN snapshots once they are available." Now, what the heck it's supposed to mean?!. Can you tell me a valid reason why there are no daily (or at least weekly) snapshot builds of the trunk available at least on the main FOP server? Because someone needs to allocate time to set that up, and the demand is not nearly high enough to make this a pressing matter. I follow both fop-dev@ and fop-users@ almost on a daily basis, and I can't even remember how long ago it was that someone asked for these nightly builds. Probably those that thought they needed it, finally came upon a brilliant idea: "Why don't I do the build myself, and synchronize my local sandbox with the repository?" As I indicated, this is Open Source. We are not professionals when we are here. We all monitor this list, respond to postings (even when they're strictly speaking off-topic), take a shot at fixing long- standing but annoying bugs... Why? All /because we like to/ Whether, if or when new features get implemented, bugs fixed, releases done... this all depends on small human factors, such as a fop-dev working for a customer: if that customer absolutely needs features implemented, there you will suddenly see some things improved in a short time. Anyway, why should I be at the bleeding edge with FOP Trunk if I only need a small, safe and fully tested fix in the 0.93 branch that I can easily update if there is a new build available. Indeed, why should you even have a complete build? If you could download only the altered class, and replace that in your fop.jar... Again, schedule an 'svn up' of your local sandbox, rebuild and deploy. Why waste Apache's bandwidth on downloading much larger precompiled binaries? And finally knowing the history of FOP your mentioning of a new release is not too promising either. Please, do no take all this as an offence I have not meant it to be. Undoubtedly. You were just having a bit of fun, weren't you? ;P Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: font-family="Arial Unicode MS" in rtf doesn't work
On Feb 20, 2007, at 14:20, Jeff Vannest wrote:
Hi Jeff,
I've changed my opinion on this issue. The CSS spec on 'font-
family' gives
this example in section 5.2.2 of the Level 1 spec, 11-JAN-1999:
Font names containing whitespace should be quoted:
BODY { font-family: "new century schoolbook", serif }
To me, this cannot be labeled a "workaround" in FOP, it is
compliance with
the spec. Frankly, I've never seen single quotes within an
attribute, and I
would have bet money otherwise, but it's clear as can be in the CSS
spec.
Interesting info! Thanks for looking this up and sharing.
OTOH, now I'm wondering...
If you've never seen single quotes within an attribute, I bet you
haven't looked too closely, or you just missed them --or you've never
written stylesheets...? ;P
In XSLT these could turn out to appear far more often than you think:
I've even seen double quotes inside single quoted attributes, because
that is equally valid XML
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] font-family="Arial Unicode MS" in rtf doesn't work
On Feb 20, 2007, at 19:49, Jeff Vannest wrote:
Yes, we did! :)
It was fixed in FOP /Trunk/ (= fix will be in the next release)
Excellent! This means that my Altova StyleVision should work either
way with
the new rev.
Indeed.
Is there a way to know when the next rev will be released?
Unfortunately, we don't have a timeline for this :(
(read: we're all volunteers, so it depends on whether any of us have
the time and motivation)
OTOH, if you have Subversion and Ant at your disposal, then it is a
piece of cake to build, though...
1) checkout the trunk from the repository
2) navigate to FOP's root directory, and type 'ant' ('ant package' to
save some time and only build the fop.jar).
That's all there is to it.
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: 0.93: Multi-page table Corrupted
On Feb 20, 2007, at 16:52, Chris Bowditch wrote: paul_moloney wrote: Hi Pascal, An excerpt from the fo file showing just the table is here: http://utils.eurion.net/pastebin/index.php?13546 Unfortunately its difficult to use this FO file because paste bin has escaped all the quotes, so I would have to write a process to unescape them! Or do it by hand - ouch. Errm... So you would write a process? ;) How about opening it in some text editor, and doing a replace of all \" with "? Cheer - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [SPAM] font-family="Arial Unicode MS" in rtf doesn't work
On Feb 20, 2007, at 12:01, József Németh wrote: No, they didn't! Yes, we did! :) It was fixed in FOP /Trunk/ (= fix will be in the next release) 0.93 won't be patched, that much is true... If you really, really need this feature, then you're welcome to checkout the source w/ Subversion and build-it-yourself. Later, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using custom EntityResolver with fop 0.92
On Feb 18, 2007, at 10:19, Jeremias Maerki wrote: Arturo, I don't know how you use the EntityResolver in your code, but I'd propose to switch to URIResolver entirely. Seems like the best option indeed. Just FYI: As to an alternative, looking a bit closer into the API docs, an EntityResolver is supposed to be set on an org.xml.sax.XMLReader instance, through its setEntityResolver() method. The XMLReader here being the reader that will be used by Xalan to parse the stylesheet. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page Slop
On Feb 17, 2007, at 23:19, Jim Tivy wrote: Hi, We tried to ship a project with .93. We almost made it, however something we coined as "page slop" stopped us so we went back to FOP.20 and it looks like we will ship with FOP .20. Were were using a trick of sizing even pages as zero to avoid rendering on even pages because the customer wanted a book with every left page blank. IIC, then it should be unnecessary to size a page to zero to avoid rendering on it... see: http://xmlgraphics.apache.org/fop/fo.html#fo-blank-pages Can you try out and see if the error disappears if you follow the cited example? If not, then don't hesitate to report back, and we'll have a closer look. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem using custom EntityResolver with fop 0.92
On Feb 18, 2007, at 02:37, Arturo Perez wrote:
In article <[EMAIL PROTECTED]>,
Jeremias Maerki <[EMAIL PROTECTED]> wrote:
http://xmlgraphics.apache.org/fop/0.93/embedding.html#fop-factory
I had already been setting the URIResolver and that doesn't seem to
work either. My document calls would look like
document('urn:hayesinc:report:id')
A call to document() is resolved during XSLT stage. Setting FOP's
URIResolver will do you little good here, unfortunately.
Xalan indeed allows an EntityResolver to be set from the command-
line, but I didn't immediately find a reference on their site as to
how this can be set if JAXP is used...
Perhaps this is a question better suited for [EMAIL PROTECTED]
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: odd error from 0.93
On Feb 17, 2007, at 00:06, Arturo Perez wrote: Hi, Just tried 0.93. I have been using 0.92beta. I get this error and my PDF looks horrible. ERROR org.apache.fop.layoutmgr.AbstractBaseLayoutManager- Cannot find LM to handle given FO for LengthBase. What did I do wrong? Not sure if you did anything wrong. Is it possible to post the FO that produces this error, or make it otherwise available, so that we can track it down further? Thanks, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Dynamic Running Heads
On Feb 15, 2007, at 04:54, Jeff Sese wrote: Hi, I tested some variations of the position of the markers and the properties i used for the retrieve-marker, i finally got my desired output. Here's my fo code for reference: Basically, I placed a marker that can be read when i specified a page-boundary of page-sequence. These were place as the first child of the parent block of the article and the first child of the last block of the article. Then I placed a marker for the separator and the title of the current article in the first block child of the main block, so that it can only be read by a page-boundary of page (I hope my understanding of the page-boundary property was correct). Yep, seems about right. Just FYI, to see if you understood it correctly, I'll try to explain a bit more... The retrieve-boundary property has an initial value of "page- sequence" (= specifying that value is the same as omitting the entire property specification). That value means that *only* markers within the same page-sequence as the retrieve-marker are qualified for retrieval. Setting this to "page" means that any marker that is retrieved, MUST be on the containing page (~ same page as the retrieve-marker). So, this property only makes a difference if a given page (or page- sequence) does /not/ contain a marker of the specified marker-class- name: * with a retrieve-boundary of "document", even a marker from a page in a preceding page-sequence may be retrieved * with a retrieve-boundary of "page-sequence", a marker from a preceding page within the same page-sequence may be retrieved * with a retrieve-boundary of "page", there would be no marker to retrieve Note that markers on pages /following/ the containing page are / never/ qualified for retrieval, whether or not they're in the same page-sequence. The retrieve-position property, OTOH, indicates a preference for which marker will be retrieved if there's more than one that qualifies based on the retrieve-boundary. In your example: 1) the first page will contain only one marker, namely one of marker- class-name="heading-in-page-sequence", so that one will be retrieved. The other two retrieve-markers retrieve nothing. Due to retrieve- boundary="page", only markers on the containing page qualify. 2) the second page contains four markers: * two of marker-class-name="heading-in-page-sequence", so the one that satisfies the preference "first-starting-within-page" is retrieved * one of marker-class-name="heading-separator", so that one is retrieved * one of marker-class-name="heading", so that one is retrieved 3) the third page contains four markers: analogous to the second 4) the fourth page contains no markers, so only retrieve-markers with a retrieve-boundary other than "page" will actually retrieve anything Only thing to take care of: in this case, all works nicely, since you control the page-breaks (break-after="page"). Using implicit, formatter-generated page-breaks would make things slightly more difficult. If you remove the first explicit break-after, and the formatter would decide to break precisely between the first and second section, your output could turn out to look like: page 1: first heading ... page 2: second heading - second heading ... Anyway, thanks for sharing your solution with the list! Always nice to have examples in the archives somewhere. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: XSL - NewLine
On Feb 14, 2007, at 01:03, Daniel Noll wrote: (We do our own breaking by substituting elements into the appropriate places before running through FOP, although it sounds like this attribute to make linebreaks significant may be cleaner.) FWIW: I've always considered the insertion of empty blocks more like a FO-hack, a way to trick the processor. Very useful trick, in some cases though. I've seen especially creative use of it in combination with conditional negative space-before or space-after (a Norman Walsh/ Docbook idea, IIRC) OTOH, if you /can/ do without them --i.e. there are no properties specified on the block, so it's only used to emulate HTML's -- then it's always better not to use them. Reason is that the Java object corresponding to a fo:block is fairly large, even for empty blocks. The less of them, the better for the memory footprint. On top of that, the XSL transform should become much, much simpler, as it becomes only a matter of adding an attribute. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 13, 2007, at 15:06, Chris Bowditch wrote: Andreas L Delmelle wrote: The Rec in all its glory! :) I wonder what this means for tables that don't have a block- container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... In the case where fo:table is a child of fo:block or fo:flow isn't the nearest ancestor reference area the fo:region-body? Whose bpd will be known. Yes, but that's precisely what makes it all so fuzzy... The Recommendation does not refer to the 'nearest ancestor reference area'. Why? I have no idea. In any case, there's only stuff like: - the closest area ancestor generated by a block-level FO - the closest ancestor block-area - the first area in the sequence of areas generated by... All in all, I'd say it boils down to: don't use percentages for table or table-row height (or table-cell, for that matter). Peculiar is that the behavior for percentages on fixed-positioned block-containers is explicitly defined in terms of references to the nearest ancestor viewport area. OTOH, if I remember correctly, block- containers aren't supposed to appear broken over multiple pages (if the content is too large to fit, treat the excess content according to the overflow property). Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 12, 2007, at 23:34, Jeremias Maerki wrote: I'd very much like to agree with your solution/interpretation, but the nit in me feels compelled to ask: "100% of what?" XSL 1.1 says for percentages in block-progression-dimension: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block-progression-dimension), the value is interpreted as "auto". But that's a weird statement IMO. If the table's parent is a block, the block's height depends on the content's size. Circular dependency. It would make more sense to say: "...of the closest anscestor that is a reference area..." Shrug. The Rec in all its glory! :) I wonder what this means for tables that don't have a block-container parent. Note that, since a block's b-p-d can't be specified, that leaves only block-container as a possible and reliable base 'block- level FO that generates the closest area ancestor'. If there is no such block-container, the behavior of percentages would again be undefined. If there's only a parent block, then this would create a circular dependency, as you point out... Besides that, mind that the native XSL property 'block-progression- dimension' does not directly apply to table or table-row. That is, specifying block-progression-dimension="100%" on a table or table-row would (and should) not have any effect. Only the CSS-XSL hybrids 'height/min-height/max-height' apply to them. Now, these being CSS properties in origin, I think that either: a) the first rule in 7.3 applies "1. For properties defined in CSS2 referring to the "containing block", the content-rectangle of the closest ancestor block-area that is not a line-area is used." or b), the height property being mapped to XSL's block-progression- dimension (or inline-progression-dimension), the fourth rule applies "4. If the formatting object generating the identified area generates a sequence of such areas, the first area is used for the conversion." I'd put my money on a). Moreover, this is most likely why XSL explicitly refers to CSS in its definition of height, since percentage heights for tables and table-rows in CSS are /not/ defined in terms of a containing block --they are undefined altogether :( b) seems to make matters even worse. It would again lead to a circular dependency for some tables that are direct descendants of the flow, since that 'first area' could correspond to the first area generated by the table itself... If not, then it could also be an area generated by a completely unrelated block (=first block in the flow) preceding the table...? Big Shrug indeed! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Need help on PDF generation using XSL-FO
On Feb 9, 2007, at 19:02, Nelson, Dean wrote: I have just tried this with my own project here - just disabling the print. It appears that the print disabling is tied to the security. Is there a way to NOT put in password and it disable the print? Right now if you disable the print, it generates a random password and lock the file. I even tried ' -noprint -u "" ' which I thought would be a null password. FOP 0.93 puked with this (a zero length string). Any ideas? That's because the PDF encryption algorithm at least needs an owner password. A user password can be safely omitted. Setting the owner password does not lock the file for viewing. Try: -noprint -o $owner_pass$ See also: http://xmlgraphics.apache.org/fop/0.93/ pdfencryption.html#Usage+%28command+line%29 HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 9, 2007, at 18:43, Andreas L Delmelle wrote: On Feb 9, 2007, at 18:22, Jeremias Maerki wrote: An extension isn't necessary. This can be expressed with normal FO means: Specify block-progression-dimension.optimum="100%" and block-progression-dimension.minimum="0pt" on the last table-row. Or, to avoid the CSS 'height' pitfall, how about: What does the percentage refer to in this case? Is space-before/-after needed to complete the picture? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 9, 2007, at 18:22, Jeremias Maerki wrote: An extension isn't necessary. This can be expressed with normal FO means: Specify block-progression-dimension.optimum="100%" and block-progression-dimension.minimum="0pt" on the last table-row. Hmm... but that property is not directly applicable to a table-row, IIRC. Only 'height' is applicable to tables or table-rows. The fun then truly begins when you read the Rec's definition of the 'height' property... 8) "For a discussion of the "height" property in tables see: http:// www.w3.org/TR/REC-CSS2/tables.html" OK, and so we browse through the CSS Rec(*), and there it says: "CSS2 does not define what percentage values of 'height' refer to when specified for table rows and row groups." (*) http://www.w3.org/TR/REC-CSS2/tables.html#height-layout I'd very much like to agree with your solution/interpretation, but the nit in me feels compelled to ask: "100% of what?" What do other processors do in that case? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Table troubles
On Feb 9, 2007, at 17:24, Vincenzo Mazzeo wrote: Chris Bowditch ha scritto: Vincenzo Mazzeo wrote: Hi all, I have upgraded fop from 0.25 to 0.93 and I have some troubles with tables. 1. On page break table doesn't have the bottom border even if I set it. This is because of border conditionality. Table borders are not painted at the start/end of a reference area by default. You have to add property table-border.conditionality="retain" I added the table-border.conditionality="retain" property to the but it says "Error(4/2343): fo:table, Invalid property name 'table-border.conditionality". How can I use this property? Chris was being a bit too fast, I guess... should be: border-after-width.conditionality="retain" Mind that you cannot use the border or border-width shorthands. Because the shorthands don't have a .conditionality component, they will set it to its initial value of "discard", and this can not be overridden by specifying it explicitly. So, you'll need to specify border-[side]-width.length and border- [side]-width.conditionality for each side separately. 2. On the last page, if there isn't enough data, table doesn't fill all available space even if I set the 'height' attribute to 100%. height attribute has no affect on a table. IIUC, then there is no way to stretch a table so that it fills an entire page using XSL- FO 1.1. I think Chris is right here... maybe an idea for an extension element of some sort? fox:table-page-filler, which, if present would always appear after the last row of a table, and triggers the creation of a row during layout, with one cell(box) of height equal to the remaining BPD on the last page/column spanned by the table... Moreover I have some cells with the 'display-align' attribute set to 'after'. Because of I can't use the 'keep-together' attribute on rows, it happens that if a row is shared on two pages the 'display-align' doesn't work and the value appears on the former page instead of the latter. This seems like a bug. Can you please post the FO, or even better, open an entry in Bugzilla and store the FO as an attachment there? HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Overflow in block-level elements
On Feb 9, 2007, at 00:11, Roger Kovack1 wrote: In short, overflow is allowed in fo:block-container but not in fo:block. Not exactly: overflow /is applicable to/ block-container, but not to block. However formatting properties states: 7.20.2 "overflow" ... This property specifies whether the content of a block-level element is clipped when it overflows the element's box (which is acting as a containing block for the content). Values have the following meanings:... Does "block-level element" refer to fo:block? Strictly speaking, yes, but since the property does not apply to fo:block... Why? Well, because a block has no width/height, so there is no possibility of overflow in either direction. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bad pdf document with embedded Times New Roman font
On Feb 8, 2007, at 12:31, Adam Skowronski wrote: I included Times New Roman into configuration as follows url="times.ttf"> ^^^ Just noticed: maybe this weirdness is caused by this, in combination with the below font-family. Change this to "Times Roman", ... In XML-FO I have: ... and this to "'Times Roman', serif" (not necessary with FOP Trunk; only with 0.93) Any changes? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bad pdf document with embedded Times New Roman font
On Feb 8, 2007, at 12:31, Adam Skowronski wrote: I tried to create PDF document and embed Times New roman font (because I need some character from ISO-8859-2 codepage). FOP executes without errors, pdf file is created, but acrobat reader (Windows or Linux version) crashes with message: There was an error processing a page. There was a problem reading this document (135). xpdf from Linux displays document correctly. If I remove from configuration this particular font (but still embed others), acroread can read document. Do anyone know solution or maybe right questions to ask? Hmm. Not sure. Have you tried different versions of Adobe Reader? Any other viewers you tried? (GhostScript?) Since you're multi-platforming, maybe the question of origin of the font (Windows/Linux) is also relevant? On what platform does FOP run? On what platform were the font files generated? Just guessing... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Again: external-graphic and scaling
On Feb 8, 2007, at 19:45, Kai Mütz wrote: Hi, I do not really understand the scaling of external images. I have an Area of 220mm (height) and 170mm (width) where I can include graphics. Thus I write something like: Isn't it (theoretically) right that if I specify content-height and content-width the image should be scaled and thus could be distorted. Only if you would specify scaling="non-uniform". If not, then FOP defaults to preserving the aspect ratio, as is mandated by the Recommendation. See: http://www.w3.org/TR/xsl/#scaling But if I include a graphic which has landscape orientation FOP scales it to 170mm width but doesn't scale the height to 220mm. The height is correct relativ to the width. This is perfect for me but doesn't this conflict with theory? Nope. :) HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: SV: Rescaling images to 300dpi
On Feb 8, 2007, at 08:38, Uwe Kubosch wrote: Hi, On Wed, 2007-02-07 at 15:51 +0100, Jeremias Maerki wrote: The attached FO file shows how to do this. Actually, Batik was so clever I had to trick it into resampling using a dummy feColorMatrix filter which does not modify the image. Without the filter the image doesn't get down-sampled. Thanks! I am working on getting this to work. I think I have solved the Xalan/Serializer endorsed jar setup, but now I get the an error: SEVERE: svg graphic could not be built: Can't find bundle for base name org.apache.fop.svg.resources.Messages, locale en_US IIC, then this was caused by Batik, and should be solved if you use the SVN Trunk version of Batik (see Bugzilla 41440) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: font-family="Arial Unicode MS" in rtf doesn't work
On Feb 7, 2007, at 20:25, Dominic Marcotte wrote: Thanks Jeremias it's work! If we want to use font name with whitespaces like "Arial Unicode MS", we must put it in quotes. As Daniel pointed out: 'should', not 'must'. Anyway, should work in FOP Trunk now w/o the quotes as well. If I understand well, I think we can even do this font-family="'Arial Unicode MS', 'Lucida Sans Unicode', sans-serif" Yep, but AFAIK, currently FOP only uses the first one in the list (and does not use the others as fallbacks, yet) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.NoClassDefFoundError
On Feb 6, 2007, at 19:04, Jeanna Geier wrote: In my project I've included the fop-0.20.5 & Batik_1.6 Libraries. Errmm, sorry, but that's a big NO-NO :) FOP 0.20.5 is not compatible with Batik 1.6. You'll have to use the Batik version shipped with FOP 0.20.5, or --better-- you can try FOP 0.93, which should work nicely with Batik 1.6. That said, I'm not sure whether this is actually the cause of the error... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: font-family="Arial Unicode MS" in rtf doesn't work
On Feb 6, 2007, at 07:22, Andreas L Delmelle wrote: All that needs to be done, IIC, is to override Maker.make (PropertyList, String, FObj) in FontFamilyProperty. Note that this is about the only property that can contain spaces, where these spaces do /not/ signify boundaries between multiple values, as a list of font-families will be separated by commas. Should be simple enough for someone who wants to get his feet wet... Might even take it on myself, if no one beats me to it. FWIW: already did this locally (incl. normalization of sequences of more than one space). It all boils down to an added 35-40 lines of code... As soon as I'm 100% sure that the testcases that now fail, are failing as a result of the previous patch being applied, I'll commit the changes to the Trunk. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: font-family="Arial Unicode MS" in rtf doesn't work
On Feb 6, 2007, at 03:59, Daniel Noll wrote: Jeff Vannest wrote: Jeremias Maerki wrote: Try font-family="'Arial Unicode MS'" http://www.w3.org/TR/xsl11/#font-family says: "Font family names containing whitespace should be quoted." font-family="Arial Unicode MS" is already quoted, right? To my knowledge, all attribute values must be quoted in order to meet most SGML-based specifications. I am not familiar with any cases where double- quoting values should be recommended. The reason is that the CSS specification (which XSL-FO happens to borrow from in this instance) recommends the quotes. To make matters more interesting, the spec also says that a font family like "Arial Unicode MS" (no quotes, and note the double spaces) should also resolve back to "Arial Unicode MS" (single spaces). FOP doesn't do any of this of course, it splits at the spaces, which is a spec violation the way I see it. If anyone feels like fixing it, the problem is roughly: the standard PropertyParser parses the property "Arial Unicode MS" as a ListProperty containing three StringProperties All that needs to be done, IIC, is to override Maker.make (PropertyList, String, FObj) in FontFamilyProperty. Note that this is about the only property that can contain spaces, where these spaces do /not/ signify boundaries between multiple values, as a list of font-families will be separated by commas. Should be simple enough for someone who wants to get his feet wet... Might even take it on myself, if no one beats me to it. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: block-container and margin/padding properties
On Feb 3, 2007, at 13:26, paul wrote: In short: margins on the left and right side get duplicated (see diagrams below). Just to be sure, I'd check if it is not indent-inheritance you're bitten by... See: http://wiki.apache.org/xmlgraphics-fop/IndentInheritance HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: display-align="justify"
On Feb 2, 2007, at 19:07, Luis Ferro wrote: When doing the pagination of a large block of text, with columns, the text is if the keepers/orfan/widows are defined acordingly, passed to the next column leaving some space behind in the previous page. The visual effect of the full pages isn't great, specially if you have for instance 3 columns per page. What happens is that the text seams to ondulate in the bottom (diferent kinds of white space in the 6 columns that will be in side by side). IIRC, in the code there are references to a value of "distribute" being allowed for display-align (as an extension to the XSL Rec.) I haven't tried whether its implementation is complete, but maybe it will do the trick here...? HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Cell overflow: word too large
On Feb 1, 2007, at 12:14, Florent Georges wrote: I just saw a strange overflow in a table cell. The cell contains two words, and the second word seems to being not put on a new line if it is larger than the column width. Here is a use case. The second cell is a little bit less large, then both words are kept on a single line, while in the first cell the second word goes on a new line: Is there a way to force breaking line even if the word is too large for the cell? The known workaround is to insert zero-width breaking spaces in the word at certain points. Activating hyphenation should also do the trick, IIC. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with fop-0.20.5 and batik-all-1.6.
On Jan 29, 2007, at 18:34, Iris Soto wrote: I try switching to FOP 0.93 but I got a hassle with the serializer that cocoon have because fop-0.93 doesn't include the class MessageHandler that cocoon's serializer needs. Ah, yes, that's still on the todo-list. FWIW: I've already been thinking of this myself the past weeks, and since it didn't look too complex, I've already taken a few steps locally in resurrecting the 0.20.5 MessageHandler and MessageListener. Still wondering what to do with all the trace- and debug-messages, but once I get that sorted out, it shouldn't be too long before this becomes available in the trunk. Something to look forward to ;) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Using style sheets with FOP
On Jan 29, 2007, at 12:17, Clarke, Thomas (UK) wrote: I'm new to the FOP scene so I apologise if this is in anyway a stupid question. Is there a way already implemented of referencing a CSS file to supply the style values for my xsl-fo files? I have a very large number of them and I'm looking for a way to shrink them down a bit. So far it looks like a no but I thought I'd check before I tried modifying the code. This is indeed not directly available... What you could try, OTOH, is http://sourceforge.net/projects/css2xslfo that's designed especially for converting HTML+CSS into XSL-FO. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problems with fop-0.20.5 and batik-all-1.6.
On Jan 25, 2007, at 17:00, Iris Soto wrote: Hi, I am using jfreechart-0.9.20 to generate svg graphics this require batik-all1.6 to work. I'm also using fop-0.20.5 with batik-all-1.6 but when I render to pdf document the image doesn't appear. In the mailing list I read that fop-0.20.5 is not compatible with batik-all-1.6, that is necessary to use the fop's batik version, so when I try to drop dependency from my pom.xml the batik-all-1.6 the jfreechart's class dont work. If at all possible, I'd recommend switching to FOP 0.93. This should resolve your hassle, as it is compatible with Batik 1.6. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 25, 2007, at 05:28, Daniel Noll wrote: However, it seems like almost the whole stack trace could be avoided if this call cached its results somehow: org.apache.fop.fonts.Font.getCharWidth(Font.java:231) (an array of 65536 elements would be enough, but wouldn't be terribly efficient in terms of memory.) So the solution may lie in between: make the call once per *used* character. It's highly unlikely that a document will contain all 64K characters anyway... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 24, 2007, at 04:30, Daniel Noll wrote: Andreas L Delmelle wrote: If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) FWIW we've noticed a similar issue with speed here, although in our case we were comparing the speed of 0.20.5 to 0.93 so we hadn't narrowed it down to being the very latest version. The only thing peculiar about our own FO files is that they are relatively heavy on table usage. and often have large images (>1024px) which are scaled down to a small size (~120px) for thumbnails. Important question that hasn't been asked in this particular thread: Does this occur only when using the AWT renderer, or is there a similar drop in processing speed when rendering to PDF or PS? If it happens only with AWT, then the used JVM (AWT implementation) could be a key factor... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bad FOP configurations
On Jan 23, 2007, at 15:06, Adrian Cumiskey wrote: Hi Adrian, I am investigating some bugs with bad FOP configurations.. http://issues.apache.org/bugzilla/show_bug.cgi?id=40120 http://issues.apache.org/bugzilla/show_bug.cgi?id=40288 In your opinion, on initialization if the FopFactory and FOUserAgent discover that they have bad configurations (e.g. malformed (base) urls, urls that reference non-existent content), should they :- a) Catch exceptions (ConfigurationException) and log SEVERE errors and silently continue. I personally prefer this, but would also agree with an intermediate solution, where the user can flip a switch on the FopFactory or the FOUserAgent to have them propagate the exception if it occurs... (analogous to strict or relaxed validation). Just my 2 cents... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: awt performance 0.93 vs 0.92beta
On Jan 23, 2007, at 10:34, paul wrote: I'll be happy to do some investigating, but I'm also a bit pressed for time at the moment(should be doing work :). It seems to me 1.5 is still installed on the system. does someone happen to know a quick way to change between different jre's, for example with path-variables (win xp)? I don't have time for lenghty download & de-/reinstallation procedures. IIC, all that needs to be done is: a) make sure that the path to the 1.5 binary appears before that to 1.6. When you subsequently execute 'java', the 1.5 executable will be used... b) the environment variable JAVA_HOME should point to the 1.5 folder instead of 1.6 If it turns out that 0.93 is slower on any JVM, then if you can, please send us the FO, so we can investigate what might be causing this. Is there anything special about the FO-file? (i.e. lots of markers, images, tables, particular FO-constructs...) Thanks, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OutputStream and renderers where it doesn't make sense.
On Jan 18, 2007, at 02:23, Daniel Noll wrote: Is this API going to be improved at some point so that subclasses don't need to implement hacks such as these? Perhaps some kind of Destination object which could contain an OutputStream, multiple OutputStreams, or even just a marker saying that no, there is no destination stream. Immediate plans? None that I'm aware of... You're welcome to submit a patch proposal if you want to speed things up, though. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Usage of setRendererOverride()
On Jan 18, 2007, at 00:20, Daniel Noll wrote: The FOUserAgent passed in and the one obtained from fop.getUserAgent () are the same object, I didn't actually create a new one. Ouch! Completely missed that... I read fopFactory.getUserAgent()... I'll see what we can do about that. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Usage of setRendererOverride()
On Jan 18, 2007, at 00:06, Daniel Noll wrote: I guess if we're not supposed to set fields on the user agent after the Fop instance is created, the API should prevent it by either (a) throwing an exception when we try to change it, or (b) not giving access to the object in the first place. Not quite. The second one you created, could be used for another Fop instance. It is perfectly legal to instantiate a useragent after the Fop instance is created. Only, don't expect it to have any consequences... Each Fop instance is linked to a FOUserAgent. The factory doesn't keep track of all the Fops and FOUserAgents it creates. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Usage of setRendererOverride()
On Jan 17, 2007, at 23:48, Daniel Noll wrote: Hi, I have a situation where I need to use two different renderers for the same MIME type. I thought I might be able to use the renderer override for this. So what I have so far is... Fop fop = fopFactory.newFop(mimeType, outputStream); fop.getUserAgent().setRendererOverride(new MyRenderer()); ... The FOUseragent should be instantiated and configured before the Fop instance. Also, getUserAgent() returns 'a' useragent. There is no such thing as 'the' useragent. So try: FOUserAgent ua = fopFactory.getUserAgent(); ua.setRendererOverride(...); Fop fop = fopFactory.newFop(mimetype, ua, outputStrem); ... HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IndexOutOfBoundsException in ColumnSetup.getXOffset()
On Jan 16, 2007, at 11:16, Michael Bruns wrote: Thanks Andreas, that hint finally showed me my mistake :-) You were right, I accidentally created a row with too many columns. Anyway, I still think throwing an exception isn't the desired behaviour, is it? Correct. This could/should be caught very early. Note that in fixed table-layout, the example you posted would have to lead to all but the first cells being dropped, unless the cell in the first row has a colspan of 3. Implicit columns are derived from the first row only. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.IndexOutOfBoundsException in ColumnSetup.getXOffset()
On Jan 15, 2007, at 17:15, Michael Bruns wrote: Hi, Hmmm...I would really like to provide you some examples, but I couldn't figure out *what* exactly causes the crashes, yet. My best guess is that it's a table with too many cells in one row (more than there are columns)... Do your tables use implicit or explicit columns and/or column-widths? Do you use rows or do you specify 'starts-/ends-row' on the cells? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Problem
On Jan 10, 2007, at 18:48, pwillsey wrote: I ran the transformation from both computers on the command line, the FO file was identical and did not contain a fo:simple-page-master element with more then one fo:region-body. Did you do a visual check, or a more reliable XPath check? Something like: /*/*/*[local-name(.)='simple-page-master'][count(*[local-name(.) ='region-body']) > 1] HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Memory issues - please help
On Jan 4, 2007, at 21:34, Cliff wrote: Hi Cliff, I'm facing FOP memory issues that I fought with a long time ago. I lost the battle back then and had to resort to some ugly manual page breaking logic and now I'm wondering the current status of the FOP project. My immediate question is: Do either FOP 0.20.5 or FOP Trunk address/improve on the memory issue regarding auto page breaks? I remember you... It was something like a second XSLT pass over the FO input, right? Since that time, some memory leaks have been fixed, so it could already help you. OTOH, the issue concerning large page-sequences has not yet been addressed, unfortunately. Problem still remains at this point: FOP needs to build an internal representation of the entire page-sequence before it can start any formatting. (= due to the current architecture: the whole layout-loop is triggered by AreaTreeHandler.endPageSequence()). I've some ideas on how to improve the situation, but they're not trivial adjustments, so I can't say when or even if these ideas will make it into the codebase... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
On Dec 19, 2006, at 19:56, Peter wrote: When working on the patch I certainly can not remember coming anywhere close to code that could have an influence on how png's get into the pdf. I was also a bit puzzled, since in the patch there are no explicit references to anything png-related (IIC, png-related stuff is already put in Commons for that matter, so it couldn't have been touched directly by the patch) OTOH, this was the only significant change to the codebase between 13.11 and now, so one can reasonably assume that the cause is in there somewhere... I'd expect something which has an impact on the interaction with the commons-lib? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: PNG transparency renders as black - urgent
On Dec 19, 2006, at 19:04, Martin Zak wrote: ...just to point out that I used the same image with the FOP binary from November 13th, and the result was *ok*. What changed between these versions??? AFAICT from the fop-commits archive: exactly on that day, support was added for rgb-icc() and a proprietary cmyk() function... As to how this influences the rendering of PNGs, I'm unfortunately at a loss :/ Hopefully Jeremias (who applied the patch) or Peter (the patch's author) have an idea on this, and chime in later on. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Question to Repository
On Dec 13, 2006, at 19:27, Kris Wolff wrote: I reduild from the repository and build a clean setup, while compailing i notice the fonts folder is empty: /VOL2/src/java/org/apache/fop/fonts/FontSetup.java:22: package org.apache.fop.fonts.base14 does not exist import org.apache.fop.fonts.base14.Helvetica; How do you compaile? What is missing? To build/compile FOP from the sources, it should suffice to have Ant available, and in the root folder of FOP, simply type 'ant' + . If the above class is missing, this means that the 'codegen' build target hasn't been executed. The Base14 font classes are generated via XML+XSLT at build time. HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Troubleshooting "No meaningful layout" errors
On Dec 13, 2006, at 19:18, Paul Moloney wrote: Hi, A particular user manual is giving a "No meaningful layout" error. [ERROR] file:/home/pmoloney/svn/pplus/docs/manuals/target/fo/ care_applications_g uide/care_applications_guide.fo:88:696 No meaningful layout in block after many attempts. Infinite loop is assumed. Processing halted. Googling about this error shows some people advising to give Fop more memory. I tried up to 1024MB and 2048MB (the machine has 2 gigs of memory) with no luck. Errm... What gave you that idea? 8) Seriously: the error is referring to what you describe below Others have said it's a result of using tables or graphics that are "too long". Any idea of some context for this? The graphic in the section that the fo error seems to related to has a graphic of 11 (w) x 15 (h) cm, which seems fine to fit on an A4 page. Removing it didn't change anything. Does your document contain tables? With explicit keeps? AFAIR from 0.20.5, it could be that this is a result from table-rows that FOP tries to keep together with the previous and next rows, and the whole table would not fit on an A4 page... That said: if you can, I'd recommend upgrading to the Trunk code. User reports indicate that the Trunk is currently stable enough to be used in production environments. On top of that, it offers more supported XSL-FO features. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: bother with secure options
On Dec 8, 2006, at 00:21, paul caffrey wrote: I'm having some difficulty getting the secure option to work in my fop installation. I'm getting the message: "Cannot find any provider supporting RC4" I was wondering if perhaps this could be due to the fop installation (from before I arrived on the project) was not compiled with encryption support? Nope. It means that, at runtime, the JCE can't find a provider supporting RC4. See: http://xmlgraphics.apache.org/fop/0.92/ pdfencryption.html#install_crypto I think, if was compiled w/o crypto support, then with FOP Trunk, you would receive an error message like: "PDF encryption requested but it is not available. Please make sure MD5 and RC4 algorithms are available." Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOPException: No element found for Namespace URI:
On Dec 8, 2006, at 13:36, <[EMAIL PROTECTED]> [EMAIL PROTECTED]> wrote: On Wednesday this week I downloaded the actual files from FOP Trunk and compiled FOP using ANT. In FO-File on line 2 and at character 28782 I found this: ^ = character 28782 This extension hasn't been ported to the Trunk yet. (and fox:outline has been replaced by the equivalent XSL 1.1 feature, fo:bookmark) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop with Java 1.5?
On Dec 7, 2006, at 19:05, Brad Smith wrote: I have seen references on this list to people using fop in conjunction with java 1.5. However, fop breaks on my system that has it. ... Would compiling from source on a java 1.5 system make a difference, then? Not sure. I'd expect 1.4 compiled code to run w/o problems on 1.5... What is the exact problem you encounter? Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: specify values for attribute once and then refer to it.
On Dec 3, 2006, at 19:08, Potje rode kool wrote: Hi, Is it posible to specify on one place some values for attributes and then refer to that, a bit like its done with css, where you create a class and refer to it with the class attribute in the html element? Google around for xsl:attribute-set / use-attribute-sets HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Copyfitting
On Dec 1, 2006, at 18:02, Peter wrote: Hi Peter, I am wondering whether anyone has any experience in the area of copyfitting and xsl-fo. To clarify - assume that I want to format a piece of text in an area (page if you want) with given dimensions. Now, in stead of getting an overflow I would like xsl-fo (fop that is :-)) to change a number of parameters (like font size etc) to try and make the text fit in the available region. Would this (or could this made to) match with xsl-fo/fop? This type of question has been raised a number of times, and there does not seem to be a straightforward solution in pure XSL-FO... Depending on the complexity of layout, you may be able to achieve a similar effect by mimicking it in SVG, then insert the graphic as an fo:external-graphic or fo:instream-foreign-object with content-width and -height set to scale-to-fit. Only tough nut to crack would be that the image would, in this case, also be stretched if it is too small. That's where XSL-FO 1.1 scale- down-to-fit would be of great help. It's not much to go on, just my 2 cents... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Prevent Linebreaks in Table Cells
On Nov 28, 2006, at 15:06, [EMAIL PROTECTED] wrote: Hi, I have Content that overflows a Table Cell but I dont want that FOP breaks the Text in multiple Lines the Text should simply cut at the end of the Cell I have read much Dokumentation but I can't find a working Example for FOP 0.92 Can someone give me some Tips ? Have you already tried using 'wrap-option="no-wrap"' on either the table-cell or the block in question? IIC, this should already be supported in 0.92b HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: need help with templating issues...
On Nov 9, 2006, at 16:13, Ricardo Soe-Agnie wrote: Hi, I want to transform the following XML to PDF: I see you're a first-time poster, but to us all it seems like the zillionth time: Such questions actually do not belong on this list. Mulberry's XSLT list is much, much better suited. This list is meant for problems/ questions wrt using Apache FOP to transform FO into PDF. The XSL transform is a separate step, which has very little to do with FOP itself... Please try to keep that in mind for the future. Thanks! On that note, you'll also notice, if you browse the archives, that many of us can't resist to offer you an answer anyway, so here we go. For the nodes for which there is no explicit matching template defined, the default template is invoked, which ultimately comes down to: and thus for their text-node children: Two possible solutions: - either define an empty template for the nodes you don't want to see processed, like so - or apply-templates to only those nodes you do want to see appear in the result, so replace this one here ... with HTH! Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: fop doesn't like imagemagick'd pngs?
On Nov 3, 2006, at 23:30, Brad Smith wrote: Hi, Does anyone have any insight into what's going on here? I'm on FC6 using fop-0.91beta-2 and ImageMagick-6.2.8.0 if that's relevant. Well, 0.91beta is a tad outdated. I'd suggest at least checking out 0.92beta to see if that solves anything. If it doesn't, and you're at liberty to build FOP from the sources, the current SVN trunk fixes a few known bugs in the image handling code. Maybe this behaviour has already been corrected in the meantime... If the problem persists in the latest trunk version, please feel free to make an entry in Bugzilla, so we don't forget to check this out. Thanks, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.92 : OutOfMemoryError
On Oct 31, 2006, at 09:28, Debasish Jana wrote: Hi, Possibly that's why, I see that memory is not being released to the same level since when the rendering was started. Is there any API that can force memory cleanup after the rendering is done - success or failure? None that I know of, but that should not be necessary. True, 0.92 still contains some leaks/bugs in this respect, but the new API was designed in such a way that (theoretically) only the objects that qualify for re-use will remain referenced, so subsequent rendering runs benefit from not having to recreate them. I removed all forward references, and my page-sequence handles very few pages now, even then I face OutOfMemoryError, wondering what needs to be done to get it through with high volume of data. Now, I have no forward page-citations, no image, just a flat table with huge number of rows, but I split that to multiple page-sequences Here's the fo sample (I have cut it short to let you feel the usage, in case I am doing wrong)... Upgrade to the trunk. Definitely should help a great deal in your case. FOP 0.92 did not yet clear the references to the FOs after finishing a page-sequence, and that seems to be exactly the cause of your OOMErrors... Other than that, there's not much you can do, I'm afraid. Also, where from I can get the latest FOP jar (binary) replacing my fop-0.92b.jar which I use now. Sorry, AFAIK, still no binaries served from the Trunk. OTOH, very easy to build from scratch if you can check out the source code with Subversion. Let us know if you need help there. If you can't build FOP Trunk from the sources, I guess the only thing you can do FTM is wait until 0.93 is released... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 0.92 : OutOfMemoryError
On Oct 31, 2006, at 08:01, Debasish Jana wrote:
Hi,
We are using FOP 0.92 for converting a XSL:FO document to PDF/RTF
etc. Since
there is a table with many rows with data coming from a huge db
table, it is
causing OutOfMemoryError.
We split up the document with single fo:root but multiple page-
sequences
with each page-sequence having a finite number of fo components,
still we
come up with OutOfMemoryError, and also, after the OutOfMemoryError
comes,
the amount of free memory does not move up to the level where the
transformation is started.
Well, 0.92 still contained a rather serious memory-leak in the FO
tree. Even if you split up the document in multiple page-sequences,
the heap will eventually be filled with unneeded FOs.
OTOH, if your document contains forward-references --page-number-
citations pointing forward to the end of the document-- then
splitting up in multiple page-sequences doesn't help all that much,
I'm afraid...
...
} finally {
//Clean-up
out.close();
}
After we hit out.close, does it cleanup all used up resources or
should we
do something extra to cleanup?
I think this should suffice... One other important memory-issue has
been fixed since the 0.92 release, in the image-cache. If your
document contains a lot of images, this could also be the cause of
your problems.
Please see if you can try to run the same documents through FOP
Trunk, as it may already offer a substantial improvement.
Also, is there any guideline that how many page-sequences a
document can
have and also within one page-sequence how much (how do we know how
much) so
as to handle large volume? I know it depends on the amount of free
memory at
the time of spawning this transform request, but still, a
guildeline would
help so that I can split into page-sequences accordingly.
No such guidelines exist, AFAIK, but if you don't have any forward
references, and keep your page-sequences relatively small --say no
more than 10 pages each-- the number you can have in your document is
virtually unlimited.
HTH
Cheers,
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem PDF Renderer could not be found
On Oct 19, 2006, at 16:10, [EMAIL PROTECTED] wrote: Hi, Now I implemented the UserAgent + Renderer correct, but now it seems that the SAX Parser can't figure out the correct FOEventHandler. Is there any way like the Renderer to configure a EventHandler? My code at the moment is: File pdffile = new File(pdfname); out = new FileOutputStream(pdffile); FOUserAgent useragent = fopFactory.newFOUserAgent(); PDFRenderer pdfrenderer = new PDFRenderer(); pdfrenderer.setUserAgent(useragent); RTFHandler handler = new RTFHandler(useragent, out); Errrm... Something's not right here. Are you trying to render to PDF or to RTF? Using the PDFRenderer with the RTFHandler is not an option, I'm afraid. :/ (For PDF you would need an AreaTreeHandler, for RTF you'd need an RTFRenderer) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: One Page DOcument
On Oct 18, 2006, at 15:56, mikevn123 wrote: I've used the fo:marker logic with FOP 0.20.5, however 0.92beta does not allow fo:tables within markers. FYI: this has been fixed in FOP Trunk, and so will be available in the next release. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversion of xml data to pdf
On Oct 8, 2006, at 15:45, Andreas L Delmelle wrote: It appears that either these bugs simply get ignored by Oracle (*), or no-one takes the time to file them and supply the Oracle-devs with the information they really need to address these problems. It just occurred to me: to make sure which of the two options applies here, maybe someone can test this with Oracle 10g and see if the bug is still present in that release. Maybe it has already been fixed, but not in Oracle 9... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: conversion of xml data to pdf
On Oct 8, 2006, at 12:33, Srinivas Akula wrote: I am using Fop 0.2.5., it is working fine in tomcat 5.0, but when the same application has been deployed in oracle 9i apache server, the application is throwing Null Pointer Exception,. The Problem i am getting is at Transformer.transform(Source, Result). I appriciate you, if you could please provide me the solution. This looks a lot like the bug in Oracle's XSLT processor that has popped up a few times now on this list... There are two possible solutions: - replace Oracle's XML/XSLT combo with Xerces (XML) and Xalan/Saxon (XSLT) - file a bug with Oracle, and insist on the problem being resolved at their end It appears that either these bugs simply get ignored by Oracle (*), or no-one takes the time to file them and supply the Oracle-devs with the information they really need to address these problems. (*) Hard to believe, but it does happen with commercial software. Ask Jeremias about his experience with filing bugs against Adobe Acrobat. :) Plain commercial logic: if you're not a large enough customer, the bug will end up way at the bottom of their priority list. In any case, nothing that can be done about it from the FOP side, I'm afraid... Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: node() and text() problem
On Oct 2, 2006, at 17:19, fabio76 wrote: Hi, Strictly speaking, this is a pure XSLT question, and therefore better suited on the Mulberry list. Anyway, this is a test subnode sub_sub_node continue... I need to write the start test (this is a test), apply a template on sub-node (node_2, node_3) and write the rest of the text (continue...) I'm not sure what your problem is, but if you use simply: Then the nodes --both elements and text-- will be processed, by any compliant XSLT processor, in document order, so this means you don't have to do anything special, it seems... (the last text node appears after the two subnodes in the document) Of course, this convenience is completely lost once you explicitly pull some nodes from the document like In that case, *all* text-descendants will be processed before any of the element-descendants. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Possible bug in PNGRenderer (when output file doesn't include an extension)
On Sep 29, 2006, at 22:19, Matt Healy wrote: Hi Matt, I believe that I've stumbled across a bug in the PNGRenderer's 'setOutputDirectory' method. If the user has set an output file on the user agent, but the file doesn't include an extension, a StringIndexOutOfBoundsException is thrown when the PNGRenderer attempts to deduce the "file prefix" to be used for the various pages, causing the rendering attempt to fail. This isn't likely to be an issue under many circumstances, since users will frequently specify the file name using an extension (e.g., "/Volumes/Stuff/ProjectReport.png"), but if the user is accustomed to working on an OS that doesn't mandate file extensions (e.g., OS X), this problem could come up, and it's reasonably easy to resolve. Seems like a fine suggestion to me, however, there's still a (rather exceptional) case that won't be covered: What if the user doesn't specify an extension, but uses a '.' elsewhere in the filename? More waterproof may be to suppose that, if there is an extension, it will always be '.png' or '.PNG' (?) Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 1.0dev: exploiting of AreaTree for measurement of content
On Sep 29, 2006, at 09:56, Igor Istomin wrote: Hi Igor, > Maybe you could use the Intermediate Format (*) for this? > Render the area tree to XML, perform the computations/transform the > attributes via XSLT, and finally render the altered area tree to PDF. Thanks for this idea. I consider this solution as alternative. The problem is that an input document can be huge and it seems not rational to process the whole document to modify page header/footer only. You could be right, but I just realized that I haven't asked more info about why precisely you need to modify the header/footer... It would probably help a lot if you could explain this a bit more. Are you absolutely certain that your issue can't be solved purely in XSL-FO? If yes, is it the same adjustment for all pages? Do you need the entire document contents to determine how much adjustment you need? Maybe it's possible to render only the first few pages (or the first page-sequence)? Besides that, it does not necessarily mean processing the whole document twice, but rather, perform part of the processing, then dump the area tree to XML, modify that, and finally continue the process (?) At least you'll skip the layout-phase the second time around (unless you need to merge information from the area tree with the original FO). Note the remark all the way at the bottom of the page about the Intermediate Format: you don't really need to write the XML to an output file. Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP 1.0dev: exploiting of AreaTree for measurement of content
On Sep 28, 2006, at 10:04, Igor Istomin wrote: Hi, I started to use FOP 0.92beta (for prototyping of print subsystem) and I need to measure some content before producing of final XSL-FO document. In fact, I need to determine height of page header/footer. Is it possible to use FOP's API (internal) to perform such measurements ? Possible? I think so, but it could turn out to be quite some work... Maybe you could use the Intermediate Format (*) for this? Render the area tree to XML, perform the computations/transform the attributes via XSLT, and finally render the altered area tree to PDF. HTH! Andreas (*) see: http://xmlgraphics.apache.org/fop/0.92/intermediate.html - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables or no tables
On Sep 1, 2006, at 16:27, Rick Roen wrote: Hi, Just FYI: With HTML I could specify a width of a span element and make if right or left aligned, however I don’t know of a way to do this with FOP In principle, all you'd need is an inline-container... but as indicated, these are unfortunately NYI in FOP. :( Cheers, Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: tables or no tables
On Sep 1, 2006, at 16:12, Niek van Elck wrote: I’m quite new to the xsl-fo subject, allthough i have build a couple of pdf reports using xsl-fo. I have encountered some limitations on fo:table The book xsl-fo from o’reilly says there are so many other ways to represent data than the use of tables. The only thing missing is what the other ways are.. Absolute-positioned block-containers, inline-containers(*), list- blocks... Really depends on what the precise requirements are. What limitations are bugging you exactly? (*) inline-containers are currently not yet implemented in FOP Is there anyone who can push me in the right direction? Well, did I? If not, it would help us if you could be more precise about the intended result. I'm sure there are a lot of people around here who would gladly offer you examples. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: AW: Setting configuration of fonts in java code?
On Sep 1, 2006, at 11:27, Peter Neu wrote:
Hm, is this possible? When fop reads the userconfig.xml, where is
the base
directory? The application runs in tomcat so I don't know where to
put the
base dir.
I think so. Unfortunately, I'm not all to familiar with getting this
info in a servlet context, but isn't it possible to obtain the root
from the below tree via the servlet?
(maybe others on this list immediately know the idiom for retrieving
that)
In that case, it might become even simpler:
fopFactory.setFontBaseURL(
{root here} + System.getProperty("file.separator") + "XML");
Same line of code for both platforms.
HTH!
Andreas
File system looks like this
ROOT
|WEB-INF
||classes
|
|XML
|--- userconfig.xml
|--- verdana.ttf
|--- ttfcm.xml
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: AW: Setting configuration of fonts in java code?
On Sep 1, 2006, at 10:49, Peter Neu wrote: Hi, I'm working my way through the src code of FOP in order to find a way to configure the font setup in the java code. But this seems rather difficult. The org.apache.fop.configuration.FontInfo object gives me the possibility to insert the font names and stuff but I cannot insert the metric file directly because only the path is taken there. Re-reading your original problem: wouldn't the solution be to use relative URIs? If you can make sure the relative locations are the same on both platforms, then only the fontBaseDir would have to be defined separately --which seems much easier... HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP - 0.20.5 and page sequence
On Aug 30, 2006, at 20:43, Shaun Shoaee wrote: Hi, Now a little issue is to count the page and will not work before page sequence ends. Any idea how to approach? Not entirely sure if I understand the problem, but it seems as if you are looking for this: http://www.w3.org/TR/xsl11/#retrieve-boundary That said, the default value should be of 'page-sequence'. The compliance page shows that FOP 0.20.5 doesn't implement this property, maybe the limitation is precisely this (?) If you can upgrade to FOP 0.92, it should work like you described without explicitly having to specify the retrieve-boundary on the retrieve-marker. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
