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