Re: [PATCH] Support for percentages and table-units
If an expression reference another expression in a parent fo, the parent fo expression must be evaluated against the LayoutContext that was in effect for the parent fo and *not* against the child fo LayoutContext. fo:block id=a border-start-width=10% fo:block id=b border-start-width=inherit /fo:block /fo:block It must be the LayoutContex for 'a' that is used when we evaluate the 10% even when we call: propertyList.get(PR_BORDER_START_WIDTH).getValue(lc) with the layout context for 'b'. [Simon Pepping] [leader example snipped} The 30% must be calculated w.r.t. the page width for both leaders, and both leaders must be equally wide. This is not the current result. When I tried to remedy this, I got confused by the sets of symbols on PercentBase and on LengthBase. Why are there 2 sets of symbols? The idea was that PercentBase.XXX names the stored values and LengthBase names the algorithm for looking up a base value. Most of the time these maps one-to-one to each other but for some I imaged that they would be different. margin-top f.ex. should really use an algorithm like BLOCKIPD_OR_PAGEHEIGHT which would look for either PercentBase.BLOCK_IPD or PercentBase.PAGE_HEIGHT depending on the fo:element. Clearly all of this isn't complete implemented in my patch yet and perhaps it can be done in a simpler way. Better names for PercentBase and LengthBase could help. They are mapped onto each other in LengthBase.getBaseLength(), but not all symbols are mapped, e.g. LengthBase.CONTAINING_BOX, which is used by leader-length, has no corresponding action. Some further integration of old and new code must be done here. Correct. Question: What to do if I insert a fo:wrapper between fo:flow and fo:block? That makes it the parent of fo:block, but it has no layout manager corresponding to it. Override getLayoutDimension on it? I don't think so, but perhaps I don't just yet understand the situation that you are describing. A percentage on the wrapper should be resolved against the parent of the wrapper, right? regards, finn
Re: [PATCH] Support for percentages and table-units
[Peter B. West] Finn, When I apply your most recent patch (10366) against a cvs updated HEAD tree and attempt to compile, I get the following: [javac] /usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: After applying the patch (10366), the following files should be removed: src/java/org/apache/fop/fo/properties/LinearCombinationLength.java src/java/org/apache/fop/fo/properties/MixedLength.java Does anyone know how to include a file-remove in a patch? regards, finn
Re: [PATCH] Support for percentages and table-units
On Sat, Feb 21, 2004 at 12:24:24PM +0100, Finn Bock wrote: Question: What to do if I insert a fo:wrapper between fo:flow and fo:block? That makes it the parent of fo:block, but it has no layout manager corresponding to it. Override getLayoutDimension on it? I don't think so, but perhaps I don't just yet understand the situation that you are describing. A percentage on the wrapper should be resolved against the parent of the wrapper, right? The wrapper is the parent of the block, so the block tries to resolve the layout dimension on the wrapper. I could have answered the question myself though: No change is required. If the layout dimension is not found on a certain FO, it is looked for at the parent. Regards, Simon Pepping -- Simon Pepping home page: http://www.leverkruid.nl
Re: [PATCH] Support for percentages and table-units
Andreas L. Delmelle wrote: -Original Message- From: Peter B. West [mailto:[EMAIL PROTECTED] Thanks Andreas. Yes, I disagree, but then, so does the spec. What information *should* do is not terribly relevant. We need to work out and express what information *must* do to get this thing working. Voila! Without worrying too much about textbook 'should'-stuff... It is after all *XSL*-FO, so I guess the basic compliance rule is also for FO processors: 'the order of the processing events doesn't matter at all, as long as the produced output is correct.' [Me:] ... Would it really be worth a shot to change the design there, and flip a switch? Throw the FOTree away and just fill up the AT and re-use that? Or process the minimal relevant parts of the FO and Area trees in parallel. That is what I am working towards. I believe that page-at-a-time layout with just in time processing of the FOs is possible. Given that, both FOs and Areas can be kept alive while required. (I haven't given any thought to rendering.) Indeed. When I began thinking about 'borderline-cases', it became clearer that situations where you need to wait for more than one page to complete the layout are rather exceptional anyway, so it's most likely the better option to treat them as what they are: 'an exception to the general processing flow' (--IOW, not *all* theoretical possibilities implied by the definitions in the spec should be covered by the *basic* processing framework). The borderline cases may be very much in the minority (and must be, judging by the degree of usage that FOP gets now) but they must be taken into account in the design of the solution. If we go for the low-hanging fruit and then discover that the ladder is too short we end up back in the workshop. Note that forward references are always going to be a problem, but that a combination of weak/soft/phantom references and serialization should keep memory requirements manageable. That's where your producer-consumer buffers step in, right? So.. by 'minimal relevant parts' you actually mean something as 'reduced skeletons of subtrees' that in themselves provide a way to pull the events generated by their descendants from the buffer, without themselves actually holding a reference to the descendants, so while the ancestor is being kept alive, the descendants can be happily collected by our friend GC if no longer used by another process, while the ancestor remains at our disposal to re-pull the same events from the buffer if/when they are needed. Is this close? I wasn't thinking of the buffers. The re-usability of the buffers is only relevant to static-content and markers, so I don't see that as a major issue, and would expect to keep the static-content buffers for a page in memory for the life of the page-sequence. Markers are a bit more problematical, and may well benefit from some transparent serialization. I was thinking more of the historical parts of the FO and Area trees. At one stage I considered linking all nodes in the FO tree with reference objects, but I was concerned about the extra layer of reference objects and their impact on memory and performance. However, when we get parallel FO tree, Area tree and rendering working it may pay dividends. I find the language of the java.lang.ref package confusing, but I think that phantom references open the possibility of performing serialization on demand, when the object is queued for GC. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: [PATCH] Support for percentages and table-units
Finn Bock wrote: [Peter B. West] Finn, When I apply your most recent patch (10366) against a cvs updated HEAD tree and attempt to compile, I get the following: [javac] /usr/local/src/fop-HEAD-finn/src/java/org/apache/fop/fo/properties/LinearCombinationLength.java:60: After applying the patch (10366), the following files should be removed: src/java/org/apache/fop/fo/properties/LinearCombinationLength.java src/java/org/apache/fop/fo/properties/MixedLength.java Does anyone know how to include a file-remove in a patch? From 'man patch' on linux: You can create a file by sending out a diff that compares /dev/null or an empty file dated the Epoch (1970-01-01 00:00:00 UTC) to the file you want to create. This only works if the file you want to create doesn't exist already in the target directory. Conversely, you can remove a file by sending out a context diff that compares the file to be deleted with an empty file dated the Epoch. The file will be removed unless patch is conforming to POSIX and the -E or --remove-empty-files option is not given. An easy way to generate patches that create and remove files is to use GNU diff's -N or --new-file option. From 'man diff' on linux: -N --new-file In directory comparison, if a file is found in only one direc- tory, treat it as present but empty in the other directory. Peter -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
Re: DO NOT REPLY [Bug 26778] - [PATCH] Support for percentages and table-units
Finn, Nice. The parser, of course, looks after all of the expression-ordering questions for you, and you have only to collect the unresolved items. I'll adopt this for alt-design. Peter Finn Bock wrote: [Peter B. West] Can you describe your expression tree in more detail? The line above is most likely the toString() on the expression that is the result of a start-indent calculation from [5.3.2]. Each set of parens represent an algebra operation node in a (mostly) binary tree. The expression above is actually stored like this. v | +-ADD | +--0mpt | +--ADD | +--0mpt | +--ADD | +--ADD | | | +-- 4000mpt | | | +-- %20 of REFERENCE_IPD | +-- 0mpt The tree is created lazily during the evaluation of expression in the property parser. If both the operands to an operation are absolute, the operation is performed at parse time, but if either one of the operands are relative values, an operation-node is created. The operation node is also considered to be a relative value, so the next operation that involves an operation node will always create a new operation node. (Note to self: Perhaps it is worthwhile to detect if one of the operands in a ADD and SUB operation is 0? It would perhaps reduce memory for the majority of start-indent expressions). A node on the operation tree is represented by an instance of fo.expr.RelativeNumericProperty. The code that creates the tree is located in NumericOp and it is called from the PropertyParser. When a property is retrieved by the LMs, it is the final call to Length.getValue() or Numeric.getNumericValue() that triggers the evaluation of the operation tree. At that time the REFERENCE_IPD value should have been assigned by the LMs to one of the parent fo:elements. regards, finn -- Peter B. West http://www.powerup.com.au/~pbwest/resume.html
