On 06 Jun 2011, at 10:59, Michael Rubin wrote: Hi Mike
> Thanks for your reply Andreas. > > Currently it is hardcoded to 10 nodes or leaves, but adding an xconf setting > perhaps should be pretty easy and quick to do. However, having spoken to my > manager, there isn't the business requirement currently to make it > configurable, and given the current large array of options already available, > the preference is to just keep it hardcoded for now. At the very least I'll > make sure the maximum leaves / subnodes value is stored in a constant so if > it is made configurable then only the constant needs to be paid attention to > rather than multiple locations in the class. OK, sounds good. I must admit, I was playing devil's advocate here, and did not see any immediate reason to be able to change it either, but you can probably bet your life that _someone_ is going to come up with this requirement as soon as the feature is discovered... :-) <snip /> > ... So for a 10,000 page doc there are going to be a lot of nulls in the page > tree. For now setting the toPDFString() to ignore the nulls rather than throw > an exception gets round this and allows the document to be correctly > generated. In my tests all the pages are produced in the correct order. I was > wondering though if there are any cases where the pages might not be passed > in in the correct order (and hence might possibly explain why the > notifyKidsRegistered() method was written in the way it is), and if so if > that has any implications on the way I have written the balanced page tree > code updates. I think the original idea was that PDF would, in the long run, also be able to do out-of-order rendering (i.e. if page N in a document would be completely resolved, and thus could be rendered, before page N-1 --in that case, the null reference would be needed as a placeholder for the not-yet-finished page). At any rate, AFAIR, this was never actually implemented for PDF, so that explains why you see all pages in the correct order every time. If it is cleaner to alter notifyKidRegistered() and avoid those nulls from being inserted in the first place, I would prefer that over just skipping them in toPDFString(). Not a must, though... Regards Andreas ---
