xmlgraphics-fop-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Xmlgraphics-fop Wiki] Update of "ProcessingFeedback" by JeremiasMaerki
Date Tue, 02 Aug 2005 13:05:59 GMT
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:
Notes as seen on the mailing list plus some more ideas

New page:
= What we have =

 * Commons Logging
 * !ElementListObserver (useful for developers only)
 * !FormattingResults (recently ported from 0.20.5)

= Problems =

Commons Logging logs through static variables so it is difficult to separate feedback in a
multi-threaded environment. Also, logging is actually mostly useful for developers, not necessarily
for users. Verbose settings from the command-line will now produce a lot of alien-looking
stuff.

!FormattingResults is only a very simple solution. It fits some people's needs but is limited.

= Further needs and wishes =

 * Call backs from inside the layout engine alerting the calling application about layout
problems such as overflows, missing resources, validation warnings and errors.
 * Some applications need to be stricter about layout problems and may choose to veto some
warnings which should effectively throw an exception and halt processing.
 * FO editor writers will want to provide better feedback during design/preview time for their
users when problems arise. They need some sort of location and context information that can
be given back.
 * In mass document production environment it is important to have a mechanisms in place that
allow identifying anomalies.
 * For machine-interpretation all events should have an ID and for human-interpretation feedback
from FOP should eventually be translated in the user's own language because many error messages
may be difficult to understand.
 * For some embedded use cases, additional hooks for providing images as !BufferedImages or
via Graphics2D would be very nice as it could spare some people writing a FOP extension. We
already have a stream insertion (or rather custom URI resolution) hook in FO!UserAgent.
 * 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 which, for example,
indicates whether a page has been filled up to the bottom with content or not. 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.

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


Mime
View raw message