You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.nl> on 2005/07/31 11:55:00 UTC
Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
On Sat, Jul 30, 2005 at 03:35:07PM +0200, bugzilla@apache.org wrote:
> ------- Additional Comments From jeremias@apache.org 2005-07-30 15:35 -------
> Patch applied with some little modifications. Thanks a lot, Manuel!
>
> http://svn.apache.org/viewcvs?rev=226511&view=rev
I changed this to a notify mechanism, similarly to that already used
in PSLM.activateLayout to notify the Root FO of the same. This gives a
more direct access to the formatting results.
It would be a nice solution to let embedding apps register themselves
as a FormattingResultsListener in the user agent. apps.Fop could do
the same to present the user with the formatting results if he
requires verbose output.
Regards, Simon
--
Simon Pepping
home page: http://www.leverkruid.nl
Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
Posted by Jeremias Maerki <de...@greenmail.ch>.
I've put all this on the Wiki.
http://wiki.apache.org/xmlgraphics-fop/ProcessingFeedback
On 02.08.2005 11:36:59 Luca Furini wrote:
> Jeremias Maerki wrote:
>
> >I agree with the actual concept but I actually want something more
> >general in the long-term. There are various aspects that I'd like to
> >provide to embedders:
> >
> >- Number of pages over all and Number of pages for every page-sequence
> >(obviously)
> >- Callbacks on layout problems such as overflows, missing resources etc.
> >(on which the listener can veto and therefore cause an exception.) [1]
>
> 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 them, 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.
>
> Regards
> Luca
Jeremias Maerki
Re: DO NOT REPLY [Bug 35937] - [PATCH] Support for FormattingResults ported from 0.20.5 to 1.0
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 31.07.2005 11:55:00 Simon Pepping wrote:
> On Sat, Jul 30, 2005 at 03:35:07PM +0200, bugzilla@apache.org wrote:
> > ------- Additional Comments From jeremias@apache.org 2005-07-30 15:35 -------
> > Patch applied with some little modifications. Thanks a lot, Manuel!
> >
> > http://svn.apache.org/viewcvs?rev=226511&view=rev
>
> I changed this to a notify mechanism, similarly to that already used
> in PSLM.activateLayout to notify the Root FO of the same. This gives a
> more direct access to the formatting results.
Thanks!
> It would be a nice solution to let embedding apps register themselves
> as a FormattingResultsListener in the user agent. apps.Fop could do
> the same to present the user with the formatting results if he
> requires verbose output.
I agree with the actual concept but I actually want something more
general in the long-term. There are various aspects that I'd like to
provide to embedders:
- Number of pages over all and Number of pages for every page-sequence
(obviously)
- Callbacks on layout problems such as overflows, missing resources etc. (on
which the listener can veto and therefore cause an exception.) [1]
- Possibly additional hooks to insert images (via BufferedImage or
providing a Graphics2D). We already have a stream insertion (or rather
custom URI resolution) hook in FOUserAgent. Users have repeatedly asked
for easy ways to do stuff like that.
- there may be more.
And! We need to split debugging output from verbose user information!
Somehow.
[1] Could be very interesting particularly for editor creators and
people who want to be informed about every irrgularity in server-side
mass document production. Every kind of problem should have an ID
(machine-interpretation) and the error which go onto the log should also
be i18n-ized (human-interpretation).
Jeremias Maerki