Re: FOP alignment problem between two font type

2016-03-08 Thread Andreas L. Delmelle
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

2015-07-30 Thread Andreas L. Delmelle

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

2011-07-30 Thread Andreas L. Delmelle
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

2011-07-30 Thread Andreas L. Delmelle
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

2011-07-30 Thread Andreas L. Delmelle
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

2011-07-23 Thread Andreas L. Delmelle
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

2011-07-21 Thread Andreas L. Delmelle

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

2011-07-20 Thread Andreas L. Delmelle
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

2011-07-20 Thread Andreas L. Delmelle

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;

2011-07-19 Thread Andreas L. Delmelle
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

2011-07-15 Thread Andreas L. Delmelle
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

2011-07-15 Thread Andreas L. Delmelle

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

2011-07-15 Thread Andreas L. Delmelle
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

2011-07-14 Thread Andreas L. Delmelle

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

2011-07-12 Thread Andreas L . Delmelle
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

2011-07-07 Thread Andreas L. Delmelle
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

2011-07-07 Thread Andreas L. Delmelle
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

2011-07-07 Thread Andreas L. Delmelle

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

2011-07-02 Thread Andreas L. Delmelle

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

2011-06-30 Thread Andreas L. Delmelle
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

2011-06-30 Thread Andreas L. Delmelle
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

2011-06-30 Thread Andreas L. Delmelle
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

2011-06-30 Thread Andreas L. Delmelle
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

2011-06-30 Thread Andreas L. Delmelle
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

2011-06-21 Thread Andreas L. Delmelle
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.

2011-06-20 Thread Andreas L. Delmelle
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)

2011-06-19 Thread Andreas L. Delmelle
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

2011-06-14 Thread Andreas L. Delmelle
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?

2011-06-13 Thread Andreas L. Delmelle
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

2011-06-13 Thread Andreas L. Delmelle
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

2011-06-13 Thread Andreas L. Delmelle
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?

2011-06-10 Thread Andreas L. Delmelle
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

2011-06-03 Thread Andreas L. Delmelle
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

2011-06-03 Thread Andreas L. Delmelle
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

2011-05-26 Thread Andreas L. Delmelle
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

2011-05-24 Thread Andreas L. Delmelle
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?

2011-05-16 Thread Andreas L. Delmelle
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

2011-04-14 Thread Andreas L. Delmelle
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

2011-04-14 Thread Andreas L. Delmelle
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

2011-04-14 Thread Andreas L. Delmelle
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

2011-04-13 Thread Andreas L. Delmelle
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

2011-04-13 Thread Andreas L. Delmelle
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

2011-04-13 Thread Andreas L. Delmelle
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

2011-04-07 Thread Andreas L. Delmelle
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

2011-04-06 Thread Andreas L. Delmelle
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

2011-04-03 Thread Andreas L. Delmelle
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

2011-04-01 Thread Andreas L. Delmelle
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

2011-04-01 Thread Andreas L. Delmelle
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

2011-04-01 Thread Andreas L. Delmelle
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

2011-03-31 Thread Andreas L. Delmelle
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?

2011-03-30 Thread Andreas L. Delmelle
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?

2011-03-29 Thread Andreas L. Delmelle
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?

2011-03-29 Thread Andreas L. Delmelle
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?

2011-03-29 Thread Andreas L. Delmelle
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?

2011-03-29 Thread Andreas L. Delmelle
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

2008-01-16 Thread Andreas L Delmelle

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

2008-01-16 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-15 Thread Andreas L Delmelle

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

2008-01-14 Thread Andreas L Delmelle

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

2008-01-14 Thread Andreas L Delmelle

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

2008-01-14 Thread Andreas L Delmelle

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

2008-01-10 Thread Andreas L Delmelle

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

2008-01-09 Thread Andreas L Delmelle

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

2008-01-09 Thread Andreas L Delmelle

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

2008-01-09 Thread Andreas L Delmelle


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

2008-01-02 Thread Andreas L Delmelle


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

2008-01-02 Thread Andreas L Delmelle

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

2008-01-02 Thread Andreas L Delmelle

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

2008-01-02 Thread Andreas L Delmelle

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)

2007-12-21 Thread Andreas L Delmelle

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

2007-12-21 Thread Andreas L Delmelle

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

2007-12-03 Thread Andreas L Delmelle

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

2007-12-02 Thread Andreas L Delmelle

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

2007-12-01 Thread Andreas L Delmelle

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

2007-12-01 Thread Andreas L Delmelle

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

2007-11-30 Thread Andreas L Delmelle

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

2007-11-21 Thread Andreas L Delmelle

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?

2007-11-20 Thread Andreas L Delmelle

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

2007-11-20 Thread Andreas L Delmelle

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

2007-11-19 Thread Andreas L Delmelle

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

2007-11-16 Thread Andreas L Delmelle

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

2007-11-15 Thread Andreas L Delmelle

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

2007-11-13 Thread Andreas L Delmelle

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

2007-11-13 Thread Andreas L Delmelle

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?

2007-11-13 Thread Andreas L Delmelle

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

2007-11-13 Thread Andreas L Delmelle


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

2007-11-13 Thread Andreas L Delmelle

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

2007-11-13 Thread Andreas L Delmelle

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

2007-11-09 Thread Andreas L Delmelle

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

2007-11-07 Thread Andreas L Delmelle

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

2007-11-04 Thread Andreas L Delmelle

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

2007-11-01 Thread Andreas L Delmelle

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?

2007-11-01 Thread Andreas L Delmelle

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

2007-11-01 Thread Andreas L Delmelle

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

2007-11-01 Thread Andreas L Delmelle

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]



  1   2   3   4   5   6   >