I second John Maddock's request. The phrase, "trying to recover", is a bit
of a tease. XEP should inform the user of the outcome. More important, we
should be told whether any information had to be dropped in order to make
the recovery successful.
<G>
At 03:44 PM 2/12/2011, Kevin Brown wrote:
>All:
>
> > The real problem with this situation is that the correct behavior would be
>
> > to report the error and stop processing
>
>Well that is certainly a debate. We have customers that run RenderX in such
>a way to create 100,000 statements in a single output file using
>applications like our VDPMill. Certainly they would not want that process to
>stop as it is possible that happens on the 99,999 statement. They certainly
>would do what any printer would do --- throw those pages from that one
>invoice (that fragment of XML document) to an exception bin and raise a
>message for the print operator that there was an issue. Although VDPMill
>splits large incoming files into chunks of a configurable size and formats
>them simultaneously in multiple threads, they would not even one of the
>chunks to abort -- just one of the documents.
>
>At RenderX, we tend to think along the lines that serve all our customer
>base and things like the above are a very large part of our customer base --
>generating huge print files for things like receipts, invoices, 401K
>statements, etc.
>
>This is a good discussion through and I can see some requirements bubbling
>up. Just like RenderX has a setting that can try (or not try) to format a
>document if the FO is invalid (DISCARD_IF_NOT_VALID) . We'll write something
>up and add to our internal requirements list:
>
>1) output messaging that enables a user to more closely track what object
>could be causing the problem (not sure about this one). I would think an
>image versus a table with keeps or a block with keeps could be flagged ...
>not sure.
>
>2) Add an option to continue or abort on encountering such a thing as a core
>option, defaulting to false as the regular (current) behavior but allowing
>the user to set up their system in such a way to abort on the condition if
>they want.
>
>The next release is in final testing right now, about two weeks away from
>release. These will be added into the next version.
>
>More on this in a few minutes in a separate email.
>
>Kevin
>
>-----Original Message-----
>From: xep-support-bounces@renderx.com
>[mailto:xep-support-bounces@renderx.com] On Behalf Of John Maddock
>Sent: Saturday, February 12, 2011 1:44 AM
>To: RenderX Community Support List
>Subject: [xep-support] Re: [error] no space for an element, trying to
>recover
>
> > The real problem with this situation is that the correct behavior would be
>
> > to report the error and stop processing, and not to try to recover at all,
>
> > because at this moment it is already clear that the rendered result does
> > not fully represent to the input source.
>
>I've asked about this before, but to reiterate: what I'd really like from
>this message is some indication of whether the processor did actually
>recover or not - for example I seem to get that message when a block (say a
>table) was too large for a page and got split over multiple pages - that for
>
>me is fine, where as dropping content off the right of the page is not. IMO
>
>the more info you can put into the error messages the better.
>
>Regards, John Maddock.
>
>
>
>
>
>_______________________________________________
>(*) To unsubscribe, please visit
>http://lists.renderx.com/mailman/options/xep-support
>(*) By using the Service, you expressly agree to these Terms of Service
>http://w
>ww.renderx.com/terms-of-service.html
>
>_______________________________________________
>(*) To unsubscribe, please visit
>http://lists.renderx.com/mailman/options/xep-support
>(*) By using the Service, you expressly agree to these Terms of Service
>http://w
>ww.renderx.com/terms-of-service.html
!DSPAM:87,4d59387363731594810637!
_______________________________________________
(*) To unsubscribe, please visit http://lists.renderx.com/mailman/options/xep-support
(*) By using the Service, you expressly agree to these Terms of Service http://w
ww.renderx.com/terms-of-service.html
Received on Mon Feb 14 06:13:22 2011
This archive was generated by hypermail 2.1.8 : Mon Feb 14 2011 - 06:13:33 PST