RE: replace extension bookmarks with XSL 1.1 ones?
-Original Message- From: Glen Mazza [mailto:[EMAIL PROTECTED] Hi Glen, Very much in favor of changing the extension elements' names to conform with the XSL 1.1 WD, but since that's all it is ATM, a 'Working Draft', changing their namespace might be a bit premature (?[*]), unless we have some certainty WRT when it's going to be approved and will get the status of 'Recommendation'. Changing the names: +1 ... the namespace: -1 Greetz, Andreas [*] Surely someone here will remember MS's 'blunder' when they adopted an XSL-WD as a 'standard' too quickly...
Re: remove Runnable from PageSequenceLayoutManager?
On Tue, Dec 14, 2004 at 04:39:20PM -0800, Glen Mazza wrote: Team, PageSequenceLayoutManager implements Runnable, theoretically to allow for the layout of each page sequence on separate threads. The more complex logical aspects needed for this to happen (e.g., idref resolution, page numbering) though are not implemented, rendering this feature not very useful. We're not using Runnable now, and so I'd like to yank it before the upcoming release--it is easy to place it back in later if we do this in the future releases (although the more extensive logic will still need to be developed). Thoughts? Objections? It is true that nothing has been done to make threading a reality. I do not object to your removing the Runnable interface. Are you a fan of Extreme Programming? They seem to teach you to avoid adding future features. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
Re: Large files.
On Mon, Dec 13, 2004 at 02:26:40PM -0700, Victor Mote wrote: Simon Pepping wrote: The code you presented seems to be an algorithm implementing an iterator over a tree. Because it maintains its state, it can be stopped and resumed at will, provided you keep a reference to it. If LMIter would have a reference to its parent LMIter, and could return to it after having processed all the siblings, it would realize such a construct. One could stop the iteration, retain a reference to the active LMIter, and resume later. Not being dependent on the Java stack would make the programming much more robust. One would have more freedom to insert actions, without the fear to lose the iteration state if one would not carefully return to the same function. Such a construct would be equally suitable to pull parsing. The LMIter call to the LM method preLoadNext would request more child fo nodes, which the parser would provide on this demand. Do you want to traverse the FO tree, without relying on the Java stack, and drive the layout process from there by firing node events? Hi Simon: You responded to my last posting in this thread, but your questions seem to be directed to Finn, so I will let him answer them. Please let me know if I have misunderstood. Victor, You are right. I replied to the last message in the thread, but it contains questions to Finn. Sorry for being unclear. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
RE: replace extension bookmarks with XSL 1.1 ones?
--- Andreas L. Delmelle [EMAIL PROTECTED] wrote: the XSL 1.1 WD, but since that's all it is ATM, a 'Working Draft', changing their namespace might be a bit premature (?[*]), They're coming very close (I suspect in a few weeks at the latest) to having a Last Call version--would it be acceptable for you at that stage? I don't mind waiting a little longer. unless we have some certainty WRT when it's going to be approved and will get the status of 'Recommendation'. I'm more comfortable with Last Call. Last Call - Recommendation I suspect incurs lots of bureaucratic delays while having few changes to the spec itself. At any rate, we can always drop and add XSL-NS FO elements and properties as the spec itself is modified. Indeed, it's frequently the implementation of these FO's that allows for feedback that causes changes in the spec to occur. Changing the names: +1 ... the namespace: -1 Greetz, Andreas [*] Surely someone here will remember MS's 'blunder' when they adopted an XSL-WD as a 'standard' too quickly... Well we can also lose in the other direction. The main question appears to be what's the percentage chance of the 1.1 bookmark XSL FO's being dropped at this stage? If 10-20%, perhaps best to switch now and accept a 10-20% chance of needing to change our code later, rather than keep it in the fox: NS and have an 80-90% chance of needing to change it later to the fo: NS. Thanks, Glen
Re: [Phishing/Spam] Moderators: a bit more careful please
Jeremias Maerki wrote: Hmm, sorry, I didn't take into account that this address could be properly subscribed. I wonder how they did this because I don't think PayPal would use such an address to monitor our mailing lists. Very Yes, that's a bit scary but IIRC ezmlm has an option to subscribe under a different email adress. I'll bring this up on [EMAIL PROTECTED] And I just noticed that [EMAIL PROTECTED] and [EMAIL PROTECTED] are subscribed too (unsubsribing them now ..) Christian
