Hello Keiron

Aaahh, sounds good to me. Just to be sure: For layout problems such as
overflows the FO "overflow" property tells the user agent if an
error condition has to be signaled. But what about things such as images
that couldn't be loaded. I can imagine that this might not always be a
condition to throw an Exception, especially maybe for FO editors using
FOP for preview or during development, when you don't want FOP to stop
as soon as problem occurs. In this case the user agent would probably be
configured to halt or continue when a problem occurs. And the user agent
would be the central point of problem handling instead my idea of a
ProblemListener. Right?

And by the way: I'm really happy to see MessageHandler go! One more step
towards a multithreading-friendly FOP. This is great!

On Thu, 22 Nov 2001 10:35:04 +0100 Keiron Liddle wrote:
> Hello Jeremias,
> As far as the spec is concerned. If an error occurs it usually says (if 
> there is any information at all) that the user agent should handle the 
> situation by doing cetain things, eg. using a fallback value.
> For layout problems (such as the one you mentioned) there is a specific 
> property that indicates if there is an error if the contents overflow the 
> containing area. In this case for example FOP "may recover" by clipping to 
> the area.
> I think that it would be easier to incorporate this into the user agent (I 
> am referring to the class FOUserAgent which implements the concept of the 
> user agent). The user agent is supposed to handle these sort of things 
> anyway.
> The user agent could also handle the logging output, this way we could 
> incorporate more information into the logging messages.
> Regards,
> Keiron
> On 2001.11.21 11:14 Jeremias Maerki wrote:
> > Hello Karen, Keiron and others interested...
> > 
> > I've been using FOP in a specially modified version derived from version
> > 0.15 (CVS), because I had to have some special duplex functionality. Now,
> > I'm in a major redesign of the application and I'm going to do the
> > duplexing stuff differently. That way I'll be able to stick to the
> > standards and can use a more current version of FOP. And that's where I
> > stumbled upon my code that tries (!) to determine if a FOP job should be
> > considered success or failure (for example because of layout problems
> > etc.).
> > 
> > Basically what I'd like to have is some kind of ProblemListener (similar
> > to the ErrorListener in JAXP 1.1 (javax.xml.transform.ErrorListener))
> > which reports (especially) layout problems separated from other errors.
> > In a production system you will want to have better control over what
> > should go through and what not. The logging output is not really suitable
> > for this. A default ProblemListener should probably do the logging of
> > problems.
> > 
> > I think I can identify 3 kinds of problems (are there more?):
> > - FO(+SVG?) problem (ex. only one flow per page-sequence permitted)
> > - Layout problem (ex. "Sum of fixed column widths 348659 greater than
> >   maximum specified IPD 340158", the cryptic ">")
> > - environmental problem (IOExceptions etc.)
> > 
> > I'd love to hear what you think about this. I'm sorry not to be more of
> > a help right now. I'm really aching to do some things in FOP (especially
> > the PSRenderer and reworking static stuff) but I simply don't have the
> > time. I hope very much to be able to help again starting Feb 2002, maybe
> > sooner. Got to get that big project going first...
> > 
> > Cheers,
> > Jeremias Märki
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]

Jeremias Märki


Postfach 3954 - Rhynauerstr. 15 - CH-6002 Luzern
Fon +41 (41) 317 2020 - Fax +41 (41) 317 2029
Internet http://www.outline.ch

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to