Re: [PATCH] Support for percentages and table-units
Somehow, in our current design, the information must be stored in an object that exists: [J.Pietschmann] IIRC that's what the layout context was meant for. Perhaps, but I doubt it. If they was change to always get a reference to the parent layout context when they are created, and if they had a reference to the FObj, and if they was made available to the property subsystem, then they could properly be used for it. I still think it is easier to use either the FOs or the LMs . regards, finn
Re: [PATCH] Support for percentages and table-units
[Simon Pepping] If in the re-use the layout would not change, the area tree could be reused. OTOH, if the layout would change, e.g. because another renderer would use a font with a different font metric, the layout information in the FO tree cannot be reused. The layout dimension that is stored in the FO tree is constantly updated during discovery of BreakPoss'es and is never reused, not even when a block is split over a break where new values are assigned. The solution I propose makes it impossible to run two different renderers concurrently, but it does not in any way prevent the FO tree from being reused with another renderer after the first rendering is finished. This is another argument to separate FO tree and layout information. No, not really IMO. regards, finn
Re: [PATCH] Support for percentages and table-units
Finn Bock wrote: > Perhaps, but I doubt it. If they was change to always get a reference to > the parent layout context when they are created, and if they had a > reference to the FObj, and if they was made available to the property > subsystem, then they could properly be used for it. The layout context has the actual IPD MinOptMax. There is no inherent reason it should have a link to a parent context or the property subsystem, it's only necessary to have a method to resolve a property expression given a set of MinOptMax for the various traits which can be used as references for percentages. Like textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext); > I still think it is easier to use either the FOs or the LMs . Maybe. J.Pietschmann
Re: [PATCH] Support for percentages and table-units
> Perhaps, but I doubt it. If they was change to always get a reference to > the parent layout context when they are created, and if they had a > reference to the FObj, and if they was made available to the property > subsystem, then they could properly be used for it. [J.Pietschmann] The layout context has the actual IPD MinOptMax. There is no inherent reason it should have a link to a parent context or the property subsystem, it's only necessary to have a method to resolve a property expression given a set of MinOptMax for the various traits which can be used as references for percentages. Like textIndent=propertyManager.get(TEXT_INDENT).resolve(layoutContext); Right, but it doesn't have all the base lengths. For some base lengths it is one of the parent layout contexts that has the trait, like ipd of the containing reference area. How could we get hold of that trait if the LayoutContexts isn't linked together? Whatever object that is passed to the resolve() method must also AFAICT also have a reference to the FO so that the resolve() can find the right LayoutContext in the LayoutContext tree to use as base. Perhaps I'm missing something fundamental in your suggestion, but I just can see how there is enough information in a single LayoutContext to resolve relative lengths that is inherited from a parent fo:element. > I still think it is easier to use either the FOs or the LMs . Maybe. Well, the approach using FOs are here already. It can't get easier than that. regards, finn
Re: [PATCH] Support for percentages and table-units
--- Finn Bock <[EMAIL PROTECTED]> wrote: > > The layout dimension that is stored in the FO tree > is constantly updated > during discovery of BreakPoss'es and is never > reused, not even when a > block is split over a break where new values are > assigned. > I don't know enough to comment too much on which implementation would be better here, but the spec does not appear to have much problem (see [1], also Finn's earlier reference to the spec's conceptual procedure [2]) with back-and-forth processes, updates, etc. between the FO Tree and Area Tree. Indeed, it seems to indicate that this kind of interaction does need to occur for the process to work correctly. Now if would be faster or more efficient to do so, that may be another issue. But Finn's ideas seem to be sufficiently in agreement with the spec. [1] http://marc.theaimsgroup.com/?l=fop-dev&m=107503563018878&w=2 [2] http://marc.theaimsgroup.com/?l=fop-dev&m=107688130007968&w=2 > The solution I propose makes it impossible to run > two different > renderers concurrently, but it does not in any way > prevent the FO tree > from being reused with another renderer after the > first rendering is > finished. > > > This is another argument > > to separate FO tree and layout information. > > No, not really IMO. > I think I agree with Finn on this issue. Reuse of the FOT/AT, i.e., re-rendering from the same input FO, but with a different output type, would probably be only a few percent of all usages of FOP. It is trivial enough that it should not weigh into the architectural decision, especially if doing so would (1) create a messier, hard-to-perfect design, or (2) slow things down for bulk of users not requiring this functionality. Stated another way, if those wanting both PCL and PDF for the same input FO would have to have the FOT & AT regenerated from scratch, we can live with that. For one thing, that's probably the current situation with the commercial renderers anyway. Also, a requirement for the FOT and AT to stay-in-memory and be reenterable may end up resulting in a rather buggy implementation. Glen
