You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Martin Edge <Ma...@asmorphic.net.au> on 2008/06/02 03:55:55 UTC

Do errors from FOP slow down overall processing time?

Hey Guys,

If I am receiving errors like this - would it affect the processing speed?

SEVERE: Ignoring property: margin-top=""
(file:/E:/work/printer_test/test.fo:171959:44: No conversion defined ;
property:'margin-top')
2/06/2008 11:51:19 org.apache.fop.fo.FONode attributeWarning
WARNING: Warning(171985/87): fo:table, only a value of "auto" for
block-progression-dimension has a well-specified behavior on fo:table.
Falling back to "auto"
2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
updateData2
WARNING: Part/page 0 overflows the available area in block-progression
dimension. (fo:block-container, location: 171954/94)
2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
updateData2
WARNING: Part/page 0 overflows the available area in block-progression
dimension. (fo:block-container, location: 171954/94)
2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
updateData2
WARNING: Part/page 0 overflows the available area in block-progression
dimension. (fo:block-container, location: 171954/94)
2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
updateData2
WARNING: Part/page 0 overflows the available area in block-progression
dimension. (fo:block-container, location: 171954/94)
2/06/2008 11:51:22 org.apache.fop.fo.PropertyList convertAttributeToProperty

Also notice that whilst It's processing it isn't obviously bashing disk, cpu
or memory.. but still seems to be slow.. perhaps this is the java memory
allocation restrictions that was mentioned?

Sorry if I'm asking a -lot- of questions.. I am doing what research I can..
:) 

Thanks
Martin.



---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org


Re: Do errors from FOP slow down overall processing time?

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
A lot of log output can decrease performance because of I/O
synchronisation. Just the error/warning condition itself shouldn't
noticably affect performance.

The fact that you don't see the CPU near 100% or a lot of disk I/O could
indicate that streams are not properly buffered, i.e. decorated with
BufferedInput/OutputStream. See also:
http://xmlgraphics.apache.org/fop/0.95/embedding.html#performance
OTOH, FOP isn't multi-threaded so it can only drive one core/CPU to
nearly 100%.

On 02.06.2008 03:55:55 Martin Edge wrote:
> Hey Guys,
> 
> If I am receiving errors like this - would it affect the processing speed?
> 
> SEVERE: Ignoring property: margin-top=""
> (file:/E:/work/printer_test/test.fo:171959:44: No conversion defined ;
> property:'margin-top')
> 2/06/2008 11:51:19 org.apache.fop.fo.FONode attributeWarning
> WARNING: Warning(171985/87): fo:table, only a value of "auto" for
> block-progression-dimension has a well-specified behavior on fo:table.
> Falling back to "auto"
> 2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
> updateData2
> WARNING: Part/page 0 overflows the available area in block-progression
> dimension. (fo:block-container, location: 171954/94)
> 2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
> updateData2
> WARNING: Part/page 0 overflows the available area in block-progression
> dimension. (fo:block-container, location: 171954/94)
> 2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
> updateData2
> WARNING: Part/page 0 overflows the available area in block-progression
> dimension. (fo:block-container, location: 171954/94)
> 2/06/2008 11:51:22 org.apache.fop.layoutmgr.PageBreakingAlgorithm
> updateData2
> WARNING: Part/page 0 overflows the available area in block-progression
> dimension. (fo:block-container, location: 171954/94)
> 2/06/2008 11:51:22 org.apache.fop.fo.PropertyList convertAttributeToProperty
> 
> Also notice that whilst It's processing it isn't obviously bashing disk, cpu
> or memory.. but still seems to be slow.. perhaps this is the java memory
> allocation restrictions that was mentioned?
> 
> Sorry if I'm asking a -lot- of questions.. I am doing what research I can..
> :) 
> 
> Thanks
> Martin.
> 
> 


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org