Re: FOP alignment problem between two font type
Indeed... Also note that the issue as described ONLY affects the Base14 (built-in) Symbol font, so another way to address this would be to make sure to use the TrueType Symbol font, if available, in which case the font-selection would also produce the intended result with two different fonts. KR Andreas - Original Message - > On Tue, Mar 8, 2016 at 6:53 PM, Puja < pujaag...@gmail.com > wrote: > > I faced such issue with sigma character, I couldn't find worthwhile > > solution. > > Ended up using image of sigma character. > > > On Mar 8, 2016 19:40, "gkaplan [via Apache FOP]" < [hidden email] > wrote: > > > > I am using XSL to create the FOP markup, so it is not possible for me to > > > easily wrap special characters in their own inline block. I am using the > > > greater-than-or-equals ≥ symbol which is only available in the Symbol > > > font. > > > The rest of the document is in sans-serif. > > > > > > What's odd is that any numbers subsequent to the ≥ symbol are also in the > > > Symbol font. > > > > > > My markup includes an attribute-set as follows: > > > > > > > > > > > > > > select="$fontSize"/> > > > > > > sans-serif, > > > Symbol > > > > > > > > > > > > But when the PDF is generated, the baseline (or some other attribute) of > > > the > > > ≥ symbol is much lower. > > > > Arial Unicode MS > Noto Sans > etc. > > > Is there really no way to fix this? I've tried tinkering with setting > > > baselines, etc. but nothing fixes this. Also, as the previous solution > > > mentions, I don't know of any fonts that include this symbol as well as > > > the > > > full alphabet. > > > > > > Thanks in advance for any help. > > > > > > If you reply to this email, your message will be added to the discussion > > > below: > > > > > > http://apache-fop.1065347.n5.nabble.com/FOP-alignment-problem-between-two-font-type-tp41322p43650.html > > > > > > To unsubscribe from FOP alignment problem between two font type, click > > > here > > > . > > > > > > NAML > > > > > View this message in context: Re: FOP alignment problem between two font > > type > > > Sent from the FOP - Users mailing list archive at Nabble.com. >
Re: Hyphenation Jar License Issues
Hi Sripathi On 30 Jul 2015, at 13:23, sripathi sripathi.rao...@gmail.com wrote: Thanks for your reply Luis..I want to use en-us pattern files,these are comes under 'Other-Free' license.Am not aware of 'Other-Free' license,is this is free? Can i use these pattern file in my commercial application.Please suggested me on this.. It depends on the context really. The reason why we had to remove them from the FOP distribution way back, is that it turned out the license did not permit free redistribution. If you are developing an app that is intended for personal/internal use, it is likely no problem to include those patterns. On the other hand, if you are a contractor developing an application for a third party and you do include them, that may be a violation of the license agreement. I suggest you carefully read the license text, and when in doubt, involve somebody with a legal background to find out for certain if what you intend to do with those patterns is OK. Hope this helps! KR Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Content spanning multiple pages issue
On 30 Jul 2011, at 17:55, Fernando Israel wrote: Hi Fernando I use FOP 1.0 to produce PDFs. The issue I am facing is that the content of the page is such that it should span over multiple pages but I only get one single page PDF file. I believe I am missing something very obvious. The reason is that *all* the content is wrapped inside absolute-positioned block-containers. Those will never, ever trigger a page-break. At worst, there will be an overflow condition if the content does not fit, but it will never flow to the next page, like a 'regular' block-container. (In XSL-FO terminology, regular block-containers will potentially yield multiple viewport/reference pairs, whereas absolute-positioned ones will always have only one such pair.) To give advice on how to resolve this (in case it is still necessary), we would also need a hint of the intended result. Let us know if we can be of further assistance. HTH! Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: TOC with leaders - alignment problems
On 30 Jul 2011, at 18:37, mhoenicka wrote: Hi Markus snip / When processing these fo with fop nightly builds (first tested: March 04 2011, last tested: July 27 2011), the chapter titles are correctly aligned on the left side. However, the page numbers do not align on the right side, resulting in a ragged edge. The longer the chapter title, the further the page number moves to the left. Here's a screenshot of the pdf output: This looks like a bug, somehow, although I am not 100% sure, yet. Is there a workaround or a fix for this problem? There seems to be a workaround. Following a hunch, I removed nested inlines as much as possible, and worked with a reduced: fo:block text-align-last=justify text-align=start end-indent=24pt last-line-end-indent=-24pt fo:basic-link internal-destination=... keep-with-next.within-line=always 1. Short chapter title /fo:basic-link fo:leader leader-pattern=dots leader-pattern-width=3pt leader-alignment=reference-area keep-with-next.within-line=always / fo:basic-link internal-destination=... fo:page-number-citation ref-id=.../ /fo:basic-link /fo:block I am no Docbook guru, so I can't tell you exactly how to make the stylesheets produce such a structure without the nested inlines, but maybe it's enough to steer you towards a solution. HTH! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Content spanning multiple pages issue
On 30 Jul 2011, at 21:13, Fernando Israel wrote: Hi Fernando, snip / So I now have to rephrase the question. Can I have a table within an absolute postioned block container go over to a second page it its length requires so ?. I guess that the answer is no, but I better ask. You guess correct. BTW, it just occurred to me, while re-examining the FO you sent, that the 'position' property does not apply to fo:block, so it actually serves no purpose there. Specifying the property can almost be seen as wasteful, because it 'overburdens' the property parser. Big word, because it does not matter _that_ much, but less is more. :-) If the answer is no, given my description of the objective, can you think of a different way of trying to achieve the objective ?. Let's see... The block-container will only be broken if its top/left positioning is relative, which FOP does not support. Never mind, because that is not what you want anyway. You would get a page-break, sure enough, but it would still cause _some_ of the content to be clipped. In fact, what would happen if FOP were to implement it, is that the block-container would be broken using the full available page-height, as it does not interact with the absolute-positioned ones. Then, the generated areas on each page are offset by the specified amount. Hardly surprising that nobody has ever even asked questions about this on the user-list (at least AFAIK). It doesn't look useful --but I'm straying... Given the above, and assuming that, in the example you sent, you would only need to see that one block flowing to the next page, you could try using space-before (instead of top) and start-indent (instead of left) to create the displacement effect. Something like: fo:block-container space-before=8.3cm start-indent=1cm width=auto height=auto fo:block start-indent=0 font-family=Comic Sans MS,cursive font-size=16px font-weight=700 font-style=normal text-align=left color=rgb(0,0,0) padding=4px fo:blockTEXT 9/fo:block fo:block Here is some sample code /fo:block fo:block Here is some sample code /fo:block ... That way, at least that block-container will be split over multiple pages, if necessary. Any absolute-positioned content following it, will have its single area on the last page spanned by the preceding, relative-positioned content. Since it is likely not known in advance how many lines will end up on that last page, figuring out the right value for 'top' in such cases would be quite a challenge. Using 'bottom' displacement may offer a way out, here, but still... If there is then yet more following relative-positioned content, it becomes increasingly difficult to manage, since there is no clue as to what the initial offset should be. You would have to resort to using forced breaks to make it a bit easier. It all really depends on how complex the eventual result can become. If it's only a single block that should flow to the next page, and it is not itself interrupted/followed by absolute-positioned content, the above would suffice: use a regular block-container with space-before for the initial displacement on the first page, or even leave that block-container out entirely, and just insert the block. Not sure if this will help, but it's very difficult to say, generically, how best to address this, without actually having seen some of the more complex cases. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: No default font defined by OutputConverter
On 22 Jul 2011, at 16:59, Lance Goforth wrote: Hi Lance snip / Does the context allow for multiple concurrent sessions, or can the user only render a single document at a time? Has it been reported across a number of different Java Runtime implementations or are all users working with the exact same OS/VM? It should only be allowing one document rendering at one time. However, I might have to backtrack through the code to verify that is true. All the JVMs should be 1.6, although some minor releases might vary, 1.6.17 and 1.6.22 - all are on a remote windows session running Windows Server 2003 Given that: a) it has only been noticed with AWT rendering, which relies on the implementation of java.awt.font, and b) it runs in remote sessions, which in all likelihood _do_ run concurrently --albeit in separate JVM instances I am beginning to suspect it is a matter of contention on the OS level. All those JVM instances are basically relying on the OS to provide them with the font information. If the OS screws that up somehow, then the Java implementation can be as good/waterproof as it wants... On the other hand, it may just as well point to a quirk in the Java VM implementation, as a lot of those concurrent sessions would basically be relying on the same, single Java installation on the server. From that perspective, purists could point out that that is simply not how Java was intended to be used in the first place. Think of it this way: it is analogous/similar to having Windows running in a VM on the server, and booting that VM from scratch for each request to render a single document with FOP. All very creative, but that is definitely not how virtualization was meant to be used. Another point of comparison: one could conceivably write a client app that, instead of issuing a query via standard JDBC, opens a remote desktop session to a server to start up a database instance and then issue the query there. Make sense? I didn't think so... At any rate, if it really is an issue affecting only concurrent runs in separate, isolated Java processes, then it is guaranteed that nothing FOP can do, is ever going to mitigate that. We can only try to safeguard the code for multiple concurrent runs in the same Java runtime. Any synchronization outside of that scope is up to Java itself and/or the OS. From FOP's point of view, there are just many isolated FopFactory instances that know absolutely nothing about each other, let alone share any common info. An interesting, yet not so straightforward experiment, would be to try this on a *nix-ish server, and see whether the issue persists there in a similar context. Java is Java, so will run on any Linux variant just as well. If Linux would do a better job at keeping those sessions truly separated, the problem would be Windows. If the issue persists on Linux as well, it would be a Java issue. From the looks of it, short-term relief can probably only be obtained, without too much effort, by reducing the maximum number of concurrent sessions on the server. That would mean that users will have to wait longer. Still, they might find that more palatable than the recovery process you referred to. Other than that, of course you could also buy more servers to handle the increased workload... JK ;-) If you ask me, the better/more robust solution in the longer term would probably mean investing in refactoring, in a paradigm shift in the application. Instead of previewing in Java AWT in a remote desktop session, just render in PDF, PNG, TIFF... and serve that via HTTP as the 'preview'. If the user accepts the preview, the server can then optionally write the stream also to a shared location, from where it is available for future reference. Or even something more personal, like send a mail with the output file as an attachment. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: No default font defined by OutputConverter
Hi Lance One thing is not entirely clear to me: Is the error thrown when rendering to PDF, AWT, or both intermittently? I've only seen it rendering to AWT, but I may have missed it going to PDF, that is used less often. OK, I was asking, since if it were only for PDF, then it would have been something strictly internal to FOP. If it's mainly for AWT, then the java.awt.font implementation becomes another relevant variable that is not fully under FOP's control... The application is a swing app, not an online or web app. So the fop generation, rendering, and display are all in one jvm for each user. Does the context allow for multiple concurrent sessions, or can the user only render a single document at a time? Has it been reported across a number of different Java Runtime implementations or are all users working with the exact same OS/VM? Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: using command line : SAXException: Mismatch: page-sequence vs. root
On 20 Jul 2011, at 10:04, Aya Sah wrote: Hi I know that this error : SAXException: Mismatch: page-sequence vs. root have already been solved in java http://xmlgraphics.apache.org/fop/faq.html#saxexception-mismatch here . But I'm using a command line, is it possible to find the original exception using a parameter or a specific command line? Given that, as the FAQ explains, the real error is likely swallowed by a buggy XSLT implementation failing to re-throw a caught Exception, the only way I can immediately think of, is to force a different one to be used (= a more recent version of Xalan, or Saxon). You can normally achieve this by editing the fop.sh script, and making sure the actual command that is issued sets the corresponding Java System property. For example, if you download Saxon-HE and make it available on the classpath, then you can enforce usage of its TransformerFactory by passing -Djavax.xml.transform.TransformerFactory=net.sf.saxon.TransformerFactoryImpl HTH! Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: No default font defined by OutputConverter
On 20 Jul 2011, at 19:02, Lance Goforth wrote: Hi Lance I've seen this message on the groups and online discussed - but never any answers. Indeed, and from the looks of it, it is already occurring since 2002 (references to FOP 0.1x?)... There are no answers, probably because no one ever succeeded in nailing down the set of parameters to reliably reproduce it, and allow us to trace it down further. Let's see if we can get there. What FOP version are you on exactly? I have an embedded system, that generates fo and pdf output from xsl. It opens the output first in the AWT renderer window. I'd say 90-95% of the time that is fine. But recently (and increasingly) it has started throwing the 'No default font defined by OutputConverter' error. Interesting... If I read you correctly, you seem to mean that it was 'better' in the past. Do you know of any relevant variables that have changed over time? A Java/FOP upgrade, or some such? Normally the user just has to re-run the report. But these are automatically generated for the user, and they have to go back in and find the spot to recreate, so it's quite a pain for them. Is it correct to infer from 'automatically generated' that the process runs in a servlet container? If yes, do you know if the number of concurrently spawned sessions has increased by a significant amount (more users)? One thing is not entirely clear to me: Is the error thrown when rendering to PDF, AWT, or both intermittently? Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: character #133;
Just to be complete: I wrote fo:block font-family=”Arial”/ xsl:texttestowe=12345#133;ABCD/xsl:text /fo:block On PDF his text was splitted into the two lines: 12345 ABCD #133; is the [next line] control character. It should not be used as this in FO to PDF. That is true in this particular context, if you want to avoid the line-break. However, for all other intents and purposes, #133; (or the corresponding Unicode codepoint U+0085) is a perfectly legitimate typographical aid, and may be used to enforce inline linefeeds, independent/regardless of linefeed-treatment=preserve. It is defined in UAX#14 as one of a handful of explicit break-characters, and as such, is supported by FOP. There are a few control break-characters which should indeed never be used --classical form-feed and line-tabulation-- but those will already cause the XML parser to choke, so FOP would never see them. See also: http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/test/layoutengine/standard-testcases/block_uax14_explicit-breaks.xml?view=markup Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: WordML continuous section break
On 15 Jul 2011, at 09:26, Marcos García wrote: Hi Marcos I have created a reduced version of the original WordML document with the same continous section break, and obtained the same results (it breaks it in two different pages). Here you have the FO I'm currently using. It's long. ready? OK, thanks. That makes it a whole lot clearer. So, you want Paragraph 1 and Paragraph 2 to be shown on the same page, right? In that case, the fact that they appear in different fo:page-sequences does not help --quite on the contrary: that forces an unconditional page-break in between the two page-sequences. The two blocks/paragraphs should end up in the same page-sequence, using the same 2-column page-master, and the fo:flow should look something like (stripped to show the most relevant parts): fo:flow flow-name=xsl-region-body fo:block span=all role=Div widows=2 orphans=2 font-size=10pt line-height=1.147 white-space-collapse=true ... fo:block font-family=TimesNewRoman font-size=12pt language=ES fo:inlineParagraph1/fo:inline /fo:block /fo:block fo:block role=Div widows=2 orphans=2 font-size=10pt line-height=1.147 white-space-collapse=true fo:block font-family=TimesNewRoman font-size=12pt language=ES fo:inlineParagraph2/fo:inline /fo:block /fo:block fo:block id=last-block/ /fo:flow Note the span=all spec on the first block to make sure it spans both columns. The second block then, will flow in two columns (implicit span=none). Obviously, this will mean --likely significant-- changes to your stylesheet code. Hope this helps! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: org.apache.fop.fo.ValidationException: fo:list-block is missing child elements
On 15 Jul 2011, at 17:54, Hamed Mohammed wrote:
Hi
Just to get it out of the way: please refrain from hijacking existing threads
in the future, unless it really is the same issue. The OP was about
fo:list-blocks, your issue concerns fo:table-rows. The OP was about missing
child elements, your issue is about a wrong child element. Apart from the fact
that a ValidationException is thrown, the cases have nothing in common...
I get this error intermittently while generating PDF report using FOP 1.0.
null:5511:928: {http://www.w3.org/1999/XSL/Format}block; is not a valid
child of fo:table-row! (See position 5511:928).
snip /
In most cases this issue is resolved on resubmitting the report. Can any one
pin point what is the actual cause of this issue and why it is happening
occasionally for the same input?
This means that, at line 5511, column 928 in the FO source, there is a fo:block
that ends up as a direct child of a fo:table-row, and that is not allowed by
XSL-FO (see: http://www.w3.org/TR/xsl/#fo_table-row - only fo:table-cells are
allowed as child nodes)
I would suspect it is actually NOT the same input. Have you verified that the
FO is really identical in both cases? If so, can you post a sample?
Regards,
Andreas
---
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Mysterious left truncation of table in region-before: version 1.0 only
On 15 Jul 2011, at 15:57, Rob Sargent wrote: Hi Rob Drats. I played with the fo after attaching it and before sending. The commented-out region-before lines are the ones which cause the problem. Sorry, but which commented lines are you referring to? I do not see any in the posted fragment... Am I missing something? Do you mean the issue is still unresolved? ... Here a left-hand page definition for this sequence: fo:simple-page-master margin-bottom=0.6in margin-top=0in page-height=11in page-width=8.5in master-name=rest-even fo:region-body margin-left=0.0in margin-right=0.833in margin-bottom=0.7in margin-top=0.66in column-gap=0.25in column-count=2 / fo:region-before margin-top=5mm margin-left=0.75in margin-right=0.833in extent=0.66in region-name=header-rest / OK, I see. Just so you know, margin-* properties do not apply to region-before, nor to any of the other side-regions for that matter. Apparently, given your description, this would be handled incorrectly in FOP 1.0. That said, however, I cannot reproduce such an issue with FOP trunk. Admittedly, I am trying to piece together a sample using the simple-page-master you posted, and FOP, as I half expected, just seems to ignore the margin. As the spec states, literally: Every formatting property may be specified on every formatting object. So, it is not an error. It should not have side-effects either, though... KR Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Mysterious left truncation of table in region-before: version 1.0 only
On 14 Jul 2011, at 05:58, Rob Sargent wrote: Hi Rob Is this by any chance a know bug in version 1.0? Searching for open issues in Bugzilla that contain both table and region-before yielded no results. So, I would assume that, if it is a bug, it is not a known one (or already fixed in trunk --didn't search the closed bugs). At any rate, sorry to keep repeating this, but... it is difficult --not to say: virtually impossible- to say more without the actual FO file. Preferably, if not too time-consuming, trimmed down to the smallest FO that shows the issue. Is it possible to post something like that here? If you can't because it contains confidential info, you can send it to me off-list if that works for you. I place a single row table, single cell table in the region before. In version 0.95 the table, which has background set to silver renders perfectly, spanning the entire region-before. Using versions 1.0, the left ~0.83 inches of the table are obliterated. The text is centered properly as if the cell spanned the region width. .83in is almost 60pt, 'roughly' .83in could be exactly that. Perhaps this gives a clue? Is there some margin/indent specified as 60pt? If you specify a border on the table, does that disappear on the left as well? I've tried placing the entire table in a block-container to no avail. Weirder still is that only in one flow, (the second of two) does the truncation appear. Both flows use the same template to define the table. The two fo files are identical (according to emacs's ediff). Is that believable? While that seems strange, I would not rule it out without having taken a closer look. KR Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 07 Jul 2011, at 21:07, Rob Sargent wrote: Hi Rob I can't seem to get my logger setup properly. I have these in my original log4j.properties file log4j.logger.org.apache.fop=ERROR log4j.logger.org.apache.xmlgraphics=ERROR I've changed them both to DEBUG, but only the xmlgraphics gets any noisier? (Slightly off-topic for fop-users@, but anyway, if it's still relevant...) The most likely explanation would be a class-loading context difference. Is it conceivable in your setup that the FOP classes are loaded in another context than XGC? If so, then FOP may be using a different log config, simply because it finds another log4j.properties somewhere on the classpath (i.e. the context ClassLoader does not see the same resource that is used for configuring the XGC logger). HTH! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 07 Jul 2011, at 16:36, Rob Sargent wrote: Hi Rob snip / Unfortunately I've had no luck with a substitution block in my fop config file _comme ca_: renderers renderer mime=application/pdf filterList !-- provides compression using zlib flate (default is on) -- valueflate/value /filterList fonts substitution Sorry if I did not make that clearer, but this is the wrong place. The substitutions block is applies to all renderers and should go into a fonts element that is a direct child of the root of the config file. See also the example on the page (link sent earlier). HTH! Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 07 Jul 2011, at 19:07, Rob Sargent wrote: Hi Rob My mistake. A rash assumption that the example was simply glossing over the renderer specific stuff. (Seemed reasonable to me that one might want different fonts in different renderers) I now have the following (partial) config. file and am still not getting a clean Joint. snip / OK, that looks good. and I have confirmed that the font files are in my distribution. The only message I get from the FOP run is: [Fop100Stage] [Print Preview Thread] [2011-07-07 10:58:27,161] DEBUG - Looking for hyph jar: longpath/fop/fop100/fop/lib/fop-hyph.jar!/hyph/ [FOP] [Print Preview Thread] [2011-07-07 10:58:27,161] DEBUG - target-resolution set to: 72.0dpi (px2mm=0.3528) where the first message confirms for me that I'm getting the correct fop version. Provided that this is the config file that is used, you should then see, a bit further down, something like ... DEBUG - FontInfo - Helvetica,normal,400: Replacing Helvetica (priority=0) by FreeSans (priority=0) ... Do you see a reference like that? If yes, do you also see the FreeSans font being registered a bit higher up? If not, that could mean either of: - a different config is actually used at runtime - the FreeSans font failed to load properly - the FreeSans font is still not the one that Java AWT falls back on for Helvetica, so the metrics still don't match As for the latter, the key is that via the config you _can_ make FOP follow suit, but you really need to make sure that it _is_ the FreeSans font that is used by Batik. Does that font have a narrower 'J' glyph than standard Helvetica? It doesn't seem so, from what I can tell... Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 07 Jul 2011, at 20:01, Rob Sargent wrote: Hi Rob First off, thanks for your persistence in this matter. No problem. I do not see the 'DEBUB - FontInfo ... replacing ...' line (nor the others you mention) but this is likely a symptom of the setting of my log level. Let me try to address that first. Or... Oh boy, how could I miss that?! I had to go back a step and look at the very first words of the initial post. You said you were using 0.95, and font-substitution was not yet implemented then. Apologies for the confusion if that is the reason it is missing from the log. In that case, the only resort may indeed be to register explicit triplets per renderer, mapping the Helvetica family to the appropriate TTF files. Should be possible with 0.95, I believe, since it is actually required for PDF/A which was already in that release. The key then remains to find out _exactly_ which font is selected on your system to substitute Helvetica. As I hinted, it should be one with a narrower 'J', which explains the visual effect. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 01 Jul 2011, at 18:20, Rob Sargent wrote: Hi Rob snip / I'm coming to the conclusion that to guarantee all platforms use the same font I must include it in the distribution of the client. As I've said, we're already including non-standard fonts (e.g. Optima), but my naive assumption that, since it's part and parcel of PDF, simply naming Helvetica was enough is clearly wrong. Given the fact that (a substitute for) Helvetica may not be available (or just is slightly different) on the client... It is not entirely true that it's part and parcel of PDF. The PDF Specification states only that viewer applications can assume the Base14 fonts to always be available, so as not to force said viewers to include them in the application package. Not necessarily naive, but you're just bitten by the fact that, at the end of the day, there simply is no such thing as true platform-independency, especially where it concerns interoperability between two basically separate Java apps. Some things depend on the implementation of the Java runtime and the actual configuration of the OS it runs on. Assuming that you know which font is actually selected by the JVM/OS, then you could try creating a substitution mapping in FOP's config, like: substitution from font-family=Helvetica / to font-family=.../ /substitution see: http://xmlgraphics.apache.org/fop/1.0/fonts.html#substitution That will force FOP to use the metrics for that font, rather than the default Base14 Helvetica (also for your FO, so there will be consistency, if that is what you are looking for). Incidentally, trying to use literal SansSerif in SVG triggered the same issue on OS X. The reason is that, for the Apple JVM SansSerif is an alias for Lucida Grande. I can confirm that I see change when adding a mapping such as above, however, the appropriate font-file cannot be parsed by FOP currently... Still, you might be able to resolve it this way on your end. Now can I just use the truetype arial which _is_ on my box (but does not rectify the current situation) and would presumably be what the pc users are getting. Or am I better off getting a commercial truetype Helvetica? That depends on what you want to do with it. Keep in mind that buying the Helvetica font would only grant you personal use. It comes pre-installed on most common systems, but that license does not permit the user-developers to just include it in their own projects. That is very likely precisely the reason why it is left out of Linux, as a matter of principle. What when you happen to run into a colleague that has the same issue? He/she should then have to buy it as well. If the vendor gets wind of you redistributing the font in your own software, or just copying it to multiple clients within your organization, he may not like it, and force you to pay more. There is a reason FOP can only redistribute the *metrics* for the Base14 fonts, not the fonts themselves. Since you're already including other fonts, in case you have not done so yet, be sure to check for those as well whether or not you are permitted to include them. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
Hi Rob, On 06/29/2011 10:44 AM, Rob Sargent wrote: Well, that explains why the bold text of my sidebar looks fine! Give that this SVG we're talking about I have to get _some_ font into the OS's fonts setup. Also give that the stylesheet has to work on Windows, Mac and Linux, what are the chances of um, er aliasing FreeSans as Helvetica? Looks like I could do that in /etc/fonts/fonts.config? Any hope there? Did you follow the link Vincent posted in Bugzilla? IIC, that explains exactly what the core issue is, and shows what needs to be done to work around it. Obviously, that would mean your FOP config is not portable across all platforms, but that seems justifiable. I'm on OpenSuSE-11.4. I have 240 /usr/share/fonts/100dpi/helv*.pcf.gz. Are these unavailable for SVG/PDF generation? Perhaps. PCF is a format used by Xserve, which is the reason why you have them installed. This does not necessarily mean that the Java AWT implementation has built-in support for PCF fonts, though... HTH! Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 30 Jun 2011, at 22:56, Rob Sargent wrote: Did you follow the link Vincent posted in Bugzilla? IIC, that explains exactly what the core issue is, and shows what needs to be done to work around it. Obviously, that would mean your FOP config is not portable across all platforms, but that seems justifiable. snip / However, I don't follow your last point on a justifiable non-portable config. I meant that a config file will, almost by definition, be tied to the local system/platform that FOP runs on. In a way, it is precisely meant to make sure that environment-specific stuff can be 'configured' with relative ease. Luckily there is only one Linux box that I need to do this correctly so I'm willing to tweak that config file by hand if it comes to that. That machine is responsible for the final pdf for the publishers. I'm not sure what the mac users are seeing, but the Windows users are doing fine with the call for Helvetica. Just so you know: the minimized sample Mehdi attached to the bug report renders fine on OS X without custom config. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 30 Jun 2011, at 23:47, Rob Sargent wrote: The news about the mac is reassuring, thanks. So far I've swapped out the alias for Numbus Sans L for FreeSans in /etc/fonts/conf.avail/30-metric-aliases.conf: fonts-config; fc-cache; placed the following in my fop config xml font kerning=yes embed-url=FreeSans.ttf font-triplet name=Helvetica style=normal weight=normal/ /font Wait a second... Did you also configure FOP to locate the FreeSans.ttf file? See: http://xmlgraphics.apache.org/fop/1.0/fonts.html#basics, and beyond If FOP is not specifically told to look elsewhere, and it would not find that TTF in the working directory, then as a result, it would still fall back to the default sans-serif and use the inappropriate metrics. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 01 Jul 2011, at 00:12, Andreas L. Delmelle wrote: snip / Did you also configure FOP to locate the FreeSans.ttf file? See: http://xmlgraphics.apache.org/fop/1.0/fonts.html#basics, and beyond Just noticed that it is not explicitly mentioned, but if you have a large number of fonts installed with the OS, you will probably want to avoid using auto-detection, as that can get quite costly. For a quick test, it may suffice to check whether the issue would be resolved, though... Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop not handling svn rotated text on linux
On 01 Jul 2011, at 00:25, Rob Sargent wrote: Even with auto-detect on? In that case, the answer to my question would be: Yes, FOP is configured to look elsewhere. Still, it just occurred to me that the font definition you added, would only influence the specifications of font and font-family in the FO, or Helvetica specs passed by Batik to FOP. The latter is precisely what does *not* happen, and causes the issue. Batik asks Java for Helvetica but gets something different. This font, however, is apparently not known to FOP. At least, not by that name... So, first thing to do, is to find out exactly which font Java AWT *does* give to Batik for Helvetica. Then we have to find out why FOP doesn't recognize it. Concerning the observation that it renders correctly if you use a 'wrong' font-family specification: that might be a worthwhile option to explore. Which exact font does Batik revert to in that case...? BTW: What exactly does that stack trace point to that you mentioned? Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Strange response
On 21 Jun 2011, at 17:39, Theresa Jayne Forster wrote: Hi Theresa I have a fo file with a block inside a b-c But on the pdf produced, I am not seeing the block on it. But I do see the red border of the b-c And all text is missing, any ideas why? snip / FO = /fo:instream-foreign-object Thanks! That's more like it! Even better --I should have stressed that-- would be the smallest complete FO document that demonstrates the problem (if it is possible to post that here without violating any confidentiality agreements...). That way, we can immediately run it through the debugger and see what's happening. Working off the posted fragment, I tried pasting it into a test template here, but did not succeed in reproducing the problem so far. The bottom-border of the b-c was not visible, but that is about all that disappeared on my end, and that can be explained by the fact that a height of 10mm is actually _just_ too little to hold a line with font-size 24pt (= 28.8pt, including half-leading, which is 10.16mm; if I make that 10.2mm, then the border renders properly, too). That said, I read in the other thread that you are currently transitioning from 0.20 to 1.0, and I am only looking at the latter. So, just to make sure we're not missing anything: To which version does this issue apply? Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: I need bottom up text.
On 20 Jun 2011, at 18:07, Theresa Jayne Forster wrote: Hi Theresa I am trying to do a document with a box near the bottom which is bottom aligned. I have tried everything but as soon as I put the apply-templates inside the table the text vanished, what am I doing wrong and how can I get it working. In the future, can you please post the generated FO markup? That helps us identify, reproduce and understand the issue better. Right now, based only on the XSLT code, we have to infer/imagine which attributes are included in the 'smallprint' set. Not that they are necessarily relevant here, but still... Suppose, for example, that the attribute-set 'smallprint' contains a relative font-size of 0.6em. Assuming that this attribute-set is also used in the matching template for Smallprint nodes, then if you start off with a font-size of 10pt, in the outer block-container it will be 6pt, and by the time the text is actually reached, that may have shrunk to well below 2pt, which would make the text near invisible at normal zoom. From the command-line, you can easily obtain the FO that FOP would get, by means of the '-foout' switch. This just as some advice that will yield quicker and more to-the-point responses. (basically I am looking for similar to the html4.0 loose transitional tabletr valign=”bottom”td/td/tr/table From what I can tell, the code you have should work fine for the most part (in FOP 1.0), assuming that there is nothing too exotic in that 'smallprint' attribute set or the other content (which we cannot see in your XSL code). The only thing that does not work, AFAIK, is a forced height on fo:table. To work around the latter, you can force the table to grow to the desired size by wrapping the cell content in a fo:block-container with explicit height. HTH! Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop .95 PDF generation issue with IE 6 (working fine in IE7)
On 17 Jun 2011, at 22:07, Chetan Shirol wrote: Hi Chetan I have set the content/type properly to PDF but still the issue is there. Actually we are migrating from fop .25 to .95 and this migration has caused this issue. Yes, but you also mention the issue is limited to IE6. People should really stop supporting it, and push their customers to modern browsers. That's the only way IE6 is ever going to die. (Still have to support it at my day-job too, to my dismay...) For the remainder, we have little context information about your servlet code. Can you check if the hint in the FAQ about using a ByteArrayOutputStream is implemented? (see the note at: http://xmlgraphics.apache.org/fop/1.0/servlets.html#xslt) The issue seems to be that IE6 thinks it has to display a text-file, rather than a PDF. I see no hard evidence so far that the PDF is actually corrupted. Another idea may to force the URL to end in .pdf by adding a dummy parameter. That used to be the way to trick browsers that depend on file extensions in the URL, rather than the content type in the HTTP header... see also: http://xmlgraphics.apache.org/fop/1.0/servlets.html#ie Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Text fill color in external SVG is not preserved
On 14 Jun 2011, at 02:10, Matthias Reischenbacher wrote: snip / I use Fop - nightly build on Win7/64 bit + Java 6. All the a, b, c, d labels should be red (first two are red, the rest is black) All the Text (1, 2, 3) should be white (first two are white, the third is black) I believe this issue is caused by the commit of rev 1095887. I've already reported to the commiter (Jeremias) which, I think, is working on a fix. But you might want to create a bugzilla entry anyway as Andreas suggested. Just in case anyone missed it: Jeremias committed the fix to FOP trunk today, so the next nightly build should work. I have verified locally that the supplied sample now renders as expected. Thanks, Jeremias! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
On 13 Jun 2011, at 12:05, Vincent Hennebert wrote: On 10/06/11 18:32, Andreas L. Delmelle wrote: The area tree XML stores the specified id as a prod-id attribute. There can definitely be multiple areas with the same prod-id, as a block can be broken over multiple columns or pages. Since prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids. Section 6.1.1 of the XSL-FO 1.1 Recommendation [1] mentions the ‘generated-by’ and ‘returned-by’ traits that XSL-FO processors are supposed to create, and that would probably prove handy in such situations. [1] http://www.w3.org/TR/xsl11/#define-returned-by Interesting catch! Yep, generated-by almost seems synonymous to the current prod-id, if we substitute the 'formatting object' with its 'id'. Granted, we do not auto-generate ids just yet... For the returned-by trait, in order to be able to serialize/externalize it, there is obviously the question of the format for the separator. Have to make sure to point out to users that they should preferably not use those (sequences of) characters in values for the 'id' property, if they use the AT or IF formats. Or at least, make the implementation robust enough to account for the (remote) possibility of brackets and commas appearing in an ID. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Text Overflows into adjacent cell
On 13 Jun 2011, at 22:53, Chetan Shirol wrote: Hi Chetan I am upgrading fop from .25 to .95 and facing the below issue. Please help. snip / Case 2: Long text with No white space like eg: ReallyReallyLongTextNoWhiteSpace then the text flows- overlaps the next column. FOP implements Unicode line-breaking rules, and those do not allow to break the sample text fragment anywhere. The usually suggested workaround is to alter the stylesheet, so that ZWSPs (U+200B) are inserted that give FOP a chance to break. So, you should get the equivalent of: R#x200B;e#x200B;a#x200B;l#x200B;l#x200B;y... That will effectively lead to a 'wrapping' effect, i.e. FOP will place as many characters as possible in a line, and break at the next ZWSP. This is currently the only around this, AFAIK. Hope this helps! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Text fill color in external SVG is not preserved
On 13 Jun 2011, at 21:50, honyk wrote: Hi Jan I use external graphics (SVG) in my FO document and when it is processed with FOP, color definition of some texts is ignored (they are black in the output). I can see the correct result in common browsers as well as in the Batik Squiggle utility. I think it is somehow connected to the transformation. Especially it happens at third sibling of the same group. Reduced SVG test case with FO file and final FOP output can be found at http://hroska.cz/other/test_case_fill.zip I use Fop - nightly build on Win7/64 bit + Java 6. Strange indeed. Thanks for the test case. I can confirm the issue on OS X / Java 6. I did a quick debug in o.a.f.svg.NativeTextPainter, and watching the GlyphVectors' TextPaintInfos, the fillPaint seems to be correct for all TextRuns. I do not have the time to dig deeper right now, but this definitely looks like a bug. Would you mind entering a Bugzilla report(*), and attaching your test case there, so we do not lose track of it? Thanks! (*) https://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop All the a, b, c, d labels should be red (first two are red, the rest is black) All the Text (1, 2, 3) should be white (first two are white, the third is black) Is there any workaround? None that I know of... Anyone? Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: How to determine which block are fo:table-row from XML-AT output?
On 10 Jun 2011, at 18:55, Christopher R. Maden wrote: Hi Chris On 06/10/2011 12:49 PM, Andreas L. Delmelle wrote: It does make perfect sense, but from FOP perspective, also poses the challenge of properly implementing id on fo:table-row... Since there is no area to attach the id to, we currently have no location in the area tree that ref-ids can point to. I hadn’t really thought about that. But IMO, the ID ought to attach to the first cell within the row. More generically, if any FO element has an ID but no area, the ID ought to attach to the first area generated by any of its descendants. Indeed! Just pondering over that here, too. Perhaps it's not that much of a challenge, after all. That raises the possibility of a single area having multiple IDs... is that a problem in PDF? I don't think this is an issue. As far as I recall, the id is only used internally to track locations on pages. As far as PDF is concerned, if the id is never referenced, it does not result in anything even being written to the stream (unless a fox:destination is used to externalize it). The area tree XML stores the specified id as a prod-id attribute. There can definitely be multiple areas with the same prod-id, as a block can be broken over multiple columns or pages. Since prod-id is FOP proprietary anyway, I don't immediately see anything against a convention of allowing this to be a separated list of producer-ids. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Hair ripping time
On 03 Jun 2011, at 16:30, Theresa Jayne Forster wrote: Hi Theresa Ok I cannot see what is wrong here,` snip / The app I am working on does this Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF,useragent,out); TransformerFactory factory = TransformerFactory.newInstance(); Transformer transformer = factory.newTransformer(new StreamSource(inputFO)); And it immediately jumps out when it hits the newTransformer() line…. ... because a FO file is not a valid stylesheet. Seems like you need: Transformer transformer = factory.newTransformer(); transformer.transform(new StreamSource(inputFO)); HTH! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Hair ripping time
On 03 Jun 2011, at 17:27, Theresa Jayne Forster wrote:
Hi Theresa
This makes no sense its crashing out with no error on this line
Fop fop = fopFactory.newFop(MimeConstants.MIME_PDF,useragent,out);
And it jumps straight to
System.out.print(*);
snip /
} catch (TransformerConfigurationException ex) {
ex.printStackTrace();
} catch (TransformerException ex) {
ex.printStackTrace();
} catch (FOPException ex) {
ex.printStackTrace();
} catch (FileNotFoundException ex) {
ex.printStackTrace();
} catch (IOException ex) {
ex.printStackTrace();
} catch (Exception ex) {
ex.printStackTrace();
Not as a general practice, but if all else fails:
} catch (Throwable t) {
t.printStackTrace();
}
Hopefully, that will reveal what is happening here.
Regards
Andreas
---
-
To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: how to do relative position
On 24 May 2011, at 19:39, Andreas L. Delmelle wrote: On 24 May 2011, at 13:55, Theresa Jayne Forster wrote: I am trying to do a multi section document where I have a “container” with absolute position and then the contents of the “container” are generated from a template call in the xsl to the same bit of code but with different contents, I have tried to use position=”relative” but it doesn’t seem to do as I would expect it to… snip / If you use position=absolute on the inner container as well, it should work as you expect, IIUC (?) In that case, the (0,0) coordinate for the inner container is then determined relative(!) to the containing reference area, which is that of the outer container. I suddenly realized this may have come across as confusing, so just thought I'd provide some further background on this: The position property is actually a shorthand, included in XSL-FO mainly for CSS compatibility. It maps to the native absolute-position and relative-position properties. (http://www.w3.org/TR/xsl/#absolute-position and #relative-position) One is implemented in FOP, the other is not, yet. (http://xmlgraphics.apache.org/fop/compliance.html) However, as pointed out, I believe you can solve your problem with absolute-position only, which _is_ supported. That is, unless I misunderstood your question (?) If the inner container is a child of the outer container, then relative-position would have virtually the same effect as absolute (except if there is content in the outer container, that follows the inner container *and* should be normally stacked...) The biggest difference between the two, is that block-containers with relative position remain part of the normal flow. They are only offset by the specified amounts during rendering. Their accumulated height still influences the layout of the following objects. Absolute-positioned containers, OTOH, are 'pulled' out of the flow, so to speak. The layout for the object after that container would just continue on the next line (= right after the content of the preceding sibling of the container). Also, just to manage expectations, note that an absolute-positioned container's content does not flow from one page to the next. Rather, the overflow, if any, will be handled in accordance with the 'overflow' property. From the Rec.: The following additional restrictions apply for paged presentations: * Only objects with absolute-position=auto may have page/column breaks. * For other values any keep and break properties are ignored. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: how to do relative position
On 24 May 2011, at 13:55, Theresa Jayne Forster wrote: Hi Theresa I am trying to do a multi section document where I have a “container” with absolute position and then the contents of the “container” are generated from a template call in the xsl to the same bit of code but with different contents, I have tried to use position=”relative” but it doesn’t seem to do as I would expect it to… snip / If you use position=absolute on the inner container as well, it should work as you expect, IIUC (?) In that case, the (0,0) coordinate for the inner container is then determined relative(!) to the containing reference area, which is that of the outer container. Hope this helps! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Can you mix page values in the same report?
On 09 May 2011, at 21:51, Eric Douglas wrote: Hi Eric Am I missing something? Is there a way to pass the page parameters as variables? I have an fo:flow nested inside a fo:page-sequence tag. The fo:page-sequence has a master-reference attribute which points to a master-name attribute of a fo:simple-page-master tag. snip / Is there any way to pass in variable values, to for instance say a 10 page report should have page 2 rotated 90 degrees? Yep, I think you're missing something... a quite useful core feature, no less. Take a look at fo:page-sequence-master[*], whose name can also be used for the master-reference. This allows you to go so far as specifying a separate, different simple-page-master for each and every page, or just use a different one for the first/last page or for odd/even pages, or for 'filler' blank pages that would be triggered by force-page-count, etc. [*] http://www.w3.org/TR/xsl/#fo_page-sequence-master Hope this helps! Regards Andreas - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fop 1.0: resolving relative Font URLs
On 14 Apr 2011, at 17:15, Ulrich Mayring wrote: Hi Ulrich Hm, maybe it's not a problem with the FOP code itself, but with the new version of xmlgraphics-commons included in FOP 1.0. At least there seems to be a new class called CommonURIResolve involved, which wasn't used in FOP 0.95. In that case, can you check what happens if you use a trailing slash in the embed-url? Strictly speaking, according to the RFC, if there is no trailing slash, the base URI (if you would use java.net.URI.resolve(), which CommonURIResolver does) would be the part up to and including the last slash. If one specifies '/my/absolute/path', then the base would be '/my/absolute/', so the 'path' subdirectory would not be included... I know FOP used to work around this as a convenience, since a lot of people appear to be unaware of that fact. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fop 1.0: resolving relative Font URLs
On 14 Apr 2011, at 17:28, Andreas L. Delmelle wrote: In that case, can you check what happens if you use a trailing slash in the embed-url? ^^ Errmm... Sorry, too quick. I obviously meant 'the font-base'. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: keep-together.within-line=always not working with inline and hyphenation
On 14 Apr 2011, at 15:14, Tobias Rettstadt wrote: Hi Tobias As I understand from the specification and previous posts, an inline with keep-together.within-line=always should prevent hyphenation of the containing text by ensuring that it is rendered on the same line. But that does not seem to work in my case: snip / Did I miss something or is this a bug in FOP for which I should file a bug reports? This is definitely a bug/defect. Looking at the code, if I judge correctly, there is no check on whether a keep-constraint is active when hyphenation is performed. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fop 1.0: resolving relative Font URLs
On 13 Apr 2011, at 17:33, Ulrich Mayring wrote: Hi Ulrich All I'm doing is replace fop-0.95.jar with fop-1.0.jar and our application ceases to work. Just a thought: it might be that the font-cache has also changed slightly between the two versions. Try adding a line to your code like fopFactory.getFontManager().setUseCache(false); If that works, the more permanent solution would be to delete and regenerate the font-cache to get everything to work as expected with 1.0. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fop 0.95: Generation of multiple PDFs on a single template
On 13 Apr 2011, at 13:37, JOSE L MARTINEZ-AVIAL wrote: Hi Jose We've been using FOP for a while to generate PDFs. Basicallly we generated a PDF for every one of our customers, so we have developed a procedure to generate a XML file for each customer, and then we generate the PDF invoking FOP with the XML and a templated. That's a long process, since we need to create the XML and invoke FOP for each customer. Is there any way a template can generated multiple PDF from a single file? As far as I know, you would definitely have to resort to a two-step approach. I see two possible routes: a) generate separate FOs for each customer: in XSLT 1.0 you will need an extension function for that, while with XSLT 2.0 you can use xsl:result-document to produce multiple result trees with a single stylesheet. Each of the FOs should then be processed with FOP separately. b) generate one FOP Intermediate Format(*) file, and process that output with a second stylesheet to separate the customer page-sets into individual IFs. Those can then each be fed to FOP, to arrive at roughly the same result as a). (*) see: http://xmlgraphics.apache.org/fop/1.0/intermediate.html Hope this helps! Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Fop 0.95: Generation of multiple PDFs on a single template
On 13 Apr 2011, at 18:51, Andreas L. Delmelle wrote: On 13 Apr 2011, at 13:37, JOSE L MARTINEZ-AVIAL wrote: ... That's a long process, since we need to create the XML and invoke FOP for each customer. snip / As far as I know, you would definitely have to resort to a two-step approach. I see two possible routes: Forgot to add the bottom line: there is currently no way to avoid invoking FOP multiple times if you need multiple outputs, unless by post-processing the PDF with another tool. Come to think of it, that could be a nice addition: a config option that triggers creation of separate PDFs for, say each fo:page-sequence... Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Series of hyphen in fo:block are bypassing wrap-option=wrap
On 07 Apr 2011, at 08:31, Prasanna wrote: Hi Prasanna, Series of hyphen chars are not getting wrapped with wrap-option=wrap. Any clue why this is happening? Some, but the most important one is probably that FOP implements Unicode line breaking rules, and Unicode UAX#14 does not allow breaking before characters of class HY (such as U+002D HYPHEN-MINUS). See: http://unicode.org/reports/tr14/#Algorithm and scroll down to find LB21 Do not break before hyphen-minus ... If you need a true line-wrapping effect, the usually suggested workaround is to inject ZWSP into the text, either at strategically chosen locations or between every two characters/hyphens. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: xslt 2.0 month name
On 06 Apr 2011, at 20:06, Chen Yang wrote: Hi Chen, I’m using xslt fn:formate-dateTime() to get the current date and time, for English it’s works fine. But everytime I try to get the month name in different languages(fr,de,etc),I will just get the current date and time with [Language: en] in the front and couldn’t get the month name in that language. This is a pure XPath/XSLT question, so is actually off-topic for this list. If someone readily knows the answer here, all the better, but you may want to raise this one the Mulberry XSLT list (http://www.mulberrytech.com/xsl/xsl-list/), or Saxon's user list, in case you need a quick response. I personally do not have the answer at hand, unfortunately. Hope this helps! Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: fop-hyph creates odd output
On 03 Apr 2011, at 16:12, Florian Apolloner wrote: Hi Florian Now the pdf output is fine for the block without hyphenation (the content after ---*infinity) but if I run it through hyphenation (the first block) it's completely broken (Especially compare the lines with linebreaks, eg the last three lines). I tried everything but I fail to find the error, any hints for me? This was still an issue in FOP 1.0, but has been fixed in FOP Trunk. See also: https://issues.apache.org/bugzilla/show_bug.cgi?id=38264 The only thing you can do in case you are stuck on 1.0, is not use linefeed-treatment=preserve in combination with hyphenation. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: OutOfMemoryException while transforming large XML to PDF
On 01 Apr 2011, at 13:13, Dennis van Zoerlandt wrote: Hi Dennis I will look further into modifying the XSL file in a such way multiple page-sequences are used. I think it's the best solution this far. Am I correct to say multiple page-sequences won't affect the definitive page lay-out of the PDF file? As Georg already pointed out, starting a new page-sequence is like inserting a forced page-break. A page-sequence should be seen as a chapter, i.e. isolated/separated from all other content. Depending on the exact use case, this might be impossible. If you absolutely need to have one continuous flow of 455 pages, increasing the heap would really be the _only_ way out. If you can live with some pages not being filled entirely, you can perhaps create new page-sequences at points where it makes sense to see a page-break in the output. How can I split up the content in multiple page-sequences? I think there's also a modification necessary in the XML input file? Not necessarily. If you really want to, you can already group your source nodes in there, obviously, but that grouping can probably also be coded into the XSLT. To find out more about grouping in XSLT, Google around some. There is lots and lots of info available about this on the web. Another question: is there a reliable way to 'predict' or calculate the page count the PDF file will have, before any transformation is started? Not really, unless the document structure is very simple and predictable. Otherwise, FOP will compute those page-breaks, so it's the chicken and the egg: you would need to process your document to know if you want to process it... In case of your test file, I can see that 11 of the detail tables (header: Status - Start - End Act no) fit together in one page, plus the static content. If the content is really that predictable, you could stop if your document would generate 1100 of those tables. At any rate, if there were a straightforward way to handle this for any arbitrary document, it would likely have already found its way into FOP. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: OutOfMemoryException while transforming large XML to PDF
On 01 Apr 2011, at 16:47, Eric Douglas wrote: I currently only have one fo:page-sequence tag in my xsl. How would auto page numbering with fo:page-number work otherwise? If you do not use the 'initial-page-number' property, the numbering for the next page-sequence just continues from where the previous one left off. In other words, by default, page-number does work across page-sequences. See also: http://www.w3.org/TR/xsl/#initial-page-number Is it possible the memory requirements could be reduced for extremely large documents by adding an option to swap some values out to temp files? Maybe save information in a file for each 100 pages? We already have a '-conserve' option on the command line, that results in pages being serialized to disk to avoid keeping them in memory, but that would likely not help in this particular situation. It is meant to be used in conjunction with multiple page-sequences if there are a lot of cross-references. That is a scenario where even multiple page-sequences might still consume too much memory for the remainder of the process to run smoothly. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: OutOfMemoryException while transforming large XML to PDF
On 01 Apr 2011, at 21:38, Eric Douglas wrote: I only reference the words page-sequence once. Is this the single page sequence problem you're talking about, or is my page loop referencing multiple page sequences? Your sample does have the potential to create large page-sequences, yes. It all depends on how many PAGE_DATA nodes you have. However, since those are basically already separate pages, if I understand correctly, you might fare better by generating a page-sequence around every 10 pages or so (i.e. plain grouping of the PAGE_DATA nodes by position). Nothing would change in the output, and you should be safe, whatever the actual amount of pages is. Your page-numbers and page-number-citations will just keep working as they do now. My input is already formatted so I know what goes on each page. I just need the pages connected for the page variable references with fo:page-number keeping track of the page count, and an fo:page-number-citation needing to know the number of the last page which I do with the empty block. Note: In FOP Trunk, using the empty block trick is no longer necessary for this case, as you can simply add an id to the fo:root and then use fo:page-number-citation-last wherever you need it. Come to think of it, the FAQ will need to be updated to reflect this... If the conserve option can help with memory use for very large reports I'll look for it, but I don't call it from the command line. My code is all embedded. In embedded code, you can activate it via: foUserAgent.setConserveMemoryPolicy(true); Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: OutOfMemoryException while transforming large XML to PDF
On 31 Mar 2011, at 15:08, Dennis van Zoerlandt wrote: Hi Dennis In the meanwhile I have tested a few things. In the attachment you'll find a FO file ( http://old.nabble.com/file/p31286241/fop1.0-5000-fo.zip fop1.0-5000-fo.zip ) which has scrambled data because of confidentiality. I created the FO file with XMLspy and tried to create a PDF file with Apache FOP 1.0 (fop.bat) on my Windows XP workstation. It produced (what it seems) this error (see below). No PDF file was created. It seems like the classic cram all content into one page-sequence issue. With a file of that size, there is little or nothing you can do. The current architecture of FOP does not allow to render such documents without a sufficiently large heap. That said: I wrote the above while I was running your sample file (with FOP Trunk, using Saxon as XSLT/JAXP implementation), and it just completed on my end, with a heap of 1GB. It did take about 7 minutes, but still... I got a nice output file of 455 pages. I doubt that it is related to images, as there is only one fo:external-graphic. Do you have font auto-detection enabled, by any chance? That might consume an unnecessary amount of heap space, for example, if you only actually use a handful of custom fonts, but have a large number of those installed on your system. Another option is that some fixes for memory-leaks, applied to Trunk after the 1.0 release, are actually helping here. Splitting the XML input file into several chunks is not a preferable option for me, nevertheless it is a valid one. Note: it is, strictly speaking, not necessary to split up the input so that you have several FOs. What would suffice is to modify the stylesheet, so that the content is divided over multiple page-sequences. If you can keep the size of the page-sequences down to, say, 30 to 40 pages, that might already reduce the overall memory usage significantly. There are known cases of people rendering documents of +10.000 pages. No problem, iff not all of those pages are generated by the same fo:page-sequence. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 30 Mar 2011, at 15:36, Eric Douglas wrote: Hi Eric I am talking about the first. Basically, it is a completely separate XSLT/JAXP implementation (TransformerFactory, Transformer etc.) Since you mentioned that the issue manifests itself only when using Oracle's Transformer implementation, a possible workaround/solution may be to use a different implementation. Note that Oracle's XML parser and XSLT processors are no strangers on this list, when it comes to weird, inexplicable bugs. Usually, the problem goes away if people switch to the latest Xerces in combination with Xalan or Saxon... Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 17:29, Eric Douglas wrote: Hi Eric I think this is what they mean by thread safe. I seem to have a concurrency issue. If I call a transform using the Fop handler with a PNGRenderer from 2 JVM sessions at or near the same time one crashes. I haven't been able to reproduce the problem so far with the PDFRenderer so either it doesn't have the issue or my timing is off on attempting to use it in 2 sessions at once. The answer is that the PDFRenderer is entirely under our control --and thus we are virtually certain it works well with concurrent runs--, while the PNGRenderer (and also other formats, like TIFF) relies heavily on Java2D and AWT. Those latter libraries are not thread-safe themselves, and not always used in a thread-safe manner in XMLGraphics and FOP... Do you have a stack trace to go with the crash? If yes, do the processes consistently fail on the same method call? If so, there is a chance that we might be able to offer a fix in the short term. Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 21:23, Eric Douglas wrote: It's actually crashing on the first transformer. It only crashes if I run 2 of these at once. Is there something obvious I'm missing in this java code? snip / Perhaps... We do not see the declaration of 'myTransformer'. Is that variable local to each thread? Transformers are definitely not thread-safe, so should be separate instances for multiple concurrent transformations. The TransformerFactory is thread-safe, so can be shared without issues. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 22:13, Eric Douglas wrote: I did include the new statement. The declaration is up at the class level. There should be one factory for the class and one transformer per instance. OK, that should be safe, indeed. snip / It's only when I run 2 at once the first transform crashes. That error message sounds like there was an error reading in the xsl file though the read statements didn't crash. Are both concurrent transformations trying to read the same XSL source file? As a crude attempt, perhaps you could try to synchronize the bare file access. I know some platforms have less of an issue with concurrent read-only access to files, but still... If that works and the use case allows it, there may be a more elegant/efficient solution, in the form of a call to TransformerFactory.newTemplates(). You can create one Templates instance for the same stylesheet, and instantiate multiple Transformers off of it. A Templates is also supposed to be thread-safe, so if you're always using the very same XSLT file, it can probably save you some overhead. Regards Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Thread safe?
On 29 Mar 2011, at 22:55, Eric Douglas wrote: I have yet to see any threading problems with the FOP objects. Well, there probably are /some/, but in general, care has been taken to make sure that each rendering-run is isolated, and the process itself is currently completely single-threaded (which does leave room for optimization on the one hand, extra debugging headaches on the other ;-)). Those parts that are meant to be shared among threads are usually properly synchronized, although glitches do pop up from time to time. Mostly in the Java2D/AWT area. Understandable, since the API docs do not mention anything about classes not being thread-safe, and often it concerns the real 'innards' of the JVM, and you'll find some sun.com classes in the stack trace, references to native methods, etc. Nothing we could have foreseen... My error seems to be just on Oracle's Transformer. Ahaaa!!! Them again! :-) So, you're saying it doesn't happen with, say, Saxon? Regards, Andreas --- - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: Making serialization documents in FOP
On Jan 16, 2008, at 18:27, Jay Bryant wrote: Hi I'm creating java servlet for making PDF file from xml and xslt files. It's possible making documents with 1000 pages or more ? How many memory i must have in my server to do this ? How long take generate this file ? I've created a system that makes 2,000-page documents with FOP. Those documents had only one image (a logo on the cover) and consisted entirely of tables that described the contents of databases. I've also created a system that makes more complex documents that exceed 700 pages. Those are software user guides that include images, tables, lists (bulleted and numbered), very deep levels of nesting (think list within table within list), and all the other fun things that technical writers will do to a document when you tell them the system can handle anything. So far, it has handled everything they throw at it. The machines running those processes (they are at two different companies) have 1GB of RAM (and I configured Java to use all of it), and both processes run in just about two minutes. Both of those processes are triggered by users calling Ant build files (either from Eclipse or from the command line), but I'm sure they'd run on a server (though it might need 2GB RAM instead of 1GB). You'd just have to train your users to not hit the Back button for two or three minutes. If it helps, in a client/server context, one would obviously want to fill those minutes with a combination of some fancy animation and client-side scripting. IIC, it should be perfectly possible to: - send an asynchronous request to a servlet (think AJAX) that creates a temporary PDF on the server; the servlet's response would be the URI for that file - while the request is processing on the server, display some animation, offer the user some more info (documentation, FAQs). Take care that any hyperlinks defined on the page actually redirect to a frame on the page itself, so the user can keep himself busy without leaving the page, or maybe even offer the option to have the end- result (or its URL) delivered by mail if finished. Offer links to additional servlets/applets/easter eggies for fun. ;-) - the onreadystatechange-handler for the asynchronous request then needs to do little more than magically uncover an IFRAME and set its src attribute to the URI that was returned The browser and its PDF plugin should handle the rest nicely, I think. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bullet points in japanese
From: [EMAIL PROTECTED]
Subject:Re: Bullet points in japanese
Date: January 16, 2008 20:19:25 GMT+01:00
To: [EMAIL PROTECTED]
Just noticed that I originally replied to Akagi off-list, but I think
the info might be useful to other users as well, so...
On Jan 16, 2008, at 11:23, Akagi Kobayashi wrote:
Hi Akagi
Indeed your reply helps.
We build in English and in Japanese. The bullet point appears
correctly for
English; in Japanese it leaves a blank, not #.
We don't have Symbol font installed in layout/fonts; only Arial,
IPAGothic,
etc.
So, in English, is the bullet point using the Arial font (as
specified in
the gentext en.xml file as #8226;)?
Can you give a little more context?
AFAICT, I see two possible scenarios:
a) the stylesheet determines only the codepoint to use for list-
bullets based on 'en.xml' or 'ja.xml'
Japanese - #x25CF;
English - #x2022;
b) the stylesheet determines both font-family and codepoint based on
those two files
If the choice of font-family is determined in the stylesheet, then it
becomes possible to have both languages render correctly, even with
FOP's current limitation.
If I changed Symbol to IPAGothic - like below - is there a risk of
skewing
up the English output?
Possibly. I don't have the IPAGothic font to test with, but if it
does not contain a glyph for both codepoints, then you risk
So, maybe what you have below needs to be supplemented with an
xsl:choose, that creates a font-family attribute with the right
value. I'm not sure how your stylesheet can reference the language
property, but let's say that's represented by '@xml:lang', then:
!-- Fallback font used for Unicode symbols such as right arrow --
xsl:param name=symbol.font.family
select='IPAGothic,Symbol,ZapfDingbats,LucidaUnicode' /
This will make sure that all templates that use this parameter, will
use that font-family list.
Only, as mentioned, FOP would eventually only use the 'IPAGothic' font.
Maybe you would need something like:
xsl:param name=symbol.font.family
xsl:choose
xsl:when test=starts-with(@xml:lang, 'en')'Arial'/xsl:when
xsl:when test=starts-with(@xml:lang, 'ja')'IPAGothic'/
xsl:when
...
/xsl:choose
/xsl:param
xsl:template match=[EMAIL PROTECTED] = 'symbolfont']
fo:inline font-family=IPAGothic
xsl:call-template name=inline.charseq /
/fo:inline
/xsl:template
This template is unrelated to the above parameter. It would force all
symbol role=symbolfont nodes in the source document to use the
IPAGothic font, so depending on the context, it could be safer/
cleaner to make it use that xsl:param.
xsl:template match=[EMAIL PROTECTED]'symbolfont']
fo:inline font-family={$symbol.font.family}
xsl:call-template name=inline.charseq /
/fo:inline
/xsl:template
!!! Be careful if the parameter is global, and the fo:inline could be
in a different language. In that case, it may become necessary to
redo the xsl:choose locally in the template to obtain the correct
effect.
HTH!
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: last-line-end-indent in 0.94
On Jan 15, 2008, at 17:26, Amick, Eric wrote: Hi It appears that FOP 0.94 treats negative values for last-line-end- indent as 0, which is wrong. Non-negative values produce the expected results. That seems like a bug indeed. The XSL-FO 1.1 Recommendation clearly states that 'Positive values indent the edge, negative values outdent the edge' (from 7.16.3 last- line-end-indent) If you don't mind, please record this in Bugzilla (http:// issues.apache.org/bugzilla/), so we don't lose track of this. Thanks! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: language specification for PDF document
On Jan 15, 2008, at 20:37, Li, Hao wrote: Hi I followed your instruction to generate the pdf. After I open it in acrobat, under file-document properties-advanced-reading options, the language option is still blank. Am I missing something? As far as I know, the 'language' property is used by FOP *only* for determining the hyphenation pattern file to use (if hyphenation is enabled). I don't think that the property is used for anything else (and so, will not yet be reflected in the document properties) It's probably not too difficult to implement (given enough time and enough knowledge about the PDF Specification). Patches are always welcome. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: language specification for PDF document
On Jan 15, 2008, at 21:29, Li, Hao wrote: Hi Is this document level language identifier part of XSL-FO standard and its usage is fo:root language=en like Chris suggested? Or can it be xml:lang attribute? The xml:lang 'attribute' in XSL-FO is classified as a shorthand (http://www.w3.org/TR/xsl11/#xml.lang), and as such, in theory it could be used to set the native XSL-FO 'language' property (but at the same time also 'country' and 'script', if applicable). In practice, this shorthand is not-yet-implemented in FOP (http:// xmlgraphics.apache.org/fop/compliance.html#fo-property-xml:lang). Even if it would be, it would still suffer the same limitations as the 'language' property. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rendering time configuration settings using fo:declarations
On Jan 15, 2008, at 18:11, Adrian Cumiskey wrote: Hi A thought occurred to me whilst implementing something and I thought I would share it with you.. I don't have time to implement this but maybe somebody else would like to pick up this idea/ suggestion... Basically, I was wondering if anyone thought it would be a useful feature to be able to provide renderer configuration settings within the fo:declarations section of an FO document? Splendid idea to post it here. I sure do hope it reaches the right person for the job. These settings could resemble and override any user configuration settings that may have been set at startup time through the API or user configuration file (e.g. fop.xconf). So the top of your FO document might look something like the following :- fo:root xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:declarations fox:strict-validationtrue/fox:strict-validation Basically a cool idea, but I would not put it in the default extension namespace. Instead, we could reserve a special FOP-config namespace for it. Definitely seems to have a lot of potential to be able to include the configurable settings at the XSLT stage, if desired. Those using Saxon 8-SA, could then have that config file validated against the fop-configuration.xsd at runtime. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Text Formatting Problem
On Jan 15, 2008, at 18:03, Amick, Eric wrote: Hi I have a three-column listing of phone numbers, and most of the time, each column entry has only one line of text. Sometimes, however, I have entries that look like this: Text that spans two lines ... 9 More text that spans two lines In case the format gets garbled, the number in the second column should line up with the last line of text in the first column and the first line of text in the third column. I've tried using display-align and vertical-align, but I can't come up with a way that works. Does anyone have any suggestions? Can you post the FO-snippet you currently have? I was thinking something like (only works in case you always have three lines, and they're all in the same font-size): fo:table fo:table-column column-width=proportional-column-width(2) / fo:table-column column-width=proportional-column-width(1) / fo:table-column column-width=proportional-column-width(2) / fo:table-body fo:table-cell starts-row=true display-align=before fo:blockText that spans two lines .. /fo:block /fo:table-cell fo:table-cell display-align=center fo:block9/fo:block /fo:table-cell fo:table-cell ends-row=true display-align=after fo:blockMore text that spans two lines/fo:block /fo:table-cell /fo:table-body /fo:table Another way to achieve something similar, would be by means of fo:block-containers (implemented) or fo:inline-containers (unimplemented, but being worked on). The display-align properties do not apply to fo:block or fo:inline. Maybe that's the reason why it doesn't work for you (? remote guess) HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: language specification for PDF document
On Jan 15, 2008, at 23:36, Li, Hao wrote: Hi Henry Does it mean that the implementation will be Apache FOP specific, because there is no such XSL-FO standard property for document level language of PDF? Basically: yes. There is no connection/obligation of a FO processor to any particular output format, like PDF or PostScript. Also, it is currently unimplemented at the moment, so should someone decide to have a shot at implementing it, and he does not know what AntennaHouse or RenderX do with the related properties (language/ country/script), then it is very likely that an eventual implementation will be specific to Apache FOP. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TransformerException: fo:page-sequence is not a valid child element of fo:flow
On Jan 14, 2008, at 18:18, Andreas L Delmelle wrote: On Jan 14, 2008, at 05:48, Travis Staloch wrote: Hi I'm trying to use fop along with xsltproc to create a pdf from docbook xml. xsltproc successfully creates an fo document with the command: xsltproc /usr/share/sgml/docbook/xsl-stylesheets-1.73.2-2.fc8/fo/ docbook.xsl my.book sf.fo However, when I run the fop command: fop sf.fo -pdf sf.pdf I get the error: SEVERE: Exception javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: file:///home/trav/open/ SportsFeed/doc/help/docbook/sf.fo:1:56740: Error(1/56740): fo:page- sequence is not a valid child element of fo:flow. at org.apache.fop.cli.InputHandler.transformTo (InputHandler.java:168) at org.apache.fop.cli.InputHandler.renderTo (InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Can anyone provide any guidance on what might be going wrong? I have fop 0.94 with java version 1.4.2_16. I've attached the fo document. When I looked at the fo document, I couldn't find any fo:page- sequence elements which were children of fo:flow. So I'm not really sure what the problem is. What it says: you do have a fo:page-sequence that is a child of an fo:flow. I checked this via XPath, and you have 4 page-sequences. 3 of which are correct - children of the fo:root, and 1 that ended up in the wrong place. No idea if it will help you much in tracking it down, but if I apply indenting to make your FO a bit more human-readable, the offending fo:page-sequence starts on line 1066. Update: in the file you sent, the offending fo:page-sequence can be found at line 1, column 57323. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Bullet points in japanese
On Jan 14, 2008, at 16:17, Akagi Kobayashi wrote: Hi Could you help me set the IPAGothic font as the font for the list - so that the bullets show? Bullets in IPAGothic (and in MS fonts) are #12539; (#x2022 doesn't work for me.). Setting the bullet in common/ja.xml l:dingbat key=bullet text=#9679;/ as such doesn't work. In the custom stylesheet, we have the following section: !-- Fallback font used for Unicode symbols such as right arrow -- xsl:param name=symbol.font.family select='Symbol,ZapfDingbats,LucidaUnicode' / I'm afraid that, as long as you don't specify the correct font-family as the first one, you won't get your bullets... :( Reason is that font-selection-strategy is unimplemented for now. FOP only looks at the first font-family (Symbol), and if that font does not have a glyph for that codepoint, then you get the dreaded '#' in your PDF... xsl:template match=[EMAIL PROTECTED] = 'symbolfont'] fo:inline font-family=Symbol xsl:call-template name=inline.charseq / /fo:inline /xsl:template I tried adding the font name after LucindaUnicode, but that didn't work! As stated above: it won't work, unless the 'IPAGothic' font is the first one in the list (only the first font-family is used). HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: TransformerException: fo:page-sequence is not a valid child element of fo:flow
On Jan 14, 2008, at 05:48, Travis Staloch wrote: Hi I'm trying to use fop along with xsltproc to create a pdf from docbook xml. xsltproc successfully creates an fo document with the command: xsltproc /usr/share/sgml/docbook/xsl-stylesheets-1.73.2-2.fc8/fo/ docbook.xsl my.book sf.fo However, when I run the fop command: fop sf.fo -pdf sf.pdf I get the error: SEVERE: Exception javax.xml.transform.TransformerException: org.apache.fop.fo.ValidationException: file:///home/trav/open/ SportsFeed/doc/help/docbook/sf.fo:1:56740: Error(1/56740): fo:page- sequence is not a valid child element of fo:flow. at org.apache.fop.cli.InputHandler.transformTo (InputHandler.java:168) at org.apache.fop.cli.InputHandler.renderTo (InputHandler.java:115) at org.apache.fop.cli.Main.startFOP(Main.java:166) at org.apache.fop.cli.Main.main(Main.java:197) Can anyone provide any guidance on what might be going wrong? I have fop 0.94 with java version 1.4.2_16. I've attached the fo document. When I looked at the fo document, I couldn't find any fo:page- sequence elements which were children of fo:flow. So I'm not really sure what the problem is. What it says: you do have a fo:page-sequence that is a child of an fo:flow. I checked this via XPath, and you have 4 page-sequences. 3 of which are correct - children of the fo:root, and 1 that ended up in the wrong place. No idea if it will help you much in tracking it down, but if I apply indenting to make your FO a bit more human-readable, the offending fo:page-sequence starts on line 1066. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How navigate/scroll inside the PreviewPanel
On Jan 10, 2008, at 20:00, Giulio Buccini wrote: Hi Giulio I know: I wrote about MY requirements from MY point view... probably everyone have a different view about that and is pretty impossible to make everybody happy. I understand this... Of course, but it is always interesting to see those different views posted here. Who knows, maybe other users have similar thoughts/needs, but have so far refrained from speaking up (since they already knew, more or less, what the answer would be). snip / Microsoft Word is massively used inside big organizations, and the base concept is WYSIWG. So, if you develop a desktop application for an employe you will receive the -unsolited- question: why what I see on the screen is not what I see when I print document or when I send it by email? Why application cannot show me the final result in real time when I work on data? Word is doing that! (I cannot describe my face in similar situations... when I was working for SIEMENS this was one of the most frequent questions...) Sure, and OpenOffice has a word-processor too, and it's also completely free of any charge. The big difference with XSL formatters, is that they are not word- processors, but should rather be compared to web-browsers. A WYSIWYG XSL-FO application would be much more like an HTML editor, and AFAIK, in most HTML editors, you don't really edit the page on-the-fly. You alter the source code, and the document is re-rendered using as much cached information as possible. Another huge blocker is that the transformation is far from always easily reversible. Creating /the/ XSL-FO source for a given PDF document is impossible, unless the PDF would contain a reference to it. For a given printed layout, there are always at least a handful of ways to describe/define it in FO. An XSL-FO document is more comparable to Tex than to Word's .doc. Looking at PDF in particular, PDF editors are also not word- processors. You cannot create a blank document, or alter an existing one, in the same sense as you would with Word. iText, for example, mentions in the manual somewhere that you cannot really replace text in the PDF using the iText API, but you would have to create a new text box containing the replacement and place that over what needs to be replaced. (If I recall correctly... it's been a while since I read that; maybe this has already been changed in the meantime) PDF is, OTOH, probably *the* most suited format for getting a uniform result whether viewed on the screen or printed on paper. But I think people are right: documents are not for technicians like you and me, documents are for people. Must be readble, well formatted, colored and attractive. XSL-FO offer all instruments to create beatiful documents but... you cannot easily integrate them in a desktop application. That depends on what output format you choose. If you choose RTF, then you /can/ edit the end result in MS Word, but you have the downside that RTF is not 'Rich' enough to cover every aspect of the Recommendation, and due to that, we're again stuck with the impossibility to create /the/ XSL-FO document corresponding to /an/ RTF. I have used yet FOP during my work, and it was always the final step after a lot of elaboration: the printing/email step. Batik project offers a big support for application integration: the JSVGCanvas class and the SVGGraphics2D generator class. iText offers something similar for PDF... so I think my requirements are not so much far from the real world. Indeed, but I think the point is more: If one needs a word-processor - Word or an OO-spinoff If you need a WYSIWYG PDF editor - Acrobat or ...? If you need a WYSIWYG FO editor - Altova, oXygen, Scriptura come to mind. If I recall correctly, they all integrate FOP in some way... some do it merely by initiating a batch process, but it is possible to use only parts of FOP, if one wants. You are definitely right, that the public API is somewhat limited ATM, and the rest of the source code is currently not very friendly unless you spend quite a bit of time familiarizing yourself with it. There is no easy way to access elements of the FO document on the controller layer, as it were. FOP's design is currently based on whole-document transformations. We would need quite a bit of changes to perform a 'live' atomic re-rendering of a fo:block that is being edited, for example. Currently, there is no completely free FO editor (IIC). Only commercial implementations, using a free XSL formatter in the background. I was seriously thinking to be involved in the enhancement of the AWTViewer, but for now I have no time at all. That's unfortunate to hear. I can imagine the big effort caming from the implementation of the XSL-FO specifications... I absolutely understand you; but, as I repeat, for now I cannot be involved in the FOP project even if I like your
Re: 508 compliance
On Jan 9, 2008, at 18:56, Li, Hao wrote: Hi there, Does anyone know if the PDF generated by fop 0.93 is 508 compliant or FOP does the effort to make it 508 compliant? Honestly, I had no idea what is meant by 508 compliance to begin with. For all those who are interested: http://www.section508.gov/ Or is it something relevant to the xml before the transformation not FOP? At first glance, it seems to be something that applies to accessibility of information in general (is not restricted to printed media). From what I can tell immediately, I don't think this 508 compliance holds for documents generated by FOP. Note that the 'Common Accessibility' properties, as defined by the XSL Rec, are for the largest part unimplemented in FOP at the moment. KR Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 508 compliance
On Jan 9, 2008, at 20:51, Christopher R. Maden wrote: On Wed, 2008-01-09 at 20:29 +0100, Andreas L Delmelle wrote: At first glance, it seems to be something that applies to accessibility of information in general (is not restricted to printed media). Yes. It would be better to make the information available in the PDF available in other formats as well. This was kind of the point of XML and XSL: provide your information via multiple channels. Note that the 'Common Accessibility' properties, as defined by the XSL Rec, are for the largest part unimplemented in FOP at the moment. I’m honestly not sure what FOP would do with them, anyway. A single XSL stylesheet might say that emphasis should be both bold and loud, but I would expect a print formatter to ignore the loudness just as I would expect an audio formatter to ignore the boldness. OK. What I meant was more that, some PDF viewers offer room for both. Adobe Reader has a 'Read Out Loud' option, which is available for PDFs generated by FOP. What I do know for certain is that FOP currently simply ignores the applicable properties, while in theory, it seems that the PDF renderer could actually do something with those. Maybe Adobe Reader could make use of XSL's accessibility properties, if FOP generated extra info in its PDFs. Right now, reading a page out loud is still a quite monotonous experience (worse than the average lecture in a university or parliament ;-)) And then, there is of course the possibility of someone coming up with an AudioRenderer that renders the input document to a series of standard audio output formats, on top of the current output formats. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 508 compliance
On Jan 9, 2008, at 20:53, Li, Hao wrote: Thanks Andreas. Yes. It is about accessibility. Although the pdf can be generated, the customer does not like it because of accessibility issues, for example: missing PDF tags, lacking language specification etc. After searching about tagged pdf, I found http://xmlgraphics.apache.org/fop/trunk/pdfa.html. It seems that PDF/A-1b is implemented, but not PDF/A-1a. Does it mean tagged PDF is not supported yet? Indeed. I know Jeremias recently mentioned tagged PDF as a (rather long term) goal, so there is definitely interest from other parties in adding this functionality as well. I will be testing it as well. If not, do you happen to know nay java plugin or product that can make accessible FO conversion? Maybe you can have a look at post-processors, like iText (http:// www.lowagie.com/iText/) or PDFBox (http://www.pdfbox.org/). They can be used in conjunction with FOP in a fairly straightforward manner. Use FOP to generate the basic PDF, and feed the output to the post-processor for further enhancements. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: attributes of block
On Jan 2, 2008, at 18:36, irene23 wrote: Hi, Since this is my first post of the year: Best Wishes for 2008 to the whole FOP community! Now as to your question, and Pascal's reply: I´m using xsl-region-after in this way: I have two page-masters defined, with one having a different footer than the other. When this renders to a 2+ page document, the last page gets the last footer and the other pages get the other footer. When it renders to a 1 page document, I get the any page footer, even though the the page is the last page I've posted on nabble.com, and gotten replies that it is possibly a bug. So, I think I can´t use a xsl-region-after in this way. But you are telling me that I can use xsl-region-after using fo:marker/fo:retrieve-marker, (if the content depends on flow), Could you tell me what is fo:marker? (I need put a signature, at the end of the body, in the last page - not in any other- and if the document has only 1 page must have the signature) The idea is roughly: You can put the signature in a single fo:marker that is attached to (= appears as initial descendant of) ONLY the last fo:block in the document. Use a dummy block as a wrapper for the fo:marker if the body text is not split up in multiple blocks. The corresponding fo:retrieve-marker will only find something to retrieve on the page where that last fo:block ends up. No matter which page-master is currently in use (you could use the same one for all pages). Analogously, as Pascal suggested, the signature can be put in an fo:footnote that is attached to the last block. Take care here: as opposed to an fo:marker, which has to appear as an initial descendant, the fo:footnote should preferably be placed completely at the end of the last block. If not, then if that last block gets broken over the last two pages, it is possible that the footnote/signature gets rendered on the next- to-last page. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: attributes of block
On Jan 2, 2008, at 19:35, irene23 wrote: Hi snip / - Is this what you want to tell me? The attributes retrieve-position, retrieve-boundary are correct? Yes, exactly. - But in the fo:simple-page-master fo:region-after region- name=footer extent=1.50in/ . /fo:simple-page-master I must put a space (extent) for the footer and all pages would have this space and I want that only the last page have the footer signature (the rest of the pages have other footer, not the footer signature), so the fo:retrieve-marker go in fo:static-content flow-name=xsl-region-after??? Indeed, that is one of the drawbacks of the approach using fo:marker/ fo:retrieve-marker In your case, it's probably a better choice to go for the approach using a fo:footnote, as this will always be rendered in a separate 'static-content' between the region-body and the region-after (if any). HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Image rendering at position problem
On Jan 2, 2008, at 18:58, Glenn Brand wrote: Hi, I am trying to place a graphic (customer logo) to the right of a table at the top of a patient walk out statement of account. When I put the graphic on the style sheet editor (stylus studio2008) it looks correct but when it gets published as XSL-FO and then rendered it is placed underneath the table. How can I get it to go to the right of the table? fo:table width=225pt border-style=none border-width=0pt background-repeat=repeat snip / /fo:table fo:external-graphic background=transparent width=200pt height=200ptsrc=url(file:///c:/CacheSys/CSP/qacahaba/ ODprofessional_logo.gif)/ Correct: a fo:table is a block-level formatting object, and as such triggers implicit line-breaks before and after. To do what you have in mind --keep a table on the same line as a following sibling inline-level FO, like external-graphic-- I think you would need support for either fo:float or fo:inline-container. Neither of these are implemented in FOP at the moment. As a workaround, you could try nesting tables (or put the external- graphic in its own last column in a cell that spans all rows). HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Filling a table cell entirely with an external graphic
On Jan 3, 2008, at 02:07, Tim Gates wrote: Hi, I have a series of problems which can be broken down into one problem in that I don't understand how to eliminate the implicit padding associated with an external graphic inside a table. If I try and create 4 images side by side then there is a gap between the top two images and the bottom two images using a variation of the basic FO below... fo:table table-layout=fixed fo:table-column column-width=50mm / fo:table-column column-width=50mm / fo:table-body fo:table-row fo:table-cellfo:blockfo:external-graphic content- width=50mm content-height=50mm src=test.png//fo:block/ fo:table-cell fo:table-cellfo:blockfo:external-graphic content- width=50mm content-height=50mm src=test.png//fo:block/ fo:table-cell /fo:table-row fo:table-row fo:table-cellfo:blockfo:external-graphic content- width=50mm content-height=50mm src=test.png//fo:block/ fo:table-cell fo:table-cellfo:blockfo:external-graphic content- width=50mm content-height=50mm src=test.png//fo:block/ fo:table-cell /fo:table-row /fo:table-body /fo:table I've tried adjusting margins, space and padding and setting them to zero on pretty much every XML element (which I've removed from the above for clarity). Does anyone know how to eliminate the padding to produce the 4 images side by side without resorting to setting the images as background images? If I remember correctly, this is a result of what is called 'half- leading', i.e. each line in a block has a leading and trailing whitespace (before and after) with an extent equal to a percentage of the line-height for the block in question. Something like the following should work: fo:table line-height=0pt ... etc. Since line-height is inherited by all the table descendants, half- leading will be equal to zero for the lines generated by the cells/ blocks, and the spurious whitespace between the graphics should disappear. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fop 0.94 (Docbook and tables)
On Dec 21, 2007, at 10:31, [EMAIL PROTECTED] wrote: Hi I am trying to upgrade from fop 0.20.5 to 0.94 and in conjunction with DocBook (1.70.1) found out that there is a irritating change in operations regarding table processing. When processing tables they: 1 Don´t cross pages (e.g if a table doesn´t fit on the current page it is rendered on the the next page) and Can you check the resulting FO, and whether it uses the 'keep- together' property on the table? If so, this will somehow have to be removed. No precise idea on how to achieve that, but it should be a matter of adding a customization to the Docbook stylesheet. 2 If a table is too large to fit a page it will get corrupted (with an error message: WARNING: Content of the region-body on page n overflows the available area in block-progression dimension. (fo:page-sequence, no context info available)) What do you mean exactly by 'corrupted'? FOP 0.94 interprets keep- values of always literally as without exception, or if the content does not fit, it will be clipped. Chained 'keep-with-next' and 'keep-with-previous' on the rows will have the same effect: FOP will try to keep the whole table together on a single page. Your best bet is to remove the keep-*=always properties from being added. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hyphenation-character doesn't appear in pdf
On Dec 21, 2007, at 09:16, Jeremias Maerki wrote: Hi Right, as soon as you enable white-space-treatment=preserve the hyphenation-character is just ignored. Otherwise, the hyphenation character works fine. Can you please open an issue in Bugzilla and add your files there? We'll have to look into this. http://issues.apache.org/bugzilla/ Filing a bug is not necessary. Vincent recently added this issue to an open Bugzilla entry that already indicates there are still problems with hyphenation in combination with preserved linefeeds/ white-space. see: http://issues.apache.org/bugzilla/show_bug.cgi?id=38264 Unfortunately, I could not come up with a work-around. On 20.12.2007 21:37:19 Xuan Ngo wrote: snip / xsl:attribute-set name=monospace.verbatim.properties use-attribute-sets=verbatim.properties monospace.properties xsl:attribute name=wrap-optionwrap/xsl:attribute xsl:attribute name=hyphenation-character\/xsl:attribute /xsl:attribute-set Maybe it's possible to tweak/customize one of the above referenced attribute set(s), so it does not generate a white-space- treatment=preserve in the result. That is: if you really don't need preserved white-space around linefeeds. Best browse around on the Docbook site, or ask on the Docbook list, unless there's a guru hanging out here that can tell you how. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Servlet Performance Problem
On Dec 3, 2007, at 13:12, Noya Paolo wrote: Hi Andreas thanks for your reply, the XML is very little (ranging from 50 to 250 nodes with size less than 10Kb) that change it with a BufferedReader or even using a DOMSource (I already parse XML elsewhere) not give me a real gain. Maybe a 1 or 2 seconds but I'm not sure because could be depends on different loads on server and so isn't really noticeable. I changed my code anyway OK, sorry. The effect I mentioned is actually more applicable to FileReader or InputStreamReader. Reading a String happens in-memory, so that will indeed not save very much... :/ I wouldn't really know where to start looking. I'd try to profile one of those runs on the servlet, to try to find out where the bulk of the runtime is spent. Other than that, if you don't feel like profiling, you could try to change the environment. Try using a different XML parser or a different XSLT processor, just to ascertain that the problem is really in FOP or whether FOP is simply waiting for some other process. You could even try to use a different JVM, or a different servlet container (Tomcat?)... Anything that helps to locate the problem. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP creates only blank pages
On Dec 2, 2007, at 22:27, Michael Siepmann wrote: Hi Michael snip Very long shot, but could it have something to do with the encryption? Can you try commenting out the following line: userAgent.getRendererOptions().put(encryption-params, new PDFEncryptionParams(null, null, true, false, false, false)); As I've said before: the code with the userAgent can be removed. My first version was without this code and with the same result. One more thing to check (don't know if you already took that step): Are you certain that the FO that gets passed to FOP (= the result of the XSL transformation) is identical in both cases? If there is nothing in the FO but two fo:page-sequences with one empty fo:block, this could explain the two empty pages. Via the command-line, you can obtain the FO through the '-foout' command-line option. You could then try testing the servlet by passing it that FO and an XSLT stylesheet performing an identity transform. Another option is to alter the servlet to dump the intermediate FO to a file, so you can inspect it. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP Servlet Performance Problem
On Nov 28, 2007, at 16:46, Noya Paolo wrote: Hi Sorry for the late reply. As Jeremias already indicated, profiling is one option. There are various tools and there is lots of documentation available on the internet concerning profiling of the JVM. Just Google around for 'java profiling' and that should help you on your way. Other than that, I see one possible cause for your issue: snip / Source src = new StreamSource(new StringReader(theXML)); While there is nothing inherently wrong about the above, depending on the implementation of StreamSource it is possible that this causes underlying calls to StringReader.read() instead of StringReader.read (char[], int, int), which means that your source XML gets read in one character at a time, which in turn would cause a noticeable slowdown... No idea if it would help here, but maybe one of my first tries would be: Source src = new StreamSource(new BufferedReader(new StringReader (theXML))); HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: FOP creates only blank pages
On Nov 30, 2007, at 11:45, Michael Siepmann wrote: Hi we have a content management system, which can create FO and with the help of FOP PDF. The system uses an Apache Tomcat 5 and we have used FOP 0.20. This combination works. But now, I've switched to FOP 0.94 and changed the code which creates the PDF. At this moment, FOP only creates white pages without any text. The number of pages is correct, for example when I create a FO with 2 pages, 2 pages will be in the PDF, but all are white. The FO-Code is still ok, which can be demonstrated by copying the FO-Code to a special test-program. Even the new code, which is copied to this test-program. But I don't see the problem, why the same code doesn't work inside the Tomcat. snip / Very long shot, but could it have something to do with the encryption? Can you try commenting out the following line: userAgent.getRendererOptions().put(encryption-params, new PDFEncryptionParams(null, null, true, false, false, false)); Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: anything wrong with this XSL snippet
On Nov 30, 2007, at 19:00, Daling Xu wrote: Hi I am using FOP to generate PDF from an XML doc. In my PDF, I would like to insert image in some places, but because not every time I have an image for all the element in the xml, I use a XSL:If statement like this way: fo:block xsl:if test=@statusImageURLfo:external-graphic src=[EMAIL PROTECTED]//xsl:if xsl:value-of select=@status/ /fo:block snip / Any idea what's wrong with my XSLT? Nothing inherently wrong about it. Are you *absolutely* certain the source does *not* contain the attribute (not even an empty one)? Another (very remote) possibility: Does the source XML contain a reference to a DTD, perhaps? Not 100% certain, but I seem to remember having seen this once: an empty attribute being added due to DTD validation. If the attribute is not defined as #IMPLIED, but with a default value of (empty string), then it could be added by the XML parser, so we wouldn't see it in the source, but the XSLT processor would. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: create FONode objects directly and generate PDF file
On Nov 21, 2007, at 20:57, Daling Xu wrote: Hi I fully understand the process of from Java Obj -- xml -- Fo file -- PDF and already made it work in my application. But is it possible directly create FONode objects, e.g. Flow, Table in my java code and then call a FOP api (maybe a Renderer or something) to generate a PDF file from the root FONode object? I guess it is possible, but FOP's API is not designed to facilitate such an approach, so even if it can be done, it might turn out to be more trouble than it's worth. It's definitely not documented anywhere, so you would be on your own. I am thinking this way because my data are in java object, then write a method to generate XML and create a XSLT file, all these steps could bring in complication and bug, why not directly generate the FO objects and generate the PDF, anyway I know which object in my data should generate what kind of things in my PDF. Yours is a valid point, but on the other hand, generating FO directly from Java also has its drawbacks. I think one of the key disadvantages is that you will end up writing a significant amount of proprietary code/classes for tasks/processes for which there are well- established standards (XML, XSLT...). You would indeed reduce the number of steps, and possibly the number of bugs, but those bugs that do pop up will be far more difficult to track, if I judge correctly. After all, look at it this way: the specification is called 'XSL-FO' and not plain 'FO'. It is precisely meant to be used in conjunction with XSLT to transform semantic XML input. Compare it with HTML: it's possible to not use CSS at all, and apply all styling manually, but by doing so, you are giving up the advantage of keeping all style-related information nicely separated from the content. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to embed svg to fop?
On Nov 20, 2007, at 09:10, m_dieu wrote: Hi snip / And my attempt to include this into a fop looks like this: fo:block fo:instream-foreign-object svg:svg width=170mm height=130mm xmlns:xlink=http://www.w3.org/2000/svg; ^^ You might want to bind the SVG namespace to the svg: prefix. That should solve the error below. snip / But when I wants to generate the pdf I get this error: [Fatal Error] :1:32817: The prefix svg for element svg:svg is not bound. System-ID unbekannt; Zeilennummer1; Spaltennummer32817; org.xml.sax.SAXParseException: The prefix svg for element svg:svg is not bound. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mac Font problem
On Nov 20, 2007, at 09:05, Raphael Parree wrote:
Andreas,
That solved it for now... tx.
When I have time I will try to find out the cause...
FWIW, and to whom it may concern: the limitation, I think, is caused
by the following in org.apache.fop.fonts.TTFFile line 225 and following
===
if (cmapPID == 3 cmapEID == 1) {
cmapUniOffset = cmapOffset;
}
}
if (cmapUniOffset = 0) {
log.fatal(Unicode cmap table not present);
log.fatal(Unsupported format: Aborting);
return false;
}
===
I looked at the docs available on developer.apple.com (amongst
others: http://developer.apple.com/textfonts/TTRefMan/RM06/
Chap6name.html#ID), and it seems that the above means that we
currently only support CMAPs with a PlatformID of 3 (= Microsoft).
I'll see shortly if changing this helps to support Mac TrueType fonts.
Cheers
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Mac Font problem
On Nov 20, 2007, at 07:56, Raphael Parree wrote: Hi I have a problem with a font on a Mac…on my PC everything seems to work but on the Macs uses by our publishing department the Courier New font does not work. It is installed on the Mac (True Type font). I am working with rev 592554 (6 nov) and use the auto detect feature. I have tried deleting the cache file as that often helps on ,my PC after using new fonts or updating FOP. I saw some posts about true type fonts on a Mac posted in feb 2006 (http:// www.nabble.com/TTFReader-and-MacOsX-.ttf-fonts- tf1139715.html#a2986169) I'm also on Mac, and noticed the same effect. Haven't looked into the exact cause, though... One possible workaround, until someone decides to get to the bottom of this: Mac OS X also supports Windows TTFs, so in the worst case, you could maybe try to replace the native Mac TTF with the Windows TTF. Untested though, can't say for sure it will work. HTH! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BreakingAlgorithm Problem
On Nov 16, 2007, at 09:29, fma-001 wrote:
Hi
thanks for your hint. I wrote a template, which checks if there are
some
non-letter-characters (like '.', '/'; etc.). If this is the case, I
concat
the string after each character with Unicode Zero Width Space
('#x200B;'),
but then FOP 0.93 overlaps letters. I also tried FIGURE SPACE
('x#2007;'),
but then FOP does break it half way ... very strange. Here my code
snippet:
xsl:variable name=sNew
xsl:for-each select=0 to string-length($s)
xsl:value-of select=concat(substring($s,.,1), '#x200B;')/
/xsl:for-each
/xsl:variable
xsl:copy-of select=$sNew/
Any idea, why FOP0.93 is doing it that way?
Yes, this was a bug in 0.93 IIRC. Upgrading to 0.94 should resolve
the issue.
HTH!
Andreas
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
On Nov 14, 2007, at 13:24, Michael Tracey Zellmann wrote: Hi Sorry for the late reply... Thanks for the response. I am trying to think of a way to still succeed. What I want to do is to send all logging messages from anything related to FOP to their own file. In the logging.properties, I tried: org.apache.fop.FileHandler = java.util.logging.FileHandler org.apache.fop.FileHandler.pattern = logs/docgen.log org.apache.fop.FileHandler.limit = 5000 org.apache.fop.FileHandler.formatter = java.util.logging.SimpleFormatter Where does org.apache.fop.FileHandler come from? Is that a class of your own? Note that changing logging.properties meddles with your global Java defaults. FOP uses Jakarta Commons Logging [http://commons.apache.org/logging/] as a bridge to a specific logging implementation, which uses JDK logging by default. The Log implementation to be used can only be changed by setting a system property, or by setting a configuration attribute on the LogFactory, named org.apache.commons.logging.Log FOP uses the default JCL LogFactoryImpl, and obtains class-based Loggers that capture the log-output. One way that /might/ work in an embedded context: - implement an org.apache.fop.apps.FileLog - set the above configuration attribute to match this implementation on the org.apache.commons.LogFactory prior to starting FOP Although this could lead to trouble when running multiple Fop instances concurrently. Since a lot (if not all) of FOP's loggers are statics, they are initialized when the class is loaded, so two threads will share the same loggers, and thus be writing to the same file. Make sure that access is synchronized, and you will still end up with log messages from different threads merged into the same file, unless you sort that out yourself. Probably the better way for FOP (well, it's a start): - implement a more generic org.apache.fop.apps.Log, that raises events on an associated Listener - set the above config attribute on LogFactory prior to doing anything else, except - offer the user a hook to plug in a custom event handler The Log instance that raises the events should ideally be tied to the FOUserAgent. Still unsure how to fit in the static loggers :/ Maybe, to minimize the amount of refactoring, FTM we could do: - implement a simple org.apache.fop.apps.StaticLog - initialize all static loggers in static blocks and call LogFactory.setAttribute() to use this type The StaticLog.info() events and above, could get overloads that accept an instance-based logger (the one tied to the user agent) on which they register those events. Should you decide to take steps in this direction, since this is becoming a rather pressing matter, IMO, I'm willing to invest some time in this as well. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two successive columns in a table -- problem with the page-break
On Nov 13, 2007, at 17:10, jorgito wrote: Thanks! So far I can't see solutions to these two problems, but will try to find them. column-count is an attribute of region-body, I don't know how to change this inside a page. You can't change the column-count mid-page, but you can make exceptions for certain fo:blocks, by using span=all. [OP:] --- If there ist a page-break I would like to have this: year | name || year | name === 2007Tom2009 Andy 2008Brenda2010 Mitch - page break -- 2011Nick 2013 Emmi 2012Carl But, maybe needless to say, I get this: year | name || year | name === 2007Tom2011 Nick 2008Brenda2012 Carl -page break-- 2009Andy 2013 Emmi 2010Mitch --- This result does not seem correct to me. I can't say for sure, though, but it looks a bit 'off'. As though the column-break is computed /after/ the page-break..? Anyone? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Capturing FOP logging message event in an embedded application using FOP 0.94
On Nov 13, 2007, at 18:29, Michael Tracey Zellmann wrote: Hi I have developed an application that generates PDFs of documentation in an eclipse environment controlled by a variety of SWT widgets. My customer would like his users to know when FOP has encountered a problem, but give them a simple message. We are already trapping exceptions, so I am interested in the kinds of events where FOP may generate a WARNING or SEVERE logging message. Like - the text has exceeded the allowed width and is overwriting another area, or the bookmark ids are pointing to a null view-port, for instance. I know how to write a File Handler to route those message to a file. Is there a way I can capture an event that will tell us to pop a dialog to the user, and hopefully get part of the logging message ? I fear you have stumbled upon a well-known shortcoming of FOP 0.9x: the error-reporting is not really what it should be. We all know it, but haven't found the time so far to take steps towards implementing something better, so exceptions and log messages are all there is to catch FTM... :( Sorry Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to set the logger?
On Nov 13, 2007, at 16:35, Gregan, Miroslav wrote: I need to use FOP 0.94 embedded, in a big project composed by different Eclipse's plug-ins where 2 of them define an org.apache.commons.logging.Log library, which causes me the following error: Invalid class loader hierarchy. You have more than one version of 'org.apache.commons.logging.Log' visible, which is not allowed. Is there a way how to set the logger manually like it was done before in FOP 0.20.5 by setting the Driver object? More or less the same answer as another thread I just posted a reply in... In short: currently, no. The loggers are static, class-based, and cannot be overridden. They are more meant for debug info during development. OTOH, I don't believe we use any specific version of Commons logging, so maybe you could try to make FOP use the other version (or make the other plugins use the jar that is distributed with FOP) Have you already tried removing one version from the classpath? Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Unexplained space
On Nov 13, 2007, at 21:52, Kamal Bhatt wrote: Hi Khamal Hi, I have a block with another block of text within and within it, I have another block of text. I do this to maintain spacing in certain circumstances (defined by the XSLT). Unfortunately one of the sideffects of this is a very large space after the enclosed block. If I run the example below in FOP 0.93, I get some chunky spacing after flight enquiries to check that your aircraft will be. The effect you describe is to be expected, I think, if you look at this snippet (simply cp; should be an exact copy of your original): --- fo:block linefeed-treatment=preserve margin-bottom=5mm margin- top=0 fo:block padding=0 margin-bottom=0 white-space-collapse=false white-space- treatment=preserve flight enquiries to check that your aircraft will be /fo:block departing at the time shown on your ticket and itinerary. --- The first series of 34 spaces in the outer block will be suppressed. Note that you have both enabled white-space-preserve and disabled white-space-collapse on the inner block. This means that, if FOP decides to break the line after the trailing spaces, they will be considered relevant when aligning the text flight enquiries Is that what you mean by 'chunky space'? Or is it maybe the effect of the preserved linefeeds in the outer block, that generate an empty line, because the second one is the only character in that line? Getting preserved white-space correct can be very tricky. Perhaps you wanted this: --- fo:block linefeed-treatment=preserve margin-bottom=5mm margin- top=0fo:block padding=0 margin-bottom=0 white-space- treatment=preserve flight enquiries to check that your aircraft will be /fo:blockdeparting at the time shown on your ticket and itinerary. --- Do you have control over the stylesheet? In that case, it should be a simple matter of adapting the template in question to produce the below version. HTH! Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two successive columns in a table -- problem with the page-break
On Nov 13, 2007, at 22:52, jorgito wrote: snip / So far I don't really have a column-break but a single table with 4 columns. I am iterating from 1 to (n + n mod 2) div 2 and writing in row m: year m and year m + (n + n mod 2) div 2. So the page-break is not done by me. I see. In that case, the output is precisely as I'd expect. Any ideas? Seems like a tough nut to crack in pure XSL-FO, at first glance... What you seem to need is the possibility to have a fo:block-container with a given maximum-height that spans all columns, and a descendant two-column table that flows over two region-columns, but this is not possible. Either the block-container spans all columns, and the table does too, or vice versa. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Two successive columns in a table -- problem with the page-break
On Nov 14, 2007, at 00:20, Andreas L Delmelle wrote: snip / Any ideas? Seems like a tough nut to crack in pure XSL-FO, at first glance... What you seem to need is the possibility to have a fo:block- container with a given maximum-height that spans all columns, and a descendant two-column table that flows over two region-columns, but this is not possible. Either the block-container spans all columns, and the table does too, or vice versa. Come to think of it: this could turn out to be a piece of cake, if only we had an XHTML plugin for fo:instream-foreign-object... Ideas? Plenty :-) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Images not resized properly in fop 0.94
On Nov 9, 2007, at 20:08, Puppala, Kumar (LNG-CON) wrote: Hi Kumar I am running into an issue with both gif and png images in fop 0.94. I am trying to render a big GIF image in my PDF document. Since the image does not fit in a single page, it should be resized. In FOP 0.20.5, I do see the correct behavior and the image is rendered properly. However in both 0.93 and 0.94 releases, the image is not truncated and hence only rendered partially. I am hereby attaching the FO file and the outputs from old and new fop. Are there any known issues here? Yes, the behavior in FOP 0.20.5 is non-compliant. Take a look at the fo:external-graphic, and the XSL-FO Rec, more precisely: http://www.w3.org/TR/xsl11/#d0e22982 (Area Dimension Properties) You have no explicit (content-)width/height, so: content-width=auto = intrinsic image width content-height=auto = intrinsic image height height=auto width=auto = the image should not be scaled to fit the viewport, but clipped. The trick is to set content-height and/or content-width explicitly to scale-to-fit. That should normally do it. Hope this helps! Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: linebreak fop0.94
On Nov 7, 2007, at 21:27, Andreas Siepert wrote: The empty-fo:block variant doesn't work my way. I already considered it but it does not only create a new line but also inserts an empty line. Really? Hadn't checked that, actually... If so, I'm not sure if that is correct behaviour, so we might have to look into that. :/ I rather want to make some kind of HTML br replacement: one br - newline, n brs in a row - n-1 empty lines. I will try your first suggestion - it sounds pretty good if the processor output can be manipulated that way. Yep, it's definitely the way to go if what you need is what is described above. The issue with empty fo:blocks is also one of performance, BTW. They only generate additional overhead, while the layout-algorithm has a ball with preserved linefeeds. It might take some caution, though, since generally, unexpected linefeeds tend to pop up that survive the XSL transform. Be mindful about linefeeds coming in from XML source like: someNode someText /someNode The leading and trailing linefeeds will both be presented to FOP, and might thus cause mayhem if you use linefeed-treatment=preserve. In case you're not sure where the value of the input node comes from, use normalize-space() in the XSLT to strip those off. For all else, I certainly do hope that you do not need hyphenation in this case, because currently this combination leads to all sorts of strangeness, like duplicated pieces of paragraphs... Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proper fop command line
On Nov 3, 2007, at 22:09, Khaled Aly wrote: snip / Hi Khaled / Vincent, As a heads-up: I just tried running the attached FO through FOP trunk, and it seems to work fine. Seems that the issue then is restricted to the 0.94 release, but has been resolved in the meantime (?) Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proper fop command line
On Nov 1, 2007, at 10:29, Khaled Aly wrote: Hi Khaled - I have my Java_Home environment variable pointing to the root of jdk1.5.0_09, the version I got installed. I see the FOP downloads labeled jdk1.3 and jdk1.4. I assume my JDK version should be backward compatible and this could not be the problem. Any doubt? This should indeed not be an issue. I run/test FOP on Java 1.5 and 1.6 all the time, and haven't seen any weirdness so far. - The same fo file that I mentioned works fine on oXygen (I'm trying to find out what fop version it runs); this same file produces good output when I run fop-0.20.4 - But, all tables are removed and their areas replaced by equal-dimensioned space. Does this mean anything, or is there a known fix for this issue for fop 0.2? We still haven't seen the whole FO-file, but note that there are some serious differences between FOP 0.20.x and 0.9x. FOs that worked under 0.20.x may need some work before you can use them with 0.9x. See also: http://xmlgraphics.apache.org/fop/0.94/upgrading.html Can you show us the FO? Thanks Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Tools for reverse FOP?
On Oct 31, 2007, at 23:59, siegfried wrote: Hi Are there any tools that will accept a PDF and produce XML? How do you mean this exactly? Translating PDF to a FO-document? What is the use-case? Might this be a feature of FOP someday? No plans that I'm aware of. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Vertical Small Caps alignment
On Nov 1, 2007, at 22:30, Andreas L Delmelle wrote: fo:block font-size=11pt font-family=Times font- weight=bold fo:wrapper font-size=75%fo:wrapper font-size=133%P/fo:wrapperART/fo:wrapper /fo:block Now, no matter what I try, the smaller text (ART) is aligned at the top of the block.. Is there anyway to get this to align along the bottom using fop? What have you tried so far? FWIW: just tried it myself, and with fo:inlines, it seems to work pretty well without doing anything special. Using fo:wrappers did not get the correct relative font-sizes with me. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: proper fop command line
On Nov 1, 2007, at 21:29, Khaled Aly wrote: Thanks Andreas for your willingness to help. I got it working fine with 0.93, which is the version used by oXygen 8.2 (that's why I never noticed there was a problem; somehow 0.93 is forgiving about the particular issue). When I tried same on oXygen 9Beta, running FOP 0.94, it failed there too but the error msg was more informative than the console one, indicating something to do with tables. Recalling FOP 0.2 had removed the tables, I used your advice to rule out, just focusing on tables. I found this problem: fo:table table-layout=fixed width=100% fo:table-header fo:table-row fo:table-cell fo:block font-size=9pt font-family=sans-serif font- weight=bold/ 0.94 required a non-empty block /fo:table-cell /fo:table-row /fo:table-header It seems like you have also stumbled into the bug that has been mentioned a couple of times: see http://issues.apache.org/bugzilla/show_bug.cgi?id=43766 It's not a violation of the XSL-FO Rec to use empty fo:blocks in fo:table-cells. It is only a requirement to have at least one fo:block child, but nothing mandates the block to have children as well. Cheers Andreas - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
