> which are relatively harmless - like content being split over multiple pages, or which are pretty fatal - like content disappearing over the right hand margin.
Well, that certainly is by your definition but I could easily see others having differing opinions. Like if someone had a table with 3000 rows and set keep-together on it or keep-with-next on the rows, it would throw at least a blank page because it could not fit on the first and then the keep would be broken. Depending on how they set it, it could result in multiple blank pages interspersed with others. It could also come from having a block-container as the first element of a page-sequence and set a break-before on it (and nothing happens in this case, although the warning is thrown).
What forms a list for you for stopping or not stopping is likely your list and not the consolidated list of all. And RenderX was designed to be a batch-formatting solution.
We have a competing set of requirements that come from our customer base. Requirements like this ask us to delve and record all things within the engine (as this one does as you would like to know externally to the engine in the middle of batch formatting all the parameters surrounding the formatter not being able to fit something). This literally means a recording of information to be reported should a condition exist. We also have requirements from the customer base to make things as fast as possible in as little memory. These two things compete without a doubt.
What we can look at is what information is available through the existing API at the time the warning occurs to see if additional information could be passed to the logger for "No space for an element". But I would say that we would not likely be able to do more than that as it would entail modifying the actual core to record more in order for it to be reported and expose more methods for that to happen. This is highly unlikely as it would most likely add significant performance degradation while increasing memory consumption.
Kevin Brown
RenderX
-----Original Message-----
From: John Maddock [mailto:boost.regex@virgin.net]
Sent: Friday, September 28, 2012 1:47 AM
To: kevin@renderx.com; RenderX Community Support List
Subject: Re: [xep-support] Re: Abort when Image File not found?
> Thomas/John and anyone else who wishes to respond.
>
> I have someone who may be willing to do this -- question on Specs:
>
> Other than image not found, is there any other "warning" you wish to
> abort on?
>
> Just from memory -- warnings could be:
>
> Image not found
> Font asked for not found and is being replaced by default font
No but, this reminds me of the "no space for an element trying to recover"
error message - did it recover or not?
The issue here is that the message may be produced for things which are relatively harmless - like content being split over multiple pages, or which are pretty fatal - like content disappearing over the right hand margin. So ideally I'd like to see:
* More information on why the message was produced.
* Was reformatting successful or is content actually lost?
To put this in perspective, at Boost we automatically generate ~70 PDF manuals from Docbook XML each up to 1200 pages long. It is literally impossible to proofread them all before doing a release, so we're relying on XEP's messages to tell us if anything has gone wrong. Manually checking every "no space for an element" is equally impossible, so we basically rely on user bug reports to tell us if anything has been messed up in formatting.
So the really important thing I'd like from those messages is some indication of whether formatting recovered (because the space that was lacking was vertical space and splitting over multiple pages worked), or whether it was lacking horizontal space and content was truncated.
Thanks, John.
_______________________________________________
(*) 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 Fri Sep 28 10:59:19 2012
This archive was generated by hypermail 2.1.8 : Fri Sep 28 2012 - 10:59:24 PDT