Dear Wiki user, You have subscribed to a wiki page or wiki category on "Xmlgraphics-fop Wiki" for change notification.
The following page has been changed by JeremiasMaerki: http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback The comment on the change is: More brainstorming ------------------------------------------------------------------------------ * User-oriented feedback from FOP in general should be available per processing run (as opposed to debugging output currently provided by Commons Logging). * The layout engine should be able to provide some information per-page, for example: An important information for users producing book-style documents is, for each page, the difference between the available page heigth and the actual content height. Even if it is not a real "error" to create unfilled pages, underfull pages are not beautiful. This information, that could be taken from the !PageBreakPositions, would allow users to easily check if fop produced "good" pages without the need to open the pdf and look at it. * Furthermore, editor writers might be interested to know what IDs ended up on which page to provide quick "jump-to-problem" functions, for example. + * Messages should be localized. At least English messages will be provided by FOP and it should be easy for users to contribute translations with a fallback to English messages if a translation is missing. Ideally, there's a check mechanism that makes sure there's at least an English message for each event/message. + + == Brainstorming for event types == + + ''(Note: this is not a complete listing, just exemplary!)'' + + * Validation problems + * Invalid child (Params: context element, location) + * Missing child element (Params: context element, location) + * Missing property (Params: property name, context element, location) + * Nodes out of order (Params: context element, tooLateNode, tooEarlyNode, location) + * Too many nodes + * Invalid property name + * etc. etc. etc. + * Layout problems + * Line overflow (warning or error if overflow="error-if-overflow") + * Page overflow (warning or error if overflow="error-if-overflow") + * Various table-related warning (such as "column-width not set" or "row-height constraint violation") + * etc. etc. etc. + * Resource problems + * Image not found (Params: URI, context element, location) + * Image provision/conversion problem (Params: URI, context element, location) + * Font loading problem (Params: URI) + * Configuration error + * etc. etc. etc. + * Rendering problems + * Unresolved destination (Params: ID) + * Paper selection problem (PCL, Params: page number, page size, fallback paper type) + * etc. etc. etc. + * Progress + * Document started + * Start page-sequence (Params: ID) + * End page-sequence (Params: ID, statistics) + * Page produced (i.e. unresolved, Params: page index/number) + * Page completed (i.e. fully resolved and sent to renderer, Params: page index/number) + * Document complete (Params: statistics) + + Many of these events are considered warnings by some users and errors by others. Some don't care about overflows while others want to know about it. Thus the need for being able to throw an Exception on some events/event categories. = Suggestions = @@ -75, +113 @@ Drawbacks: * Unusable for us until the license is changed from LGPL to something that's on the allowed licenses list: http://www.apache.org/legal/3party.html - * Unusable for us until we migrate to Java 1.5 because it uses annotations. + * Needs Maven for code generation. No Ant task available, yet. + * Localization of the error messages doesn't seem to be available, yet. ''Comment by JeremiasMaerki: Thanks, Wilfred, for your suggestion and for writing this up. But I don't think it's going to happen this way in the short term because of the above points. Furthermore, I'm very allergic to Maven.'' ''Comment by WilfredSpringer: I could change the license, and the annotations are JavaDoc-type of annotations. Think commons-attributes. In this case it's based on QDox, so you don't have to worry about Java 1.5.'' + ''Comment by JeremiasMaerki: I've removed the point about Java 1.5. You were right, of course. I just saw "@"s and thought they were annotations. I took a closer look now. A problem for us would be the current necessity for Maven for code generation. We'd need an Ant task. I get the impression that the main focus is on logging those events to a logging subsystem. For us, I think, this would only be a side-show. The most important is for the user to install an event listener so all events (including all parameters) can be inspected and acted upon (including throwing exceptions). My proposal: I'm going to sketch out a proposal (without Blammo) that I think would meet the requirements of FOP and then we can see if and how Blammo could maybe accommodate this and if it would be worth adding such a dependency. + --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
