RE: Problem rendering PNG Issue

[Puppala, Kumar (LNG-CON)]

Thanks for the quick response. I probably will not be able to modify
these images. I can grab the latest code from the Commons Trunk.



-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Thursday, March 06, 2008 2:29 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Problem rendering PNG Issue

Grmbl, grmbl. Had you found this bug about 4 days earlier it would have
made it into the XML Graphics Commons release 1.3. Now we probably have
to do a bugfix release. (Not your fault!!! Thanks for the bug report!)

Bugfixed in Commons Trunk:
http://svn.apache.org/viewvc?rev=634385&view=rev

You can, as a work-around, edit the PNG file in some bitmap editor and
add some metadata to it so its size increases a bit. You only need about
4 bytes more and the PNG will run through with no error.

On 06.03.2008 19:56:55 Puppala, Kumar (LNG-CON) wrote:
> I am trying to render a PNG image using the new FOP Trunk code and I
am
> getting the following error in the log:
> 
>  
> 
> ERROR org.apache.fop.fo.FONode : I/O error while loading image: null
> 
>  
> 
> I am attaching the particular PNG image in question (the image by
itself
> is good and it opens up properly). I rendered the same image
> successfully using 0.20.5 version. When I debugged the code, the
> exception that was caught in ExternalGraphic.java was EOFException
with
> no message. Any help is greatly appreciated.
> 
>  
> 
> Thanks,
> 
> Kumar
> 




Jeremias Maerki


-
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]

Problem rendering PNG Issue

[Puppala, Kumar (LNG-CON)]

I am trying to render a PNG image using the new FOP Trunk code and I am
getting the following error in the log:

 

ERROR org.apache.fop.fo.FONode : I/O error while loading image: null

 

I am attaching the particular PNG image in question (the image by itself
is good and it opens up properly). I rendered the same image
successfully using 0.20.5 version. When I debugged the code, the
exception that was caught in ExternalGraphic.java was EOFException with
no message. Any help is greatly appreciated.

 

Thanks,

Kumar

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

RE: Fop 0.20.5 vs Fop Trunk Performace

[Puppala, Kumar (LNG-CON)]

I forgot to mention this point. We in fact are running in multi-threaded
mode and I am creating a pool of TranformerFactories and transformers.
Each thread needs to go through a synchronized call to get access to
them. As you pointed out, TransformerFactory is not thread-safe and I
found it the hard way (got a lot of NullPointerExceptions when I was not
using the pool).

Thanks !! 

-Original Message-
From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 05, 2008 5:07 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Fop 0.20.5 vs Fop Trunk Performace

On Mar 5, 2008, at 21:36, Andreas Delmelle wrote:

> On Mar 5, 2008, at 21:09, Puppala, Kumar (LNG-CON) wrote:
>>
>>// Setup JAXP using identity transformer
>>TransformerFactory factory =  
>> TransformerFactory.newInstance();
>>Transformer transformer = factory.newTransformer(); //  
>> identity transformer
>
> Interesting! So the memory leaks are not inherent to FOP it would  
> seem, but to the way the JAXP-pattern is used.
>
>>
>> When you use the TransformerFactory in this manner (within each  
>> run), the SAXParser instance created by the transformer is held in  
>> memory. On subsequent runs, I noticed more and more instances of  
>> SAXParser's in memory. To fix this, I moved this code to the  
>> calling function, thus keeping a single copy of transformer.
>
> Makes sense. The TransformerFactory should indeed (better practice)  
> be declared only once. If you ever plan on using XSLT stylesheets,  
> you could also cache a Templates object.

This made me re-read the API docs, and it this may suit your  
particular setup, I was wrong and in general one should actually be  
*very* careful when re-using either the TransformerFactory or the  
Transformer. Neither of the objects are thread-safe, so this can only  
be done if you are absolutely certain that no two threads will  
concurrently access either of them... Re-using them in sequence is no  
problem whatsoever, and actually seems to be recommended, based on  
your observations.



Cheers

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


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

RE: Fop 0.20.5 vs Fop Trunk Performace

[Puppala, Kumar (LNG-CON)]

Hi Andreas,

I ran our server using DevPartner and noticed a lot of memory leaks.
After much analysis, I was able to determine that the manner in which we
embed FOP in our application (for that matter any application) might be
resulting in these leaks. The specific piece of code that I found very
interesting is as shown below:

 

   // Setup JAXP using identity transformer

   TransformerFactory factory =
TransformerFactory.newInstance();

   Transformer transformer = factory.newTransformer(); //
identity transformer

 

When you use the TransformerFactory in this manner (within each run),
the SAXParser instance created by the transformer is held in memory. On
subsequent runs, I noticed more and more instances of SAXParser's in
memory. To fix this, I moved this code to the calling function, thus
keeping a single copy of transformer. This greatly reduced the GC times.
However, I am still seeing an incremental increase rendering times on
subsequent runs.  I am trying to streamline the code on our end to
adhere to your suggestions. If you find anything, please let us know.

 

Thanks,

Kumar 

 

-Original Message-
From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, February 20, 2008 12:47 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Fop 0.20.5 vs Fop Trunk Performace

 

On Feb 15, 2008, at 20:37, Puppala, Kumar (LNG-CON) wrote:

 

Hi Kumar

 



> Well, it's not so much the number of objects I'm thinking of, but

> rather, how much time is spent executing specific methods and which

> ones take longer in later iterations. The actual cause of the

> slowdown may precisely be located in a class of which there are

> relatively few instances alive, if I judge correctly. Or did you

> already check whether the bulk of the increase in processing-time is

> really only spent on garbage-collection?

> 

> --> I did verify that garbage collection is playing a very  

> significant role in these increased timings. I am currently using  

> the Java Profiling tool to identify the methods where we have the  

> maximum execution time. I ran the basic simple.fo file provided in  

> the examples directory and below is the screen shot from the  

> profiling tool:

> 

> 

> 

> I need to do further analysis on this but comparing this output to  

> the one generated by running the same fo file against fop 0.20.5  

> codebase, I do see two significant areas (lineBreak and layoutMgr)  

> that are taking time. The profiling output for the same test on fop  

> 0.20.5 codebase is as shown below:

> 

 

Unfortunately, a single run is far from representative, especially  

when compared to the set of tests you ran earlier.

 

What one could say, based on the screenshot, is that most of the time  

is spent on parsing the FO and on creating loggers, but then we would  

be conveniently ignoring the simple facts that:

* all loggers are static, so the cost of creating them is overly  

represented if you measure only a single run (hence why LogFactory is  

at the top of the list here)

* the org.apache.fop.fo package contains a lot of static  

initialization as well, so ... (unfortunately, no details shown in  

the screenshot to confirm)

 

In the meantime, I have run some local tests using the files you  

published. Thanks for those!

The tests were run as an iteration of the most basic example  

ExampleFO2PDF.java, slightly modified to process the whole set of  

files you provided one-by-one, using a specified maximum number of  

concurrently running threads.

 

So far, I have run:

1 batch of 1500 runs, single-threaded

1 batch of 1500 runs, in two threads

1 batch of 1500 runs, in three threads

1 batch of 3000 runs, in 10 threads.

 

I did not immediately see any indication of individual tests  

consistently taking longer in later iterations. Each of the 117 files  

was processed about 13 times in the course of one batch of 1500, 26  

times for the batch of 3000. Some run a tiny bit slower, but IMO not  

enough to count as actually 'slower'. Some tests are even faster the  

13th time around than the first time.

 

I do see some runs taking significantly longer, most likely due to  

garbage-collection. This effect can already be observed when running  

in a single thread.

 

As potential improvements:

There are some tests that generate a significant amount of log- 

messages (mostly warnings). AFAICT, if you can make your generated FO  

such that it produces less of these warnings, there could already be  

a noticeable speed-benefit. The processing times in my tests were  

always a lot higher for those tests that generated a lot of warnings.

 

To reduce the strain on the garbage-collector, you could also  

consider generating 'better' FO.

 

Of course, this is a matter of opinion, but one striking example I  

encou

RE: Fop 0.20.5 vs Fop Trunk Performace

[Puppala, Kumar (LNG-CON)]

Hi Andreas/Jeremias,

  Thanks for the quick responses. Provided below are my responses to
your questions.

 

 

Thanks!!

 

-Original Message-
From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, February 12, 2008 2:22 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Fop 0.20.5 vs Fop Trunk Performace

 

On Feb 12, 2008, at 17:06, Puppala, Kumar (LNG-CON) wrote:

 

Hi Kumar

> We are currently using FOP 0.20.5 on our production boxes and  

> intend to use the latest FOP at some point this year. As such, we  

> are trying to gauge performance improvements between the two.  

> However, I am finding that the new FOP is taking more time to  

> render than the old one. The options used to run the FOP (both old  

> and new) are as shown below:

> 

Just to be sure: which revision of the trunk are you trying out?

 

 --> I obtained the latest from the trunk on Jan 22nd. Information
pertaining to the fopTrunk as seen in the status.xml file is:

"status.xml 614201 2008-01-22 14:02:27Z jeremias"

 

As Jeremias already pointed out, make sure that at least the  

FopFactory is instantiated only once (that was the whole point of its  

inception: to save time on reloading resources that can be shared  

between multiple runs).

 --> Yes, I am instantiating FopFactory just once. Initially I was not
doing that but I changed my code to instantiate it just once. The
results provided are with the change.

 

Apart from that, focusing purely on FOP Trunk, if you know how to  

narrow it down to specific methods/calls that cause the increase in  

processing time that would help us a lot.

 --> I do have the complete Heap report. Some of the classes having
maximum instances are as shown below:

463132 instances <http://dvc7632:7172/instances/0xb4d0a270>  of class
org.apache.fop.traits.MinOptMax <http://dvc7632:7172/class/0xb4d0a270>  
441537 instances <http://dvc7632:7172/instances/0xb4d139a8>  of class
org.apache.fop.layoutmgr.NonLeafPosition
<http://dvc7632:7172/class/0xb4d139a8>  
386229 instances <http://dvc7632:7172/instances/0xb4bd3f50>  of class
org.apache.fop.fo.properties.CondLengthProperty
<http://dvc7632:7172/class/0xb4bd3f50>  
362166 instances <http://dvc7632:7172/instances/0xb4d33020>  of class
org.apache.fop.layoutmgr.LeafPosition
<http://dvc7632:7172/class/0xb4d33020>  
216985 instances <http://dvc7632:7172/instances/0xb4bd6648>  of class
org.apache.fop.fo.properties.SpaceProperty
<http://dvc7632:7172/class/0xb4bd6648>  
181359 instances <http://dvc7632:7172/instances/0xb4cf9dd0>  of class
org.apache.fop.layoutmgr.KnuthGlue
<http://dvc7632:7172/class/0xb4cf9dd0>  
164198 instances <http://dvc7632:7172/instances/0xb4d69638>  of class
org.apache.fop.layoutmgr.inline.TextLayoutManager$AreaInfo
<http://dvc7632:7172/class/0xb4d69638>  
140706 instances <http://dvc7632:7172/instances/0xb4d17690>  of class
org.apache.fop.layoutmgr.KnuthPenalty
<http://dvc7632:7172/class/0xb4d17690>  
107113 instances <http://dvc7632:7172/instances/0xb4c62c38>  of class
org.apache.fop.fo.properties.CommonBorderPaddingBackground
<http://dvc7632:7172/class/0xb4c62c38>  
107113 instances <http://dvc7632:7172/instances/0xb4c64700>  of class
[Lorg.apache.fop.fo.properties.CommonBorderPaddingBackground$BorderInfo;
<http://dvc7632:7172/class/0xb4c64700>  
104453 instances <http://dvc7632:7172/instances/0xb4d69f18>  of class
org.apache.fop.layoutmgr.inline.KnuthInlineBox
<http://dvc7632:7172/class/0xb4d69f18>  
91823 instances <http://dvc7632:7172/instances/0xb4c64c78>  of class
[Lorg.apache.fop.fo.properties.CondLengthProperty;
<http://dvc7632:7172/class/0xb4c64c78>  
84488 instances <http://dvc7632:7172/instances/0xb4cc3ac8>  of class
org.apache.fop.layoutmgr.LMiter <http://dvc7632:7172/class/0xb4cc3ac8>  
78913 instances <http://dvc7632:7172/instances/0xb4d7acb0>  of class
org.apache.fop.area.inline.WordArea
<http://dvc7632:7172/class/0xb4d7acb0>  
73825 instances <http://dvc7632:7172/instances/0xb4c91138>  of class
org.apache.fop.fo.flow.table.BorderSpecification
<http://dvc7632:7172/class/0xb4c91138>  
70532 instances <http://dvc7632:7172/instances/0xb4c79380>  of class
org.apache.fop.datatypes.LengthBase
<http://dvc7632:7172/class/0xb4c79380>  
70532 instances <http://dvc7632:7172/instances/0xb4bdea20>  of class
org.apache.fop.fo.properties.PercentLength
<http://dvc7632:7172/class/0xb4bdea20>  
69942 instances <http://dvc7632:7172/instances/0xb4c7bbd8>  of class
org.apache.fop.fo.FObj$FObjIterator
<http://dvc7632:7172/class/0xb4c7bbd8>  
67494 instances <http://dvc7632:7172/instances/0xb4c92670>  of class
org.apache.fop.fo.flow.table.ConditionalBorder
<http://dvc7632:7172/class/0xb4c92670>  
63321 instances <http://dvc7632:7172/i

RE: fo:table-row issues

[Puppala, Kumar (LNG-CON)]

Andreas,
  You are correct in you analysis that having such data does not make
much sense. But since we are a downstream system and we don't control
the data that comes to us (in XML format), we do implicit conversions to
XSL-FO format using our own programs. As such, we need to account for
all such weird situations :)

Thanks !!

-Original Message-
From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 04, 2008 12:41 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: fo:table-row issues

On Feb 4, 2008, at 18:03, Puppala, Kumar (LNG-CON) wrote:

Hi
>
> Thanks for the quick reply. I tried both the suggestions and am  
> still having issues. Listed below are my findings:
>
> What if you add two empty cells, or simply leave out the empty row?
>
> If I add two empty cells, the renderer complains that the number of  
> cells in the row overflows. The error message is as shown below:
>
> "org.apache.fop.fo.ValidationException: Error(67/15): column-number  
> or number of cells in the row overflows the number of fo:table- 
> column specified for the table."
>
OK. This still seems understandable to me, although it does not help  
your case, but...
> If I leave out the entire row, I see different results between fop  
> 0.94 and fopTrunk. In fop 0.94, it renders but the borders on the  
> top for the two cells are missing (attaching the pdf doc). However,  
> in fopTrunk, I get the following validation exception:
>
>  "org.apache.fop.fo.ValidationException: A table-cell is spanning  
> more rows than available in its parent element."
>

This seems to be a bit too strong to me. I'd prefer a warning and a  
fallback to the number of available rows, instead of throwing a  
ValidationException in this case... Maybe I'm missing some parts of  
the XSL-FO Rec, but it does not mention this explicitly as an error.

What do others think?

OTOH, now I'm wondering why you would create a table with only one  
row, and a cell in that row that spans two rows, or even: why you  
would in that case want to add another row, just so the cell can span  
two rows... It seems more correct to omit the number-rows-spanned  
property in that case, but of course, I have no idea if this is  
simple to achieve by altering your stylesheet.


Cheers

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


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

RE: fo:table-row issues

[Puppala, Kumar (LNG-CON)]

Thanks for the quick reply. I tried both the suggestions and am still
having issues. Listed below are my findings:

 

What if you add two empty cells, or simply leave out the empty row?

If I add two empty cells, the renderer complains that the number of
cells in the row overflows. The error message is as shown below:

 

"org.apache.fop.fo.ValidationException: Error(67/15): column-number or
number of cells in the row overflows the number of fo:table-column
specified for the table."

 

If I leave out the entire row, I see different results between fop 0.94
and fopTrunk. In fop 0.94, it renders but the borders on the top for the
two cells are missing (attaching the pdf doc). However, in fopTrunk, I
get the following validation exception: 

 "org.apache.fop.fo.ValidationException: A table-cell is spanning more
rows than available in its parent element."

 

Thanks !!

 

-Original Message-
From: Andreas Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 04, 2008 11:27 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: fo:table-row issues

 

On Feb 4, 2008, at 17:11, Puppala, Kumar (LNG-CON) wrote:

 

Hi

 

> I am trying to render a 2x2 table, the first row of which spans  

> across two cells and two rows as shown below:

> 

> 

> 

> 

> 

> 

>  padding="2pt" text-align="left" display-align="before" number- 

> columns-spanned="2" number-rows-spanned="2" >

> 

>  font-style="normal" text-decoration="no-underline" font-size="10pt"  

> >kangaroo

> 

> 

> 

> 

> 

> 

> 

> 

> 

> This markup used to produce the desired results in fop 0.20.5 but  

> gives me validation errors when using 0.94 and higher (trunk  

> included).

 

 

This (an empty row) is definitely not allowed by the XSL-FO Rec, so  

the validation error is more correct than 0.20.5, in any case.

The XSL content model of fo:table-row only allows for one or more  

fo:table-cell child nodes, possibly preceded by some fo:markers  

(although, IIC, FOP Trunk will ignore markers in a table-row).

 

> If I try to adhere to the validation rules and provide a table-cell  

> with an empty block for the second row, it complains that the  

> number of cells overflow the number specified for the table.

> 

> From this analysis, it looks like if a table contains a row which  

> spans the entire columns and any additional rows, we run into  

> issues. Has anyone encountered this issue and are there any  

> workarounds for this?

 

What if you add two empty cells, or simply leave out the empty row?

 

The last option would definitely be preferable, as it saves resources  

(no construction of empty cells/blocks). If you can adapt the  

stylesheet, so it omits the offending row, that should work...

 

 

HTH!

 

Andreas

 

-

To unsubscribe, e-mail: [EMAIL PROTECTED]

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

 



aa.pdf
Description: aa.pdf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

fo:table-row issues

[Puppala, Kumar (LNG-CON)]

I am trying to render a 2x2 table, the first row of which spans across
two cells and two rows as shown below:

 















kangaroo















 

 

This markup used to produce the desired results in fop 0.20.5 but gives
me validation errors when using 0.94 and higher (trunk included). If I
try to adhere to the validation rules and provide a table-cell with an
empty block for the second row, it complains that the number of cells
overflow the number specified for the table.

 

>From this analysis, it looks like if a table contains a row which spans
the entire columns and any additional rows, we run into issues. Has
anyone encountered this issue and are there any workarounds for this?

 

 

Thanks,

Kumar Puppala

RE: BreakingAlgorithm Problem

[Puppala, Kumar (LNG-CON)]

You could insert a Unicode Zero Width Space (​) after each
character within your table-cell. That should enable the word to break
properly without overflowing into the next cell.

However, if the same logic is applied to some standard text (which can
hyphenate) it will no longer hyphenate. 

Thanks,
Kumar

-Original Message-
From: fma-001 [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 14, 2007 11:46 AM
To: fop-users@xmlgraphics.apache.org
Subject: BreakingAlgorithm Problem


Hi!

I use FOP 0.93 and write some data in a table with several columns. In
one
column data can be broader than the column-width without any chance to
hyphenate.

FOP then logs message: "WARN  [BreakingAlgorithm] Line 1 of a paragraph
overflows the available area."

I tried to get rid of it with overflow- and wrap-option-attributes, but
it
doesn'nt work:








Say, I have a string "www.verylonguri.com", FOP can't hyphenate it and
does
write it into the next column. I would like to break it hard, like this:
www.verlon
guri.com

Is there any way to archive this?

Thank you in advance!
Franz
-- 
View this message in context:
http://www.nabble.com/BreakingAlgorithm-Problem-tf4806438.html#a13751025
Sent from the FOP - Users mailing list archive at Nabble.com.


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


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

RE: How to keep pagenumber over several page-sequences

[Puppala, Kumar (LNG-CON)]

Let me try to understand your requirement. You have the following
page-sequences in your document

 

Page sequence for Index

Page sequence for Chapter1

Page sequence for Chapter2

...

 

And you want the page number to start off from 1 on Chapter 1 instead of
Index.

 

If this is what you want, you can set initial-page-number on the page
sequence for Chapter1 to 1 and then not mention this attribute on the
remaining page-sequences. Regarding page sequence for Index, you mention
the initial-page-number to 1 as well. The page number gets reset
whenever you mention the initial-page-number property on a particular
sequence.

 

Hope this helps.

 

 



From: Michael Niemann [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, November 14, 2007 4:09 AM
To: fop-users@xmlgraphics.apache.org
Subject: RE: How to keep pagenumber over several page-sequences

 

That makes sense. By removing the initial pagenumber for the chapter
block the count starts with the index page though. How can I make it
start with 1 without setting it in the block?

"Puppala, Kumar (LNG-CON)" <[EMAIL PROTECTED]> wrote:

Having just the force-page-count property on the subsequent page
sequences should do the trick.

 



 

The page number on subsequent page sequences is a continuation from the
previous page sequence in this case.

 



  



Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See
how. <http://us.rd.yahoo.com/evt=51732/*http:/overview.mail.yahoo.com/> 

RE: How to keep pagenumber over several page-sequences

[Puppala, Kumar (LNG-CON)]

Having just the force-page-count property on the subsequent page
sequences should do the trick.

 



 

The page number on subsequent page sequences is a continuation from the
previous page sequence in this case.

 



From: Michael Niemann [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, November 13, 2007 10:45 AM
To: fop-users@xmlgraphics.apache.org
Subject: How to keep pagenumber over several page-sequences

 

hello,
I've split up my document into several page-sequences for better
performance.



  
 
  
  




  

  

As you can easily see each chapter now starts with page 1. Is it
possible to pass the pagenumber between those sequences without losing
all the performance gain I got from spolitting up the chapter into
sequences?

best regards
michael

  



Get easy, one-click access to your favorites. Make Yahoo! your homepage.
  

Column balancing issue

[Puppala, Kumar (LNG-CON)]

I am noticing some white space in the last two pages of a PDF document
that I am trying to render using 0.94. Also, the columns are not
balanced properly (using dual column layout). The weird thing about this
test is that the problem disappears once I reduce some text in the .FO
file. The only suspicious message I see during rendering is as shown
below:

 

Nov 12, 2007 5:05:04 PM org.apache.fop.layoutmgr.PageBreaker
doPhase3WithColumnBalancing

WARNING: Breaking algorithm produced more columns than are available.

 

I tried to cut down the .FO file to recreate the issue but could not do
so. The file is about 692 Kb and hence I am hesitant to attach it,
unless needed. Any idea what might be causing this?

 

Thanks,

Kumar Puppala

RE: Images not resized properly in fop 0.94

[Puppala, Kumar (LNG-CON)]

Thanks Jeremias for pointing me to the examples. From the examples, I
could not find one that suits my testcase. However, I was able to find
one from another website: 
  http://www.renderx.net/lists/xep-support/0376.html

I tried this approach for my image and it worked. The trick is to
specify the markup as shown below:

 

Since we do not have this particular testcase in the images.fo file, can
you please add this? It might be helpful for those who wish to scale
only those images that do not fit in the page.

Appreciate your help.

Thanks!!

-Original Message-
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 09, 2007 5:00 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Images not resized properly in fop 0.94

May I suggest that you have a look at "examples/fo/basic/images.fo" in
the FOP distribution? The example shows various ways to use
fo:external-graphic. I'm sure you'll find the pattern you need there.

Good luck!

Jeremias Maerki



On 09.11.2007 22:50:23 Puppala, Kumar (LNG-CON) wrote:
> Thanks for the information. I tried to use both content-height and
> content-width (setting them to 'scale-to-fit') in my testcase and it
> still did not work. I think there might be some issue here. Below is
the
> code snippet from AbstractGraphicsLayoutManager.java file:
> 
>  
> 
> In getInlineArea() function:
> 
>  
> 
> Line 72 onwards...
> 
> int bpd = -1;
> 
> int ipd = -1;
> 
>  
> 
> The bpd and ipd values are only overwritten if 
> 
> Line 129 onwards...
> 
> if ((scaling == EN_UNIFORM) || (cwidth == -1) || cheight ==
-1)
> {
> 
> if (cwidth == -1 && cheight == -1) {
> 
> cwidth = fobj.getIntrinsicWidth();
> 
> cheight = fobj.getIntrinsicHeight();
> 
> }
> 
>  
> 
> Line 164 onwards...
> 
> if (ipd == -1) {
> 
> ipd = cwidth;
> 
> }
> 
> if (bpd == -1) {
> 
> bpd = cheight;
> 
> }
> 
>  
> 
> The ipd and bpd values are set as per this flow for my FO file. As
such,
> the values are not being scaled. We might be missing something here
but
> since I am not an expert in this area, any input to fix this issue
will
> be greatly appreciated.
> 
>  
> 
>  
> 
> Thanks,
> 
> Kumar Puppala
> 
>  
> 
> -Original Message-
> From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] 
> Sent: Friday, November 09, 2007 2:21 PM
> To: fop-users@xmlgraphics.apache.org
> Subject: Re: Images not resized properly in fop 0.94
> 
>  
> 
> On Nov 9, 2007, at 20:08, Puppala, Kumar (LNG-CON) wrote:
> 
>  
> 
> Hi Kumar
> 
> > I am running into an issue with both gif and png images in fop  
> 
> > 0.94. I am trying to render a big GIF image in my PDF document.  
> 
> > Since the image does not fit in a single page, it should be  
> 
> > resized. In FOP 0.20.5, I do see the correct behavior and the image

> 
> > is rendered properly. However in both 0.93 and 0.94 releases, the  
> 
> > image is not truncated and hence only rendered partially. I am  
> 
> > hereby attaching the FO file and the outputs from old and new fop.  
> 
> > Are there any known issues here?
> 
>  
> 
> Yes, the behavior in FOP 0.20.5 is non-compliant.
> 
>  
> 
> Take a look at the fo:external-graphic, and the XSL-FO Rec, more  
> 
> precisely:
> 
>  
> 
> http://www.w3.org/TR/xsl11/#d0e22982 (Area Dimension Properties)
> 
>  
> 
> You have no explicit (content-)width/height, so:
> 
>  
> 
> content-width="auto" => intrinsic image width
> 
> content-height="auto" => intrinsic image height
> 
> height="auto"
> 
> width="auto"
> 
>  
> 
> => the image should not be scaled to fit the viewport, but clipped.
> 
>  
> 
> The trick is to set content-height and/or content-width explicitly to

> 
> "scale-to-fit". That should normally do it.
> 
>  
> 
> Hope this helps!
> 
>  
> 
>  
> 
> Andreas


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


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

RE: Images not resized properly in fop 0.94

[Puppala, Kumar (LNG-CON)]

Thanks for the information. I tried to use both content-height and
content-width (setting them to 'scale-to-fit') in my testcase and it
still did not work. I think there might be some issue here. Below is the
code snippet from AbstractGraphicsLayoutManager.java file:

 

In getInlineArea() function:

 

Line 72 onwards...

int bpd = -1;

int ipd = -1;

 

The bpd and ipd values are only overwritten if 

Line 129 onwards...

if ((scaling == EN_UNIFORM) || (cwidth == -1) || cheight == -1)
{

if (cwidth == -1 && cheight == -1) {

cwidth = fobj.getIntrinsicWidth();

cheight = fobj.getIntrinsicHeight();

}

 

Line 164 onwards...

if (ipd == -1) {

ipd = cwidth;

}

if (bpd == -1) {

bpd = cheight;

}

 

The ipd and bpd values are set as per this flow for my FO file. As such,
the values are not being scaled. We might be missing something here but
since I am not an expert in this area, any input to fix this issue will
be greatly appreciated.

 

 

Thanks,

Kumar Puppala

 

-Original Message-
From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 09, 2007 2:21 PM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Images not resized properly in fop 0.94

 

On Nov 9, 2007, at 20:08, Puppala, Kumar (LNG-CON) wrote:

 

Hi Kumar

> I am running into an issue with both gif and png images in fop  

> 0.94. I am trying to render a big GIF image in my PDF document.  

> Since the image does not fit in a single page, it should be  

> resized. In FOP 0.20.5, I do see the correct behavior and the image  

> is rendered properly. However in both 0.93 and 0.94 releases, the  

> image is not truncated and hence only rendered partially. I am  

> hereby attaching the FO file and the outputs from old and new fop.  

> Are there any known issues here?

 

Yes, the behavior in FOP 0.20.5 is non-compliant.

 

Take a look at the fo:external-graphic, and the XSL-FO Rec, more  

precisely:

 

http://www.w3.org/TR/xsl11/#d0e22982 (Area Dimension Properties)

 

You have no explicit (content-)width/height, so:

 

content-width="auto" => intrinsic image width

content-height="auto" => intrinsic image height

height="auto"

width="auto"

 

=> the image should not be scaled to fit the viewport, but clipped.

 

The trick is to set content-height and/or content-width explicitly to  

"scale-to-fit". That should normally do it.

 

Hope this helps!

 

 

Andreas

 

 

-

To unsubscribe, e-mail: [EMAIL PROTECTED]

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

 

RE: hyphenation problem

[Puppala, Kumar (LNG-CON)]

Hi Vicent,
   Thanks for the explanation for the FOP behavior that I am noticing.
In the testcase that I sent out earlier, there are some situations where
the word starts right on the border (for example, in 'on an employee's'
text, the last word start right on the border). Regardless of the
total-fit algorithm, I would have expected the word to start on the next
line instead of beginning on the table border. 

Our data contains all kinds of languages and special characters and it
is difficult to control what comes to us. We definitely need to go with
the approach where the word flows to the next line if it cannot fit
within the table-cell borders. The current total-fit algorithm does not
bode well with our system and I would like to make changes in my local
copy to get the desired behavior (as rendered by old FOP). If you can
point me in the right direction to accomplish this, I would greatly
appreciate.


Thanks,
Kumar Puppala

-Original Message-
From: Vincent Hennebert [mailto:[EMAIL PROTECTED] 
Sent: Friday, November 02, 2007 6:13 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: hyphenation problem

Hi Kumar,

Sorry for the delay, looks like I ended up forgetting this thread.

Puppala, Kumar (LNG-CON) wrote:
> Hi Vicent,
>I am not sure if I understand you. If you look at newFop.pdf(from
> previous mail), the 14th line in the table cell ( 'sion scheme') has
the
> overflow. It looks like the word 'scheme' started at the very edge of
> the table cell and the hyphenation did not occur. The oldFop.pdf file
> (generated using 0.20.5) demonstrates the correct behavior. 

The word 'scheme' cannot be hyphenated, so it can only be placed on one 
single line. But as it is wider than the column width, it would overflow

the column anyway.

What you see and which looks strange is a result of the total-fit 
algorithm: FOP optimizes line breaks for the whole paragraph, instead of

working one line at a time. If it chose to put 'sion scheme' on one 
line, that's because that leads to an less bad overall result than if it

had cut it.

That's the best it can do in such a special situation. Really, you 
should make sure that the column is at least wide enough to make all the

syllables fit on one line.


> The testcase does come from real-life usecases. In some of our
usecases,
> we do have table cells that accommodate only 1 character (which is
> usually a number).

Ok, but if you actually put only one character in such cells, you won't 
have any problem.

HTH,
Vincent

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


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

RE: Issue with Table spanning multiple pages

[Puppala, Kumar (LNG-CON)]

I tested the same failedTable.fo file against fop 0.93 version and it
works fine. Just an FYI if someone can relate this behavior to the fixes
added for 0.94.

 

Thanks,

Kumar Puppala

 



From: Puppala, Kumar (LNG-CON) [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, October 31, 2007 3:05 PM
To: fop-users@xmlgraphics.apache.org
Subject: Issue with Table spanning multiple pages

 

I am running into an issue with an fo:table that spans 2 pages. Instead
of starting the table on the current page, the table is rendered on the
next page. There seems to be some dependency on the numbers of columns
used in the table. Once I reduced the number of columns from 6 to 5 for
this table, it started rendering the table on the current page. Provided
with this mail are files describing this behavior:

 

failedTable.fo   --> initial fo file that exhibits the problem.

FT_newFop.pdf  --> PDF file generated using failedTable.fo using fop
0.94

FT_oldFop.pdf  --> PDF file generated using failedTable.fo using fop
0.20.5. This exhibits correct behavior.

succeededTable.fo --> Updated FO file that works. The only difference is
that I reduced one column on the table.

ST_newFop.pdf --> PDF file generated using succeededTable.fo using fop
0.94.

 

 

Any input on this issue is greatly appreciated.

 

 

Thanks,

Kumar Puppala

RE: hyphenation problem

[Puppala, Kumar (LNG-CON)]

Hi Vicent,
   I am not sure if I understand you. If you look at newFop.pdf(from
previous mail), the 14th line in the table cell ( 'sion scheme') has the
overflow. It looks like the word 'scheme' started at the very edge of
the table cell and the hyphenation did not occur. The oldFop.pdf file
(generated using 0.20.5) demonstrates the correct behavior. 

The testcase does come from real-life usecases. In some of our usecases,
we do have table cells that accommodate only 1 character (which is
usually a number).

Thanks,
Kumar

-Original Message-
From: Vincent Hennebert [mailto:[EMAIL PROTECTED] 
Sent: Friday, October 26, 2007 5:04 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: hyphernation problem

Hi Kumar,

Puppala, Kumar (LNG-CON) wrote:
> I had a similar problem. The below mentioned approach cannot be
applied
> in the testcase attached (tableIssue.fo) since the overflow occurs
even
> for regular English words. This used to work in fop 0.20.5
(oldFop.pdf).
> Any ideas how I can get past this problem?

Well, if there is not even enough space to make a syllable fit on the 
line, I'm not sure that much can be done. Does your document come from 
any real-life usecase?

Vincent

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


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

RE: hyphernation problem

[Puppala, Kumar (LNG-CON)]

I had a similar problem. The below mentioned approach cannot be applied
in the testcase attached (tableIssue.fo) since the overflow occurs even
for regular English words. This used to work in fop 0.20.5 (oldFop.pdf).
Any ideas how I can get past this problem?

Thanks,
Kumar Puppala

-Original Message-
From: fabio76 [mailto:[EMAIL PROTECTED] 
Sent: Thursday, October 25, 2007 11:17 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: hyphernation problem


Thanks a lot for your support.
It works correctly

Fabio



Manuel Mall wrote:
> 
> On Thursday 25 October 2007 22:25, fabio76 wrote:
>> Hi
>>
>> I have a problem in breaking, multi-line, codes containing only
>> characters and "_" (no space, see example).
>> For example if I have a table that contains a code like
>> ___A and this value is not in bigger that cell, fop
>> overflow.
>> I  use the fop with hypernation pattern (see attached file) and fop
>> 0.94. Someone knows how to customize the file or have another
>> solution?
>>
> You could insert a Unicode Zero Width Space (​) or a Unicode
Soft 
> Hyphen (­) after each underscore to indicate to FOP a break 
> opportunity.
> 
> Manuel
>> Thanks
>>
>> Fabio http://www.nabble.com/file/p13407619/en.zip en.zip
>>
>>
>> Example
>>
>> This is a visual example of my problem:
>>
>> +---+--+
>> + FIELD 1+   FIELD2  +
>> +---+--+
>> + 1234+ __+A
>> +---+--+
>>
>> correct format:
>>
>> +---+--+
>> + FIELD 1+   FIELD2  +
>> +---+--+
>> + 1234+ __+
>> +   + A  +
>> +---+--+
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context:
http://www.nabble.com/hyphernation-problem-tf4691131.html#a13409064
Sent from the FOP - Users mailing list archive at Nabble.com.


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



tableIssue.fo
Description: tableIssue.fo


oldFop.pdf
Description: oldFop.pdf


newFop.pdf
Description: newFop.pdf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

wrapping issue within Tables

[Puppala, Kumar (LNG-CON)]

I am noticing that the word wrapping within a table cell is not working
as desired. I am hereby attaching a sample FO file along with the
outputs from old (0.20.5) and new FOPs (0.94). I am using fop-hyph.jar
file when rendering the file using new FOP. Are there any known issues
here?

 

Thanks,

Kumar Puppala



newFop.pdf
Description: newFop.pdf


tableIssue.fo
Description: tableIssue.fo


oldFop.pdf
Description: oldFop.pdf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Issue with fo:markers

[Puppala, Kumar (LNG-CON)]

We are transitioning to 0.94 version from 0.20.5. We are noticing an
issue with fo:markers with the new FOP. If an fo:marker is placed
directly under an fo:block, it works. But if I place it directly under
an fo:inline, it does not work. Attached with this mail are examples for
both scenarios (fo and pdf files). I cannot go with the fo:block
approach since it introduces a new line and hence breaks the text. I
need to have the text continue on the same line. Any help is
appreciated.

Thanks,
Kumar Puppala

-Original Message-
From: Miroslav Pukhalsky [mailto:[EMAIL PROTECTED] 
Sent: Friday, September 07, 2007 9:31 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: Trouble with page header

Hello Andreas,

Andreas L Delmelle wrote:
> On Sep 4, 2007, at 12:07, Miroslav Pukhalsky wrote:
> 
> Hi
> 
>> I have a trouble with page header.
> 
> Not sure if I follow, but I see a remote possibility for a solution,
but 
> it depends on whether the table /always/ starts its own page or not.
:/
> 
> Maybe you can implement the caption as an fo:marker/fo:retrieve-marker

> pair. Include the marker only somewhere in the first row, so that for 
> all but the first page, the reserved space in the page-header will be 
> left empty, but still occupied by the header (?)
> 
> 
> It's a long shot, but hope it helps.
> 
It is not what I want. The table can start in ANY place on page. The 
page can contains more than one table or only table part or previous 
table tail and next table begin. And only when table starts from page 
begin I need to get my desired view.

>>  for
construction 
>> block is not working. May be do I something wrong?
> 
> You're not doing anything wrong. IIC, relative-position is not 
> implemented, yet.
> 
It's a pity.

Regards,

Miroslav.

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


NotWorkingMarker.fo
Description: NotWorkingMarker.fo


WorkingMarker.pdf
Description: WorkingMarker.pdf


workingMarker.fo
Description: workingMarker.fo


NotWorkingMarker.pdf
Description: NotWorkingMarker.pdf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: text-align="justify" issues

[Puppala, Kumar \(LNG-CON\)]

Andreas,
  I removed white-space-treatment property from my fo:block and
everything works fine. I thought that it was a bug since I could see the
same FO work properly in old FOP but not in the new one. Thanks for the
clarification.

Thanks,
Kumar Puppala

-Original Message-
From: Andreas L Delmelle [mailto:[EMAIL PROTECTED] 
Sent: Saturday, September 15, 2007 9:35 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: text-align="justify" issues

On Sep 15, 2007, at 14:26, Andreas L Delmelle wrote:

Just thought I'd add for the sake of clarity:

> On Sep 13, 2007, at 15:20, Puppala, Kumar (LNG-CON) wrote:
>
>> Hi Vincent,
>>   Thanks for your suggestion. Removing white-space-treatment  
>> property got me a correct result.
>
> The result *with* white-space preservation is also correct (don't  
> confuse 'unexpected' with 'incorrect').
> 
> It's not a bug, but a feature. ;-)

Given that the issue arose in a transition of FOP 0.20.x to 0.9x, the  
*only right way* to deal with it is to adapt the stylesheet to not  
use white-space-treatment="preserve" anymore, unless when it is  
absolutely necessary to do so. In the provided example, the property  
serves no purpose at all, so should best be removed.

In FOP 0.20.x, white-space-treatment was necessary to preserve  
linefeeds, which is non-compliant behavior. The two properties white- 
space-treatment and linefeed-treatment operate independently of each  
other.
Firstly, linefeeds are either preserved, ignored or converted to a  
space.
Then the space-characters, after having treated the linefeeds, are in  
their turn preserved or ignored.
In a first pass --in XSL-FO terms: refinement stage--, by only  
looking at explicit linebreaks, like start- or end-of-block or  
preserved linefeed characters.
Further on, in a second pass --in XSL-FO terms: area tree building--,  
the implicit formatter-generated linebreaks also enter the equation.

Add white-space-collapse into the mix to further control whether  
series of spaces should be replaced by one space character.

Finally, there is also the suppress-at-line-break property one could  
use on individual fo:characters, to specify the behavior for a single  
character (regardless of whether it is white-space or not).


Cheers

Andreas


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

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

RE: text-align="justify" issues

[Puppala, Kumar \(LNG-CON\)]

Hi Vincent,
  Thanks for your suggestion. Removing white-space-treatment property got me a 
correct result. I may be able to use this as a workaround for now. We did add 
that property on the block for a specific reason and I will try to figure out 
what else I might be breaking if I take that out of my fo:block elements. I 
will also keep looking at the code related to whitespaces handling. If anyone 
is able to resolve this issue (or have suggestions how to fix it), please post 
it.

Thanks,
Kumar Puppala

-Original Message-
From: Vincent Hennebert [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 13, 2007 4:39 AM
To: fop-users@xmlgraphics.apache.org
Subject: Re: text-align="justify" issues

Hi Kumar,

Indeed there seems to be something going wrong, caused by the 
white-space-treatment property. Your change seems to fix part of the 
problem, although I'd have to study it into more details. Sorry, right 
now I have no time for that. If someone else wants to take the lead...
Properties related to the handling of whitespaces are a bit complex and 
not easy to grasp correctly.

Note that if you remove the white-space-treatment property (or leave  it 
to its default value) you will get a correct result. Maybe you can avoid 
using it? You would have something working while waiting for the issue 
to be corrected.

Vincent


Puppala, Kumar (LNG-CON) a écrit :
> Thanks for the response. I am hereby providing a sample FO file along with 
> outputs generated using fop 0.20.5 and 0.94.
> 
>  
> 
>  xmlns:lnsm="http://www.lexis-nexis.com/lnsm"; 
> xmlns:lnvx="http://www.lexis-nexis.com/lnvx"; 
> xmlns:lnv="http://www.lexis-nexis.com/lnv"; 
> xmlns:lnvxe="http://www.lexis-nexis.com/lnvxe"; 
> xmlns:lnclx="http://www.lexis-nexis.com/lnclx"; 
> xmlns:fo="http://www.w3.org/1999/XSL/Format";>  master-name="cover-end-page-first" page-height="11in" page-width="8.5in" 
> margin-top=".5in" margin-bottom=".5in" margin-left=".9in" 
> margin-right=".9in"> column-count="2"/> master-name="cover-end-sequence"> master-reference="cover-end-page-first"/>  master-reference="cover-end-sequence" force-page-count="no-force" 
> initial-page-number="1" > white-space-treatment="pre
serve" white-space-collapse="false" color="#00" font-family="Times" 
text-align="justify" font-weight="normal" font-style="normal" 
text-decoration="no-underline" font-size="10pt" line-height="1.35" >Testing Apportionment 
Apportionment Apportionment Apportionment Apportionment Apportionment 
Apportionment Apportionment Apportionment Apportionment calls for the exercise 
of an informed judgment on a consideration of many 
factors.
> 
> 
> If you notice these outputs, you will see that the second line clears shows 
> that justification is not working properly. I was playing with the order of 
> the elements created for a space in TextLayoutManager.java and was able to 
> align the text properly on the left (refer to newFopUpdated.pdf) but still it 
> does not justify properly on the right. The change I did to get it aligned 
> properly on the left is:



-
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]

text-align="justify" issues

[Puppala, Kumar \(LNG-CON\)]

We have been using apache fop 0.20.5 and are planning to switch to .94
version. One difference I noticed between the two is when we have
text-align="justify" set on an fo:block. I don't see the text justified
properly as it used to do in the previous version( 0.20.5). The text is
rendered in dual column layout. If the text was rendered in Single
column layout, the very first line of the paragraph seems to be off
compared to the other lines. However, the remaining lines seem to be
justified properly. Are there any known issues here? I was going through
the 'known Issues' list for fop 0.94 and it does mention about word
spacing not working as expected. The corresponding testcase is named
block_word_spacing_text_align_justify.xml. There is not a whole lot of
information provided on this issue. For the pudits on this forum, do you
see any correlation between the issue I am facing and the one already
documented? If so, are there any workarounds.

PS: The same problem was also seem in 0.93 version.

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