Bug 30851 - [patch][enhancement] "No meaningful layout in block" --> better location in FOPException
Summary: [patch][enhancement] "No meaningful layout in block" --> better location in F...
Status: CLOSED DUPLICATE of bug 30852
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.20.5
Hardware: Other other
: P3 enhancement
Target Milestone: ---
Assignee: fop-dev
Depends on:
Reported: 2004-08-25 17:19 UTC by tagunov
Modified: 2012-04-01 13:48 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description tagunov 2004-08-25 17:19:52 UTC
While a new version of FOP is being designed and coded it would be highly benefitial to current FOP users to have

* more precise [systemId + line] reported when
  FOP is unable to generate a layout
  and endless loop terminator kicks in

* have getters for systemId, line, column on FOPException

In fact currently when FOPException with message

    No meaningful layout in block after many attempts.
    Infinite loop is assumed.  Processing halted.

is thrown it may produce very little infromation that would help user
to locate offending fo element. In our case it contained line/column for
our fo:root element!

The proposed patch goes down FObj tree following markers and thus
locates offending fo element (a too large png imange in our case)
pretty well.

Also, while we're at it, getters for systemId, line, column on FOPException
are also helpful (we currently have to parse parse getMessage() ).
Comment 1 Glen Mazza 2004-08-25 17:37:27 UTC
Thanks--we have this in our upcoming 1.0 version however.  FOPException is 
being downgraded/deprecated in much of the code in favor of SAXParseException, 
which already has methods to provide locator (line, col, sys id) information. 

I'm inclined not to make this change in our 0.20.5 version--the branch is 
frozen, and we're trying to emphasize resources with 1.0, but am keeping this 
open in case other committers feel differently.


Comment 2 tagunov 2004-08-25 18:17:11 UTC

*** This bug has been marked as a duplicate of 30852 ***
Comment 3 Glenn Adams 2012-04-01 13:48:10 UTC
batch transition to closed remaining pre-FOP1.0 resolved bugs