keep-together problem

2008-08-26 Thread Preuss, Jacqueline - ENCOWAY
Hi!

 

I know that there were some questions about the keep-together problem,
but those didn't answer my question. Maybe I misunderstood something...

 

The problem:

I have a table which contains some block elements, at least two. I want
the table and its elements to stay together when the content does not
fit on the rest of the page, the table should be wrapped to the next
page then. That seems to work if I use the keep-together="always"
attribute on the table. But if the content of the table is longer than
one page it will not be wrapped to the next page - instead the text is
clipped. 

 

How can I avoid this? 

 

I also tried to use the keep-with-next="always" attributes on the table
rows. This solves the clipping problem but the table starts at one page
and continues at the next page. What I want is that the table starts on
a new page if it doesn't fit on the previous one.

 

Hope you understand what I mean.

 

Regards,

Jacqueline.

 

 



AW: AW: keep-together problem

2008-08-28 Thread Preuss, Jacqueline - ENCOWAY
Hi again!

You are right, Chris. Integer keeps work with FOP Trunk. Thanks...

So I suppose that the integer support won't be released soon? :-(

Regards,
Jacqueline.

> -Ursprüngliche Nachricht-
> Von: Chris Bowditch [mailto:[EMAIL PROTECTED]
> Gesendet: Donnerstag, 28. August 2008 09:58
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: keep-together problem
> 
> 
> Preuss, Jacqueline - ENCOWAY wrote:
> 
> > Hi!
> 
> Hi,
> 
> >
> > This didn't help. I changed keep-together="always" to keep-together.within-
> column="always" but the text on the second page is clipped and not wrapped
> to the third page.
> >
> > I attached a sample file.
> >
> > What could be wrong here?
> 
> It looks like you need support for integer keeps, e.g.
> keep-together.within-column="10" Integer values work differently from
> "always" because they allow the content being kept together to be broken
> when the object spans more than an entire page. However, FOP v0.95
> doesn't support integer values in keeps and treats any value as "always"
> 
> FOP Trunk has some experimental support for integer values in keeps but
> I've never tried it so don't know if it will work in your case.
> 
> Regards,
> 
> Chris
> 
> 
> 
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



MalformedURLException when using relative paths

2008-05-21 Thread Preuss, Jacqueline - ENCOWAY
Hi!

 

We're just upgrading from fop_0.92 to fop_0.95beta. In our Fop
Configuration File we defined a base and a font-base like this:

 

./pdf_test

./pdf_test/pdf_fonts

 

With 0.92 everything works fine but with the newer version we get the
following exception:

 

java.net.MalformedURLException: no protocol: ./pdf_test/

at java.net.URL.(URL.java:567)

at java.net.URL.(URL.java:464)

at java.net.URL.(URL.java:413)

at
org.apache.fop.apps.FopFactory.checkBaseURL(FopFactory.java:339)

at
org.apache.fop.apps.FopFactory.setBaseURL(FopFactory.java:355)

at
org.apache.fop.apps.FopFactoryConfigurator.configure(FopFactoryConfigura
tor.java:116)

at
org.apache.fop.apps.FopFactoryConfigurator.setUserConfig(FopFactoryConfi
gurator.java:231)

at
org.apache.fop.apps.FopFactoryConfigurator.setUserConfig(FopFactoryConfi
gurator.java:203)

at
org.apache.fop.apps.FopFactory.setUserConfig(FopFactory.java:637)

 

Are relative paths not allowed anymore? What can we do to solve this?
Are there any suggestions available?

 

Regards,

Jacqueline.



AW: MalformedURLException when using relative paths

2008-05-22 Thread Preuss, Jacqueline - ENCOWAY
Hi, 

thanks for your replies. I tried: file:pdf_test, file://pdf_test Works both for 
me, because we have our own URI Resolver Implementation. Now, we have to check 
whether the case path starts with file:// and remove this.

Regards,
Jacqueline.

> -Ursprüngliche Nachricht-
> Von: Ted Young [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 21. Mai 2008 22:41
> An: fop-users@xmlgraphics.apache.org
> Betreff: RE: MalformedURLException when using relative paths
> 
> 
> I know it works with FOP .94 since I am doing exactly this right now.  :-)
> 
> Ted
> 
> -Original Message-
> From: J.Pietschmann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, May 21, 2008 3:11 PM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: MalformedURLException when using relative paths
> 
> Ted Young wrote:
> > Yes, it supports relative, but relative URLs not relative file paths.  So,
> > what you want it:
> > file:pdf_test
> 
> Everything starting with file: (or anything else which looks like
> an URI scheme) is by specification an absolute URL. The string
> file:pdf_test is not a valid URL at all, although some libraries
> will try to interpret it the way you do. I'm not sure whether FOP
> does it, and I'm too tired to check the URI resolver class right
> now.
> 
> J.Pietschmann
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Image size too large

2008-05-23 Thread Preuss, Jacqueline - ENCOWAY
Hi!

 

We have a problem with images and fop (0.93). In case that an image
can't be found our (own) FOPURIResolver writes an one-pixel GIF instead.
But in the pdf-file there is now much more space reserved for that GIF
as expected. 

 

Example if the image was found

 

image

a line

some text

 

Example if no image was found and we send a onepixel GIF:

 

image

[SPACE]

[SPACE]

[SPACE]

[SPACE]

[SPACE]

[SPACE] 

a line

some text

 

How can that happen? We generate the following XML for that image:

 



   



   



 

Is there a problem with the content-width?

 

Regards,

Jacqueline.

 

 

 



AW: Image size too large

2008-05-28 Thread Preuss, Jacqueline - ENCOWAY
Hi again!

 

We always build the image tag programmatically like this: 

 



 

If I understand right with the url(…) parameter we tell our URIResolver to 
resolve the URI, isn’t it? In case that the resolver can’t find the image it 
will write the Onepixel GIF instead in a StreamSource. If the image is supposed 
to be 8 cm wide, the Onepixel GIF will be scaled to 8 cm in width _and_ also in 
height. That could explain the bigger space to the following elements. Do you 
understand what I mean?

 

Regards,

Jacqueline.

 

Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 
Gesendet: Freitag, 23. Mai 2008 15:30
An: fop-users@xmlgraphics.apache.org
Betreff: Re: Image size too large

 


This always works for me: 

 




"Preuss, Jacqueline - ENCOWAY" <[EMAIL PROTECTED]> wrote on 05/23/2008 09:12:29 
AM:

> Hi! 
>   
> We have a problem with images and fop (0.93). In case that an image 
> can’t be found our (own) FOPURIResolver writes an one-pixel GIF 
> instead. But in the pdf-file there is now much more space reserved 
> for that GIF as expected. 
>   
> Example if the image was found 
>   
> image 
> a line 
> some text 
>   
> Example if no image was found and we send a onepixel GIF: 
>   
> image 
> [SPACE] 
> [SPACE] 
> [SPACE] 
> [SPACE] 
> [SPACE] 
> [SPACE] 
> a line 
> some text 
>   
> How can that happen? We generate the following XML for that image: 
>   
>  
> 
>  content-width="8cm" /> 
> 
>  
>   
> Is there a problem with the content-width? 
>   
> Regards, 
> Jacqueline. 
>   
>   
>