| Summary: | [patch][enhancement] "No meaningful layout in block" --> better location in FOPException | ||
|---|---|---|---|
| Product: | Fop - Now in Jira | Reporter: | tagunov |
| Component: | general | Assignee: | fop-dev |
| Status: | CLOSED WONTFIX | ||
| Severity: | enhancement | ||
| Priority: | P3 | ||
| Version: | 0.20.5 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | other | ||
| Attachments: |
The patch
Sample source files to test the patch The revised patch (prev variant contained bad formatting - tabs and a stray import) |
||
This patch is an enhancement to infinite loop terminator which was commited while fixing bug #8778 Created attachment 12529 [details]
The patch
Created attachment 12530 [details]
Sample source files to test the patch
Created attachment 12531 [details]
The revised patch (prev variant contained bad formatting - tabs and a stray import)
*** Bug 30851 has been marked as a duplicate of this bug. *** Glen's comment (from bug #30851) 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. Glen Glenn kept this open in case of… but said that it is only applicable to 0.20.5. What to do now? Latest FOP includes this functionality. The error messages were improved in a number of places. batch transition to closed remaining pre-FOP1.0 resolved bugs |
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 * 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 won't have to parse FOPException.getMessage() once we have them)