Re: AWTRenderer: getting the absolute position of an area
Salut Renaud I wondered about that, too: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481 So far, I can only say that there's so mandatory reason for that change. It would certainly make the renderers simpler but there might be problems in other areas. The real downside is when you have to do the same calculations in every renderer. Some can be (and already are) put in AbstractRenderer but for others this is not so easily possible. No definitive answer from me. We'll see what comes out of the page-break rewrite. On 22.02.2005 20:28:56 Renaud Richardet wrote: bonjour fop-dev's i've been walking through the rendering process. if i understand it rightly, an area doesn't records it's absolute position. therefore, we have to pass the currentIPPosition, currentBPPosition all along during the rendering process to figure out where to position an area. what i don't understand: this information (the absolute position of an area) MUST somehow have been known during the building of the area tree (otherwise we could'nt know where to break the pages). so my question: wouldn't it be easier to record the absolute position of an area during the page-breaking process? or am i missing something? renaud PS: the abstract Java2DRenderer sounds like a really good deal to me :) Jeremias Maerki
Re: AWTRenderer: getting the absolute position of an area
hello Jeremias merci for the informations. I wondered about that, too: http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]by=threadfrom=984481 interesting! Victor, in [1] you talked about dealing with the positioning of areas during the AreaTree building. could you point me to the classes in FOray that handle that logic? So far, I can only say that there's so mandatory reason for that change. It would certainly make the renderers simpler but there might be problems in other areas. The real downside is when you have to do the same calculations in every renderer. ok, that's what i was affraid of... but i understand that the area tree building is already enough complex. well, i'll base the Java2DRenderer on the pdf renderer. could someone tell me if it's stable enough (especially those tricky issues like reference-orientation and writing-mode that i don't completely understand yet). Some can be (and already are) put in AbstractRenderer but for others this is not so easily possible. No definitive answer from me. We'll see what comes out of the page-break rewrite. ok, good luck. i'm looking forward to see your rewrite. renaud [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]msgNo=10534
Re: AWTRenderer: getting the absolute position of an area
On 22.02.2005 22:35:15 Renaud Richardet wrote: snip/ So far, I can only say that there's so mandatory reason for that change. It would certainly make the renderers simpler but there might be problems in other areas. The real downside is when you have to do the same calculations in every renderer. ok, that's what i was affraid of... but i understand that the area tree building is already enough complex. well, i'll base the Java2DRenderer on the pdf renderer. could someone tell me if it's stable enough (especially those tricky issues like reference-orientation and writing-mode that i don't completely understand yet). Well, the PDF Renderer is our reference renderer and it's the only one that is currently actively maintained. I'll get to the PostScript renderer later. Just concentrate on the simple things first. No need to worry about the writing mode already. The reference orientation is simple. It's just a matter of getting the transformations right. Run the simple test cases from the layout engine test suite and work from simple to more complicated. snip/ Jeremias Maerki
RE: AWTRenderer: getting the absolute position of an area
Renaud Richardet wrote: Victor, in [1] you talked about dealing with the positioning of areas during the AreaTree building. could you point me to the classes in FOray that handle that logic? ... [1] http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED] l.apache.orgmsgNo=10534 Hi Renaud: The main classes where you can see this logic are Area, AreaFixed, and AreaFlexible. However some of the methods are overridden in subclasses, esp. LineArea, since it is the pivot concept between BPD-stacking and IPD-stacking Areas. See especially the methods that start with br (border rectangle), pr (padding rectangle), cr (content rectangle), and rr (render rectangle, a concept invented for dealing with adjustments to the content rectangle for things like justification). See also the methods setProgressionDimension, incrementProgressionDimension, setAnteriorSpace, and incrementAnteriorSpace where the sizes of the area and its resolved before or start space is stored. I have to give you a bunch of caveats. There is still a bunch of the old stuff in those classes that I haven't gotten around to removing yet. The location computation stuff works reasonable well ATM, but a lot of the supporting code has serious problems, so you will get NPEs, etc. with even simple documents. This is a work in progress. Also, I haven't implemented only some of the necessary writing-mode and reference-orientation changes. I am kind of torn ATM between nailing this down solidly and trying to get a usable release done. From a speed standpoint, FOray's approach may be sub-optimal. Each Area computes its location relative to its parent's. The philosophy behind it is that I want to store stuff only once, not so much to save memory, but more to reduce confusion about the proper place to go for the data, and (importantly) to get layout to the place where it doesn't know or care about the location, orientation, or writing-mode of an area, only its size. At some point, we may find that it is beneficial to cache the intermediate computations for performance. It is not important to me ATM. The ViewCVS of the classes mentioned is here: http://cvs.sourceforge.net/viewcvs.py/foray/foray/foray-areatree/src/java/or g/foray/area/ Victor Mote
Re: AWTRenderer: getting the absolute position of an area
Victor, thanks for your explanations. i'll give a look into FOray when i'll feel more confident about the layout process. cheers, Renaud
