Re: [GSoC] BreakingAlgorithm: simplify handling of activeLines
Vincent Hennebert wrote: Hi All, Good news: before-floats are working. There probably are bugs and place for improvement but I think it is time to submit a first patch, so that you may see what I've done. I'm currently cleaning up and documenting my code, and I think the handling of the activeLines array may be simplified: currently, for a line l, activeLines[2*l] points to the first active node for this line, and activeLines[2*l+1] points to the last node. But the last node is never directly accessed, only by starting at the first one and following the links. Perhaps I misunderstand your question, but I think the last active node in a line is used when adding yet another active node for that line at the end of the linked list. In BreakingAlgorithm:addNode(): activeLines[headIdx + 1].next = node; On the other hand, a different data structure of nodes might very well open up different improvement. The current structure of using a linked list for each line, is just the best I could come up with at the time. regards, finn
Re: Error message: "Should be first"
Jeremias Maerki wrote: One of my clients reported to me that he gets a "Should be first" error message on the log. This happens in (Page)BreakingAlgorithm.removeNode(). I get the impression that the code there is not finished rather than that is a real error condition. Correct. In BreakingAlgorithm, at least, I simply didn't bother to implement the out-of-order removing because I thought it wouldn't happen. Adding conditions and flags, such as found in PageBreakingAlgorithm seems unnecessary to me. Just unconditionally remove the node in the single-linked list. regards, finn
Letter space [was Re: Kerning]
[Luca] ... A little doubt concerning letter spaces: at the moment, a letter space is "assigned" to the preceding character. Is this correct? I don't remember any section in the specs stating about the "ownership" of letter spaces ... I think that everything is simpler, from the point of view of both users and implementors, if each letter space is owned by the preceding (or following) formatting object, but this does not mean it is what the specs require! In [7.16.2 "letter-spacing"], I read it as if each alphabetic letter has 1/2 a letter space preceding and 1/2 a letter space following the character. These space-before and space-after trait values are then resolved with whatever other spaces that they are up against according to space resolution rules. The same goes for wordspaces which is split into 2 half word spaces. "A Word" then becomes: hls 'A' hls hws hws hls 'W' hls hls 'o' hls hls 'r' hls hls 'd' hls where 'hls' is half a letter-space and 'hws' is half a word-space. How the "hls hls" and 'hls hws' sequences are resolved depends the .precedence and .conditionality values. OTOH, it is user agent dependant how letter space is resolved with word spaces, so I think your implementation is complient, it is just not what I think the spec suggest. regards, finn
Re: DO NOT REPLY [Bug 37639] New: - [PATCH] Whitespace handling revised
[Andreas] Have a look and let me know if it needs improvement. Your renaming of whiteSpaceTreatment and whiteSpaceCollapse is a break from the automatic naming of all the other property instance vrbl names. I capitalized each '-' seperated word in the property name: "white-space-treatment" and "white-space-collapse". regards, finn
Re: Inquiry: conditional inclusion of dev-related debugging?
[Andreas]
Hi all,
For starters: it's not really a pressing matter ATM, but it may become
of relevance if we want to strive for a production-release. The matter
is somewhat related to the distinction between developer- and
user-directed logging.
It concerns the numerous log.debug() and log.trace() messages scattered
around. Just recently, I was reminded of a little Java trick that
emulates C's conditional compilation, which inspired me to pop this
question here.
As you are most likely well aware, every log.debug() generates bytecode
at compile-time, which leads to compiled classes being unnecessarily
large for general usage. In Java, there exists this little trick to
define a final debug() method:
final void debug(String msg) {
if (DEBUG) {
log.debug(msg);
}
}
The DEBUG boolean constant being defined in a central, easily
accessible place.
If subsequently, all log.debug() calls are replaced by mere debug(),
and one sets DEBUG to false, then the result at compile-time is that:
- there is no bytecode generated for the debug() methods (empty body)
That is true.
- since the method is final, and it has an empty body, the compiler can
optimize further and no bytecode will be generated for any call to it.
Not true for javac from jdk1.4.2. A call to the debug method is included
in the byte code. Perhaps other compilers does it differently.
Meaning also: possible string literals in the message do not take up
space in the internalized string-table, which in turn would be
beneficial for eventual runtime-calls to String.intern() (smaller table
=> decreased lookup-time)
Also not true for 1.4.2.
public class x {
public static final boolean DEBUG = false;
public static void main(String[] args) throws Exception {
new x();
}
public x() {
int i = 55;
debug("hello " + i + " world");
}
final void debug(String msg) {
if (DEBUG) {
System.out.println(msg);
}
}
}
Compiled from "x.java"
public class x extends java.lang.Object{
public static final boolean DEBUG;
public static void main(java.lang.String[]);
throws java/lang/Exception
Code:
0: new #1; //class x
3: dup
4: invokespecial #2; //Method "":()V
7: pop
8: return
public x();
Code:
0: aload_0
1: invokespecial #3; //Method java/lang/Object."":()V
4: bipush 55
6: istore_1
7: aload_0
8: new #4; //class StringBuffer
11: dup
12: invokespecial #5; //Method java/lang/StringBuffer."":()V
15: ldc #6; //String hello
17: invokevirtual #7; //Method
java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
20: iload_1
21: invokevirtual #8; //Method
java/lang/StringBuffer.append:(I)Ljava/lang/StringBuffer;
24: ldc #9; //String world
26: invokevirtual #7; //Method
java/lang/StringBuffer.append:(Ljava/lang/String;)Ljava/lang/StringBuffer;
29: invokevirtual #10; //Method
java/lang/StringBuffer.toString:()Ljava/lang/String;
32: invokevirtual #11; //Method debug:(Ljava/lang/String;)V
35: return
final void debug(java.lang.String);
Code:
0: return
}
All the string litterals and string concatination still exists in the
byte code.
Perhaps the JIT will detect the empty method and avoid the string
concatination, I have not tested that, but I doubt it.
regards,
finn
Fixed block-containers. Was [Bug 37236] - Fix gradients and patterns
[Jeremias] ... the transformation list is still necessary to recreate the same state after a "break out" as needed when painting fixed block-containers. I haven't found a better way to handle this case, yet. Is there a reason for keeping areas from absolute and fixed block-containers in the flow of normal areas? IIUC absolute and fixed block-containers generates areas with an area-class of xsl-fixed and it is hinted that such areas is taken out of the flow and placed under the page-area: """ [7.5.1] Absolutely positioned areas are taken out of the normal flow. ... The area generated is a descendant of the page-area """ If I'm right about this, the break-out code can be avoided by placing the absolute and fixed block-container differently in the area tree. regards, finn
Re: Sponsorship
[Peter B. West] ... That code was alt-design properties code. It seems to me that many of the ideas and implementation details of alt-design are now sitting in the FOP code base. This is true whether Finn ever looked at the alt-design properties code. It ain't over yet.[1] I did, before I became a committer. Back then I evaluated the different branches (0.20, alt and head) and made a decision on which one to work on. The alt-design property code was, back then, in my eyes, code written by a person who did not intuitively create object oriented design. It was, IMO, not a good fundation for further work. I have then later looked at different times, one where I made a incorrect description of how alt-design stored references from fo-object to properties, an other when I wanted to understand why you though alt-designs Property/PropertyValue was any different from head's PropertyMaker/Property. Does any record of any of this remain on the web site? No. Plagerism? Not a single line from alt-design has ever been committed to head by me! regards, finn
Re: The space resolution examples
[Simon]
In general, I have a different idea about the retain
condition. Retained spaces do not appear between areas returned by the
FO; all spaces appear before or after all areas returned by the
FO. This is different from retained padding and borders.
[Jeremias]
That's the part where I think you are wrong. 4.2.3 and 7.10.5 make it
clear IMO that space-before|-after are applied to every area generated
by an FO. The following sentence is the key: "Specifies the value of the
space-specifier for the space before the areas generated by this
formatting object." (Notice the "areas"!)
So for inlines we get
xxx xx xxx xx xxx x xxx iii i
iii iii ii iii iii i ii i ii xxx xxx xxx
xxx xxx
xxx xx xxx xx xxx x
xxx iii i
iii iii ii iii
iii i
ii i ii xxx
xxx xxx
xxx xxx
where a retained space-start is applied to each inline area, not just
the first one generated?
My understanding is more in line with Simon.
I would guess that the key sentence is also true if the space is applied
to only the first area.
regards,
finn
Re: Static methods
[Peter] I noticed that you extracted numeric function methods as statics into a class of their own. Was this for aesthetic or performance reasons? The methods in NumericOp? They are called from multiple places which does not have anything in common. So I put the methods in NumericOp to avoid duplication of the few lines in each method. There was no performance reasons behind that decision. regards, finn
Re: dominant-baseline property
[Manuel] I just discovered something unusual in the spec. It describes the dominant-baseline property in a number of places as: 'The "dominant-baseline" property is a compound value with three components.' It then goes on and lists the 3 components as "dominant-baseline-identifier", "baseline-table" and "baseline-table font-size" collectively referred to as a "scaled-baseline-table". Or to put it differently - the computed value of the "dominant-baseline" property is a value of type "scaled-baseline-table". [Andreas] Not exactly. Read 7.13.5: "The 'dominant-baseline' property is used to determine a scaled-baseline-table. A scaled-baseline-table is a compound value with three components..." So, it's not the property itself which is a compound value, but rather the property's enum value is used to determine the compound value of the scaled-baseline-table. [Manuel] It also says in 7.13: The primary baseline alignment property is the "dominant-baseline" property. This property has a compound value with three components. And in 5.5.7: The value of this property is a compound value with three components: a baseline-identifier for the dominant-baseline, a baseline-table and a baseline-table font-size. So there is some evidence in the spec that the authors meant that the computed value of the property is of type "scaled-baseline-table". I agree, the spec does indeed indicate that the value isn't a simple enum. OTOH I have no idea how it should be handled in the property system. It isn't a normal compound property (no "dominant-baseline.baseline-identifier" sub property). I'm far from being an expert on alignment, but my gut feeling would make the "scaled-baseline-table" datatype a class in layoutmgr, accessed from LayoutContext and updated at each LM level with the alignment properties. If you allow me to turn the question around, what would be the benefit of having a scaled-baseline-table datatype in the property system? I guess that inheritance of values would be the main reason which is easy in the property system and somewhat harder in LayoutContext. The calculation is the remainging values seems easier to do during layout. regards, finn
Re: text-altitude/-depth properties
[Manuel]
This is probably a question for Finn.
I am looking into replacing the use font.getAscender() /
font.getDescender() in the relevant LMs with the use of the appropriate
properties text-altitude and text-depth. I would like to avoid having
to write in all the LMs code like:
int textAltitude;
if (fobj.getTextAltitude().getEnum() == EN_USE_FONT_METRICS) {
textAltitude = fobj.getCommonFont().getAscender();
} else {
textAltitude = fobj.getTextAltitude().getValue(this);
}
What's the best way to move this sort of logic into the property system
so the LMs only need to call:
textAltitude = fobj.getTextAltitude().getValue(this);
and the enum is resolved as part of the getValue call?
My gut feeling is that it should *not* be moved to the property system.
Perhaps it should be placed in CommonFont which already has some of the
intersection of properties and font state info. OTOH CommonFont is well
defined and does not include text-altitude.
How about putting it on CommonFont as a static method:
static int getTextAltitude(Font font, Length textAltitude,
PercentBaseContext pbc) {
if (textAltitude.getEnum() == EN_USE_FONT_METRICS) {
return fs.getAscender();
} else {
return textAltitude.getValue(pbc);
}
Or perhaps it should be placed in a "FontHelper" class in layoutmgr.
regards,
finn
Re: svn commit: r289865 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop: fo/ fo/flow/ fo/properties/ layoutmgr/table/
[adelmelle]
Author: adelmelle
Date: Sat Sep 17 16:59:25 2005
New Revision: 289865
URL: http://svn.apache.org/viewcvs?rev=289865&view=rev
Log:
Implementation for initial values of the column-number property
Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java
URL:
http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java?rev=289865&r1=289864&r2=289865&view=diff
==
--- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java
(original)
+++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/flow/TableCell.java Sat
Sep 17 16:59:25 2005
...
+if( pList.getExplicit(PR_COLUMN_NUMBER) != null ) {
+((TableFObj) parent).setCurrentColumnIndex(
+
pList.getExplicit(PR_COLUMN_NUMBER).getNumeric().getValue());
+}
Why is explit specified values different? In all other cases in FOP, the
fo object only needs the computed values.
Perhaps it is needed here for table objects, but I find it very strange.
regards,
finn
Re: Initial values for column-number (commit still pending...)
[Jeremias and Andreas on starts-row & ends-row] My take is that only a "true" value is used to determine a change in row. It makes no difference to the fo-tree or to layout if a default "false" or an explicit "false" is found. [7.26.15] """ The "starts-row" and "ends-row" properties with a "true" value are typically used when the input data does not have elements containing the cells in each row, but instead, for example, each row starts at elements of a particular type. """ I found no indication that a "false" value can be used to prevent a row change, so there is IMO no real conflict if conflicting values are used on sibling cells. regards, finn
Re: Characters and area traits
[Manuel] I am currently looking at adding the missing background and border/padding support to fo:character and have run into a co-ordinate system issue. In fop text areas and character areas are positioned in the bpd direction using the "offset" attribute which refers to the character baseline position. However, border/padding and backgrounds are positioned everywhere relative to the top left (or should I say before/start) corner of the area rectangle. However, in the renderer based on the area traits (for a text or character area) I cannot easily determine the before edge position of the rectangle based on the baseline offset unless I go to the font and ask for its ascender size etc.. But that is really stuff for the layout system. I see two options: a) We can wrap the character area into an inlineParent area and put the background/border/padding for the character on the inlineParent. b) We add another attribute to the generic fop area being the baseline offset called "lead". The meaning of the attributes is then that "offset" refers to the distance between the before edge of the parent area to the before edge of the area to be rendered and "lead" is the distance from the before edge to the baseline for character placement. Perhaps I misunderstand, but I think it would be better if we defined an dominant-baseline on the inlines (or even better dominant-baseline-identifier on inline and actual-baseline-table on the fonts) and a baseline-start-point on the linearea. The semantics of these traits are as described in [4.2.6] and [4.5]. Together with bpd, I think that would be enough to find the rest of the different rectangles. I guess it is the same as your suggestion b), but I would rather stick with the terms used in the spec. regards, finn
Re: vertical-align vs baseline alignment properties
[Manuel]
As a consequence of the recent discussion on the correct bpd for inline
areas I was looking at actually implementing it. Part of that is
correct vertical positioning, i.e. baseline alignments, of those areas.
Am I correct in saying that the vertical-align property which is a
shorthand for a combination of baseline related properties is not
currently implemented as shorthand, that is the property system doesn't
do the mapping to the corresponding properties (alignment-baseline,
alignment-adjust, baseline-shift and dominant-baseline)?
Correct.
Also those 4 properties, while set on the various fo's, don't seem to
have getters so are not available to the layout system.
So, the first step in moving away from vertical-align and to the four
corresponding properties is to fix the property subsystem and the fo
definitions.
Correct.
Finn, the property system already has a notion of corresponding
properties, etc.. I haven't looked into it in any detail but can that
be used for the mapping of vertical-align or do we need some custom
mechanism in this case?
There is also explicit support shorthands. For the 4 properties the
vertical-align must be specified as a shorthand:
m.addShorthand(s_generics[PR_VERTICAL_ALIGN]);
and a new custom ShorthandParser must be written and added to the
vertical-align maker
m.setDatatypeParser(new VerticalAlignShorthandParser());
which consist of code to implement the rule in [7.29.22]:
if (property.getEnum() == EN_BASELINE)
switch (propId) {
case PR_ALIGNMENT_BASELINE:
return new EnumProperty(EN_BASELINE)
case PR_ALIGNMAENT_ADJUST:
return new EnumProperty(EN_AUTO)
case PR_BASELINE_SHIFT:
return new EnumProperty(EN_BASELINE)
case PR_DOMINENT_BASELINE:
return new EnumProperty(EN_AUTO)
}
} else property.getEnum() == EN_TOP) {
switch (propId) {
case PR_ALIGNMENT_BASELINE:
return new EnumProperty(EN_BEFORE_EDGE)
case PR_ALIGNMAENT_ADJUST:
return new EnumProperty(EN_AUTO)
case PR_BASELINE_SHIFT:
return new EnumProperty(EN_BASELINE)
case PR_DOMINENT_BASELINE:
return new EnumProperty(EN_AUTO)
}
As an aside, the FOP implementation deviates from the spec since
shorthands should set values for other properties, but our system pulls
the values out of the shorthand property with the help of a ShorthandParser.
regards,
finn
Re: fo:inline bpd
some 10pt text some 12pt text more 10pt text All the inline areas also have a line-height trait of 12000 but that is only used when lls="line-height" [4.6]. [Manuel] Hmm, the line-height property would be "normal" everywhere which equates to "1.2" that means the trait would be "14400" for areas generated from fo elements with a font-size of "12pt" and "12000" for areas generated from fo elements with a font-size of "10pt". But as you said it doesn't matter really unless lss is "line-height". Your are right, my mistake. I believe the line-height trait should be 14400 for all the inline areas. Does it make sense? Yes it does. Does it also means the bpd doesn't "bubble up" in the case of nested inlines? So if we expand on the example of the nested inline above: some 10pt textsome 14 pt textmore 10pt text Does the line-area generated from that have a bpd corresponding to a 12pt font or 14 pt font (spec [4.5] for lss="max-height": "block-progression-direction is the minimum required to enclose both the nominal-requested-line-rectangle and the allocation-rectangles of all the inline-areas stacked within the line-area")? I believe the bpd of the line area will correspond to the 14pt font because [4.5] talks about "all the inline-areas". So the bpd on inlines does not bubble up the outer inlines, but it (and/or depth & altitude) do bubble up to the calculation of line-rectangles on the line-area. Also, I think that makes sense. The nominal-requested-line-rectangle corresponds to a 12pt font. But is the area generated from the nested inline an "inline-area stacked within the line-area" or not? Stacked inline-areas must refer to all the desendents, not just the immediate children, see [4.6.1]. regards, finn
Re: FOTree test question
[Andreas] Very roughly, the new ColumnNumberProperty.make() does something like this: That should be ColumnNumberPropertyMaker in order to follow the naming of all the other custom makers. regards, finn
Re: fo:inline bpd
[Manuel] Any way, back to the topic at hand. Lets assume the following fo: some 10pt textfont-size="12pt">some 12 pt textmore 10pt text In this case the line-height everywhere is normal which is equivalent to 1.2em. The innermost fo:inline will return an area with a bpd of 12pt. However, the outer fo:inline has a smaller font and as the line-height spec on an inline element is binding it can only return areas of 10pt bpd therefore "cutting off" part of the inner fo:inline. So our area tree (assuming it all fits on one line) in fop terminology would look like: some 10pt text some 12pt text more 10pt text Right, except the 1 and 12000 values should be text-altitude + text-depth: some 10pt text some 12pt text more 10pt text All the inline areas also have a line-height trait of 12000 but that is only used when lls="line-height" [4.6]. In my interpretation as there is no explicit line-height spec on the inlines we get an area tree like: some 10pt text some 12pt text more 10pt text I have no idea whose right or wrong here or even which interpretation makes more sense. From [4.6]: """An inline-area with inline-area children has a content-rectangle which extends from its dominant baseline (see [4.2.6 Font Baseline Tables]) by its text-depth in the block-progression-direction, and in the opposite direction by its text-altitude;""" So it appears that the bpd of an inline depends on the inline's font and not on the line-height property or the inline's children. Does it make sense? I have no idea what the spec means by [7.15.4]: """If the property is set on an inline-level element, it specifies the exact height of each box generated by the element.""" because both "set" and "box" is undefined by the rest of the spec. The text is copied from CSS where it perhaps makes sense. regards, finn
Re: fo:inline bpd
Manuel Mall wrote: On Tue, 13 Sep 2005 04:12 pm, Finn Bock wrote: [Manuel] Inline areas have their own line-height trait which can be different to the line-height on the containing line area / containing block. line-height when specified on an inline fo has a different meaning, i.e. the inline area returned MUST have the exact line-height as specified, while line-height on a block level sets the minimum height for all decendant inline areas. We don't do any of that in the moment. Side note: in layout we don't know any more if a property is inherited or specified on that element, that could be a complication here. Finn, any thoughts on this? You mean the phrases: "If the property is set on an inline-level element, it specifies ..." is only used when the line-height property is explicitly set on inline-level? If the line-height is inherited then that paragraph isn't operative? [Manuel] Yes that's how I read it because otherwise the sentence "If the property is set on an inline-level element, it specifies ..." doesn't make sense to me. As the property is always implicitly set so this must mean explicit. Do you (or anyone else) understand that differently? Hmm, not speaking english natively puts me in a disadvantage, but perhaps the sentence means the same as "If the property is *used* on an inline-level element, it specifies ..." ? The focus is merely on the element type, not on where the property value comes from. regards, finn
Re: fo:inline bpd
[Manuel] Inline areas have their own line-height trait which can be different to the line-height on the containing line area / containing block. line-height when specified on an inline fo has a different meaning, i.e. the inline area returned MUST have the exact line-height as specified, while line-height on a block level sets the minimum height for all decendant inline areas. We don't do any of that in the moment. Side note: in layout we don't know any more if a property is inherited or specified on that element, that could be a complication here. Finn, any thoughts on this? You mean the phrases: "If the property is set on an inline-level element, it specifies ..." is only used when the line-height property is explicitly set on inline-level? If the line-height is inherited then that paragraph isn't operative? If that is the case, then line-height is the only(?) property that isn't using the specified value. Strange. But is it not a big deal, the inline-level .bind() method will have to check if the line-height is explicit set: lineHeightExplicit = pList.getExplicit(PR_LINE_HEIGHT); which is then non-null is the property is set on the element. However it is a huge deviation from the rest of the properties. regards, finn
Re: fo:inline bpd
Manuel Mall wrote: yes, that is an option. What I am unsure about here is that the children, typically text areas, do not take the line spacing into account when reporting their bpd, that is the usually 10% space above and below the character. So what is the correct bpd for an fo:inline which has text area children: is it just the max bpd of its children or is it max bpd plus any line spacing settings from its parent? [Luca] Oh, yes, the "half-leading" trait ... If I understand correctly the specs (4.5 Line areas) this line spacing must be added to the bpd of each inline area too. As it is the same for all inline areas, it could be stored into the LayoutContext by the LineLM. I don't read it that way, instead the half-leading are set as space-[before|after] only on the line area, and are in some cases resolved with other surrounding spaces. regards, finn
Re: Space-resolution doesn't work
[Luca on space resolution]
So, my idea for handling space resolution is tho have a LM ask its
children about their spaces, and create the necessary elements (while at
the moment each LM creates elements for its own spaces).
For example, if we have this LM tree
Outer BlockLM
|
+++
|||
BlockLM 1BlockLM 2BlockLM 3
|
+--+-+
||
BlockLM ABlockLM B
BlockLM1.getNextKnuthElements() would return to the outer BlockLM only
the elements representing its block content, without any space.
In order to decide which elements it has to create, the outer BlockLM
could have some lines like:
(currentChild = BlockLM 1
nextChild = BlockLM 2)
space1 = currentChild.getSpaceAfter();
space2 = nextChild.getSpaceBefore();
if (this.mustKeepTogether()
|| currentChild.mustKeepWithNext() && !nextChild.hasBreakBefore()
|| !currentChild.hasBreakAfter() && nextChild.mustKeepWithPrevious) {
// there cannot be a break between the two children,
createElementsForSpace(resolve(space1, space2, false, false));
Surely there is a possible break here. It just have a very high penalty,
but even keep-*="always" is allowed to break.
regards,
finn
Re: Area Tree XML format as reloadable intermediate format
[Jeremias] It's time bring this on the table. I've started writing down a proposal for an intermediate format for FOP. All the details are on the wiki page: http://wiki.apache.org/xmlgraphics-fop/AreaTreeIntermediateXml Thoughts welcome. Looks fine, but a few things is unclear to me. - What is "SAX-based serialization"? - The "wrapper around a PageViewport" is a functional extra that the pure area tree doesn't need by itself, right? - What and where do you mean "no direct painting routines"? regards, finn
Re: Combined compound and shorthand property specs
[Manuel] I must still be misunderstanding something. The above property definition does not give the results I expected. All 4 of border/padding start/end still have conditionality="discard". The absolute border-*-width & padding-* are length, not length-conditional. So the default values for .conditionality is returned. OTOH, setting a component like .conditionality on a length should definitely cause an error or warning. regards, finn
Re: Combined compound and shorthand property specs
[Manuel] Is the following legal:? border-start-width.conditionality="retain" border-end-width.conditionality="retain" padding="1pt" padding-start.conditionality="retain" padding-end.conditionality="retain"> What seems to happen is that for borders it works fine, that is I get 4 solid red 1pt borders with the start and end borders having a conditionality of "retain". Oh, it works exactly the same for borders, you are just seeing the default "medium" (=1pt) value for "border-start-with.length" and the default "0pt" for "padding-start.length". However for padding I get padding before and after with length 1pt but start and end padding have a length of 0pt(!) although their conditionality is correctly set to "retain". If the above is legal than something is wrong in the property subsystem with respect to shorthand length and component specs. If the above is illegal than I am just lucky that it works for borders. The effect seen occurs because we consider "padding-start" to be explicitly set by setting "padding-start.conditionality" and then the shorthand is ignored. From [5.3.1] """ If the corresponding relative property is specified on the formatting object and the absolute property only specified by the expansion of a shorthand, then the computed value of the absolute property is set to the computed value of the corresponding relative property. """ I don't know if that is the correct interpretation. regards, finn
Re: [VOTE] Manuel Mall as new FOP committer
[Jeremias] Manuel Mall has been investing a tremendous amount of time and effort into making FOP better lately. The results were just great. It's been a pleasure to apply his patches, even though it ate up a lot of my time. ;-) Manuel has been around since at least late 2002, even submitted a patch back then. He shows a good understanding of how things work in our project and is quick to learn in other areas. He doesn't fear diving into the code of the layout engine. That's exactly the sort of people we need in the project team. That's why I'd like to nominate him for committership in Apache FOP. +1 regards, finn
Re: [Xmlgraphics-fop Wiki] Update of "ExtensionPoints" by JeremiasMaerki
[Luca] Speaking of extensions, I'd like to resurrect the layout extensions That isn't exactly use of the term "extension" which I'm using and which I think Jeremias is using in the ExtensionPoints wiki. Your extensions are additional useful features, when I talk about extensions it is the ability to dynamicly load additional behaviour without modifying FOP sources. If your features could be implemeted as dynamicly loaded code, the result would be a lean FOP with incredible power ... that were part of the code used to start the Knuth branch, but I want to be sure I'm allowed to do it. .. and you wouldn't have to ask. :-) OTOH, I'm not entirely sure how to design and implement such a system that dynamicly loads code into the layout system. The set of extensions (a couple of new properties, and some new value for an existing one) New properties are fine, new values to existing properties are bad, I think. It basicly makes the fo file into a FOP file, since no other processer can handle the 'illegal' values. It would be better to define fox:display-align="fill" which when specified will override the value of display-align. is aimed to give the user more control about the page breaking: in particular, via these extensions it is possible to give the application a list of properties that can be adjusted in order to fill all the available bpd of a region (in addition / substitution to the spaces between blocks [1]). I wonder why you don't mention that line-height is a min/opt/max space. Surely that will (when implemented) be usefull way to limit the size og empty areas. regards, finn
Re: Exceptions
[Jeremias] No surprise, actually. The tables all use the collapsing border model. But tell me, have they updated the NIST test suite for XSL Rec 1.0? I remember that at a stand-still in working-draft stage (master-name instead of master-reference). Years back, when we last talked about the NIST suite, the author of the suite gave a link to a new version of the suite. Last I checked, it was the old version that was available on their webpage. regards, finn
Exceptions
Hi Running the NIST test suite I get 2 table related exceptions and 1 KnuthElement related exception: java.lang.NullPointerException org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:246) org.apache.fop.layoutmgr.table.GridUnit.resolveBorder(GridUnit.java:230) org.apache.fop.layoutmgr.table.TableRowIterator.resolveStartEndBorders(TableRowIterator.java:480) org.apache.fop.layoutmgr.table.TableRowIterator.buildGridRow(TableRowIterator.java:419) org.apache.fop.layoutmgr.table.TableRowIterator.prefetchNext(TableRowIterator.java:294) http://www.w3.org/1999/XSL/Format";> margin-right="1.0in" margin-bottom="1.0in" margin-top="0.2in" margin-left="1.0in" page-width="8.5in" page-height="11in"> margin-top="0.2in" margin-left="1.0in"/> This test evaluates the "border-before-color" property on a table-body FO. The "border-before-color" property (see red border) for the next table-body FO was set to red. The border above should be red. java.lang.NullPointerException org.apache.fop.layoutmgr.table.TableContentLayoutManager$RowPainter.addAreasForCell(TableContentLayoutManager.java:885) org.apache.fop.layoutmgr.table.TableContentLayoutManager$RowPainter.addAreasAndFlushRow(TableContentLayoutManager.java:864) org.apache.fop.layoutmgr.table.TableContentLayoutManager.addAreas(TableContentLayoutManager.java:642) org.apache.fop.layoutmgr.table.TableLayoutManager.addAreas(TableLayoutManager.java:296) http://www.w3.org/1999/XSL/Format";> margin-right="1.0in" margin-bottom="1.0in" margin-top="0.2in" margin-left="1.0in" page-width="8.5in" page-height="11in"> margin-top="0.2in" margin-left="1.0in"/> This cell spans one row This cells spans two rows java.lang.ClassCastException org.apache.fop.layoutmgr.inline.ContentLayoutManager.getNextKnuthElements(ContentLayoutManager.java:282) org.apache.fop.layoutmgr.inline.LeaderLayoutManager.getLeaderInlineArea(LeaderLayoutManager.java:150) org.apache.fop.layoutmgr.inline.LeaderLayoutManager.get(LeaderLayoutManager.java:77) org.apache.fop.layoutmgr.inline.LeaderLayoutManager.getNextKnuthElements(LeaderLayoutManager.java:255) http://www.w3.org/1999/XSL/Format";> margin-right="1.0in" margin-bottom="1.0in" margin-top="0.2in" margin-left="1.0in" page-width="8.5in" page-height="11in"> margin-top="0.2in" margin-left="1.0in"/> The "leader-pattern" property of the "leader" FO below was set to "use-content"(set to "*"). Entry 1leader-pattern="use-content" leader-length.optimum="1.0in" leader-length.maximum="1.0in">*Page 1
Re: svn commit: r264856 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/render/rtf: TextAttributesConverter.java rtflib/rtfdoc/RtfText.java
[EMAIL PROTECTED] wrote:
+
+ private static void attrBaseLineShift(EnumLength baselineShift, RtfAttributes rtfAttr) {
+
+ String s = baselineShift.getString();
Use baselineShift.getEnum() to get the enum values that is assigned to a
length. Never ever use the getString() method, it is purely there for
debugging and for use by the testing frameworks.
I have also fixed this in SVN.
regards,
finn
Re: svn commit: r264863 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java
[EMAIL PROTECTED] wrote: Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java URL: http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java?rev=264863&r1=264862&r2=264863&view=diff == --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java (original) +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOText.java Tue Aug 30 14:09:41 2005 @@ -24,11 +24,13 @@ // FOP import org.apache.fop.apps.FOPException; import org.apache.fop.datatypes.ColorType; +import org.apache.fop.datatypes.Length; import org.apache.fop.fo.flow.Block; import org.apache.fop.fo.pagination.Root; import org.apache.fop.fo.properties.CommonFont; import org.apache.fop.fo.properties.CommonHyphenation; import org.apache.fop.fo.properties.CommonTextDecoration; +import org.apache.fop.fo.properties.EnumLength; import org.apache.fop.fo.properties.Property; import org.apache.fop.fo.properties.SpaceProperty; @@ -83,6 +85,7 @@ private int textTransform; private Property wordSpacing; private int wrapOption; +private EnumLength baselineShift; That is wrong, EnumLength is an implementation detail which must never be used in the fo tree code. Always use Length for properties that is defined as . // End of property values /** @@ -161,6 +164,7 @@ wordSpacing = pList.get(Constants.PR_WORD_SPACING); wrapOption = pList.get(Constants.PR_WRAP_OPTION).getEnum(); textDecoration = pList.getTextDecorationProps(); +baselineShift = (EnumLength) pList.get(Constants.PR_BASELINE_SHIFT); Don't use cast, but call the coerce methods pList.get(XXX).getLength(); I have already committed the fix for this. regards, finn
Re: FOP extension to output custom PostScript instructions
[Jeremias on extensions] Anybody opposed to my adding this? ... Not at all, but I assume that you ask because it can't be added as an extension that is completely seperated from FOP. That you have to make changes to FOP sources in order to add it. Yes, that's true. And that is IMO a bit of a failure of FOP and the renderer design. [Jeremias] Why do you think this is a design failure? I would like if anybody, not just FOP comitters, could add such usefull features to FOP. And it is mostly the renderers that can't be extended by dynamicly loaded extensions. regards, finn
Re: FOP extension to output custom PostScript instructions
[Jeremias on extensions] Anybody opposed to my adding this? ... Not at all, but I assume that you ask because it can't be added as an extension that is completely seperated from FOP. That you have to make changes to FOP sources in order to add it. And that is IMO a bit of a failure of FOP and the renderer design. regards, finn
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
[Manuel] Agree, and I have a solution for that ready to go. I think this deserves some further comment / discussion. One, IMO important, reason I want to do the evaluation during the FO parsing stage is that once we are in the LMs we lost the property inheritance information. That is something like: Text looks to the LM like: Text True, but the percentbase of the second 120% should be the same as the base of the first. They are both 120% of a value on . So when evaluated, the result values will be the same. All inheritance must be resolve by the property system. Otherwise it is a bug. The reason for keeping the values as percentage is to support font-size="120% + 1pt" and to *really* open the discussion it should be noted that the spec does *not* require additive operation on relative lengths. Only multiplications are required. Once the expression engine in fop tried to use that by calculating a factor to be applied to relative lengths. Does svn view have an attic? http://svn.apache.org/viewcvs.cgi/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/ If it does I could propably find the code, it wasn't pretty. regards, finn
Re: Non-implemented props: border-*-precedence
[Jeremias Maerki] Perfect, Finn! I've just hacked together a little test extension that lets me evaluate properties and write failure messages to a singleton which a JUnit test case could process. It's very rough right now, but with a little more work this could really be cool for checking the FO tree. Looks very good. How about adding a property expected-outcome="success|fail" (with a default of "success") to , and tags and when the value is "fail", will either: print "Expected failure still fails as expected" throw "Expected failure was miraculously solved!!!" That way test for unimplemented features can be added without having to disable the entire test file. regards, finn
Re: Non-implemented props: border-*-precedence
Since I have added a new file to SVN must I do something to make line
ending right?
[Jeremias Maerki]
I've just added svn:keywords ("Id") and svn:eol-style ("native") to the
file.
Thank you, I'll try to do that next time.
In the meantime I've made good experiences by doing a few settings in
my SVN config file. In Windows under %USERPROFILE%\Application
Data\Subversion\config.
I've enabled "enable-auto-props = yes".
Furthermore, I've added the following entries under [auto-props]:
*.sh = svn:eol-style=native;svn:executable
*.txt = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.java = svn:eol-style=native;svn:keywords=Id
*.xml = svn:keywords=Id
That takes care of 95% of all cases.
Thanks for that advice.
>>Is there a way in our test system to check the values of properties in
>>the fo tree?
Not yet, I'm afraid. It would really be good to JUnit-test the FO tree
and property subsystem. The layout engine test facility only tests the
layout engine and the visual testing facility only the generated output.
We still have a few gaps WRT testability. Ideas welcome.
Extension elements has access to the propertyList so it can do checks like:
but I'm not sure how it can be made part of a junit suite.
regards,
finn
Re: DO NOT REPLY [Bug 36379] New: - [PATCH] Revised percentage resolution system
[Jeremias Maerki on ] Yeah: Wow! Finn, you're the specialist here. Can you take the lead on this one? I'm hardly a specialist on the layout system, and that is where a good sized part of Manuels patch is, but in the property system I do not like the hack to LineHeightPropertyMaker and FontSizePropertyMaker that test for a PercentLength since it will not work for expressions. I assume that a FixedLength is returned because somebody (BlockLM.createLineManager?) tries to resolve line-height before a context is available. The solution is to delay resolution of line-height, by passing the Length into the LineLM. Eventually the no-args getValue() and getNumericValue() should be removed. And a throws PropertyException added to the Length.getValue() signature. But that is for later. In the layout system, I find to strange to see calls to the initialize() method from addAreas() and getParentArea(). I would rather see a public initialize() method that was called once from the outside, perhaps from AbstractLayoutManager.getChildLM() before a LM is traversed by getNextKnuthElements. But not all agree: http://marc.theaimsgroup.com/?l=fop-dev&m=111811772615007&w=2 Other than that, the patch looks ok. There is one thing I would have made differently: Instead of setting an PercentBase.XXX integer on the PropertyMakers I would set an instance of an implementation of PercentBase that implemented the rule by that property. So there would be a subclass of PercentBase for each of the rules you have identified in the PropertyHandling/Percentages wiki. That way the code for dealing with percentage rules can be placed in the property package instead of the LM package. The LM package only supplied the context that the rules can work on. But since I haven't written that code, I don't get to decide. regards, finn
Re: percentages on i-p-d/b-p-d/height
[Manuel Mall] The spec says: The percentage is calculated with respect to the corresponding dimension of the closest area ancestor that was generated by a block-level formatting object. If that dimension is not specified explicitly (i.e., it depends on content's block/inline-progression-dimension), the value is interpreted as "auto". The second sentence of the above statement is currently not implemented resulting in "messed up" output. What is the best way to fix this? Can we do it on the fo tree when the property is constructed, i.e. walk up the tree and see if a corresponding dimension is set explicitly and if not not force the property to "auto"? There are complications like width and height are corresponding properties to i-p-d/b-p-d and writing mode and reference orientation are also relevant. May be this is too much for the fo tree / property construction phase? It sounds just like a job for the property system since it already deals with the corresponding properties and knows if a property is explicitly set. I don't think that there is an existing way to check if a fo is block-level but that can be added (like generatesReferenceAreas()) or just done by hand: if (fo.getNameId() == Constants.FO_BLOCK || ... Alternatively, it must be done in the layout managers / percentage resolution code. But this appears to be non-trivial as well. Currently the getValue() call just returns an int. If we want to use an int value to signal back "cannot resolve" we need to reserve a value for that purpose, may be MIN_INT? But this then has to flow through the expression validation logic. Reminds me a bit of handling of NULL values in SQL - nasty. Ugh. Or getValue() could throw an exception - but there are many 100's of calls to getValue() which all would need to be checked then. Or we could set a flag on the property (e.g. isResolved()) to be tested after calls to getValue(). Or we put more logic into the LMs for this. They would have to test the property if it is of type Relative...Property. If so they have to go up the LM chain and check if the ancestor block has an explicit b-p-d, The knowledge of explicit set properties isn't stored after the fo tree is constructed. This is for memory reasons. if yes do normal property resolution, if no behave as if the property was set to "auto". Any one with better ideas / comments? regards, finn
Re: Non-implemented props: border-*-precedence
[Andreas L Delmelle] Any hint appreciated. I have added support for the default values in a TableBorderPrecedence property maker class. Since I have added a new file to SVN must I do something to make line ending right? Is there a way in our test system to check the values of properties in the fo tree? regards, finn
Re: Inheritance and percentages in line-height property
[Manuel Mall] I think this is one for Finn :-) at least I am not sure how to fix it. The line-height property has a special inheritance rule. If it is a number (and the enum "normal" is considered a number) inherit the specified value otherwise inherit the calculated value. In the current system if the specified value is a percentage it still inherits the percentage that is the specified value not the calculated value. I have committed a fix. The specified value is only stored for numbers. Now we just need to decide what a number is . regards, finn
Re: background-position-vertical and -horizontal
Manuel Mall wrote: The safety check in addBackground is already there. This is how I stumbled across it as it is triggered by one of the layout engine tests. Also note that the percentage handling in addBackground is a rough hack that doesn't work when expressions are used: "40% + 1pt". regards, finn
Re: Percentages in XSL-FO
[Jeremias Maerki] Looks like you made a thorough analysis. What I read made sense to me although I didn't check everything to the last character. Providing the Context interface through the LayoutContext didn't occur to me and I don't know if it's the right way, but if it just clicks in there without much hassle then it's probably a good idea. I'd have implemented the Context as an inner class to the LMs but then I haven't investigated this so thoroughly as you just did. I simply stumbled over it back in January and what I wrote there was simply what was occuring to me at the time (having been a newbie to the layout engine, too, back then). So. I believe you're on the right course. Your approach seems to be fine-grained enough to handle every case and still limit the additional code to where it is needed. [Manuel Mall] I have been working on this for the last couple of days and I am not so sure any more about the 'being on the right course' bit. So this is a bit of a cry for feedback. I will try to outline the issues. Most percentages are being resolved in the same way: Find the appropriate ancestor area and get the relevant dimension from it. That sounds very simple. The current system solves this by a) using the fo tree to navigate upwards until an appropriate fo is found which generates the type of area we are looking for and b) by the layout managers to attach dimension information to the fos. The reason we are looking for a redesign is that this doesn't appear to be the right way to attach layout information to the fos. The current system is also not complete in its implementation but that is a different issue. The alternative proposed is to use a context which is created by the layout managers and passed to the property resolution system, i.e. the getValue() call. Sounds good so far as the layout managers have access to the dimension information, actually in my code in the moment the layout managers are the context, that is they implement the interface I have defined for the context. But we still need to move up some form of tree or list to find ancestors. The obvious choice would be the area tree but that doesn't work as in many cases when we need a resolved property value the areas (as objects in fop) haven't been created yet. Also the areas are not linked back upwards in the tree although a parent pointer could be introduced for that purpose. So, if we can't use the area tree and don't want to use the fo tree what then? The next thing coming to mind is the layout managers as they form a tree structure as well. They even have a parent pointer. So, to find the dimensions we are looking for we navigate up the parent links of the layout managers until we find one which generates what we are looking for and get the dimensions from it. That is a very good summary of the issue. Thank you. But, the parent link is not set consistently and sometimes late. There is for example the case where a layout manager in its constructor accesses a property value. To be able to resolve it would need to know its parent layout manager which isn't set yet. The fix for that is to carry the parent layout manager into all layout manager constructors. Or delay all calls to Length.getValue(..) until after the layout manager tree is completed and the dimensions are available. So the initialization is allowed to store Lengths but only during getNextKnuthElement() is it allowed to extract the int values from the Lengths. This is where my problem is. We have a system now which is simple (attach dimension information to the fo tree) and we are replacing it with something that changes many internal interfaces, virtually hundreds of method calls by adding extra parameters, and still does the same thing. Which is exactly why I didn't complete the work at the time. Navigate up a tree structure (and I am not 100% sure that navigating up the layout manager tree really is the right thing to do) to find a suitable node and get the appropriate values from that node. The information obviously belong in either the LM tree or in the Area tree. So it is the right thing IMO to move it out of the fo tree. regards, finn
Re: Non-implemented props: border-*-precedence
Andreas L Delmelle wrote: Hi all, Back from holiday, and just started work on the collapsing border model (something I discussed thoroughly with Jeremias a while ago --don't worry, I'm not going to start all over :-) ) Let me just say that, where earlier on I didn't have a clear idea on what needed to be done code-wise, right now I'm pretty confident that I will be able to offer a patch-proposal very soon... Note that, although it will mean that part of the border-collapsing logic will move to the FOTree, I'm still convinced this will make the related code in layout much easier to follow --but to get the FULL picture, potential devs will need to look at both the FOTree AND the LayoutManagers. On to the topic then: while I'm at it, I would also like to try and implement the border-precedence properties (and ultimately also collapse-with-precedence), and have the following questions/remarks about this: * What would be the correct property type to use? So far my working hypothesis is 'EnumNumber', since the value can be an enum (=force), as well as any integer value. Correct assumption? The type should be a number with added 'force' enum. The number property will then coerce a 'force' value into an EnumNumber which is a number that also holds a enum value, but only the property subsystem needs to know that. + Another question concerning the possible value of 'inherit': does it suffice to have Maker.setInherited() set the flag to true (in FOProperyMapping)? * Another issue may be that those properties' default values depend on the type of object they are bound to. The most straightforward way of dealing with this seems to be to defer determining the actual default value until the respective FObj's bind() methods... Does this sound OK, or does anyone see a better way? It was my goal that all the properties should return the correct value from the PropertyList. So if it is possible at all, I would prefer to see that the inheritance issues is implemented in the PropertyMaker classes, instead of the FObjs (or the LayoutManagers). regards, finn
Re: DO NOT REPLY [Bug 36036] - [PATCH] Support for font-size= and font-size=
--- Additional Comments From [EMAIL PROTECTED] 2005-08-05 12:13 --- Thanks for doing this. Your patch looks good and appears to work. However, theres one little thing thats puzzling me. Finn, who is our properties guru wrote the class CommonFont. If you look at the method getFontState there is some code that implements the relative keywords for font weight and comments that say should do font size relative keywords too. Why would he write this if all he needed to do was added some keywords to the Property Maker ??? The getFontState() method was copied from somewhere else. I do not remember from where. I believe that the properties should return the documented values without a need for postprocessing (as seen in getFontState()), but I never got around to do it for the font stuff. I guess that the maker for font-size would look a bit like the maker for line-height. regards, finn
Re: svn commit: r201864 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: ./ flow/ pagination/ pagination/bookmarks/
Jeremias Maerki wrote:
I don't think the discussion was finished when you did this, Glen.
[Glen Mazza]
Oh no, it wasn't--but we know the status quo *wasn't* acceptable, and
that the performance argument was no longer valid because of the
research you did on .equals().
Not so fast. Measurements are always better than guesses. And there *is*
a difference in performance.
We should not intern strings, unless we have very special reasons,
better reasons than performance. Unless SAX promises that the URI
strings are interned, then we can't depend on receiving interned strings.
But since == *is* faster then .equals and I think we can assume that
most URIs are in fact from the FO namespace we can get the benefit from
both.
Measured with jdk1.4.2_02 on winXP:
Equal string
== 141
.equals 1938
== || .equals 203
Different string
== 140
.equals 1844
== || .equals 1891
regards,
finn
public class c1 {
public static void main(String[] args) {
String s1 = "http://xml.org/sax/features/string-interning";;
String s2 = "http://xml.org/sax/features/string-interning";;
String s3 = "http://xml.org/sax/features/namespace";;
long before;
long after;
System.out.println("Equal string");
cmp(s1, s2);
cmp(s1, s2);
before = System.currentTimeMillis();
cmp(s1, s2);
after = System.currentTimeMillis();
System.out.println("== " + (after - before));
equals(s1, s2);
equals(s1, s2);
before = System.currentTimeMillis();
equals(s1, s2);
after = System.currentTimeMillis();
System.out.println(".equals " + (after - before));
cmpequals(s1, s2);
cmpequals(s1, s2);
before = System.currentTimeMillis();
cmpequals(s1, s2);
after = System.currentTimeMillis();
System.out.println("== || .equals " + (after - before));
System.out.println("Different string");
cmp(s1, s3);
cmp(s1, s3);
before = System.currentTimeMillis();
cmp(s1, s3);
after = System.currentTimeMillis();
System.out.println("== " + (after - before));
equals(s1, s3);
equals(s1, s3);
before = System.currentTimeMillis();
equals(s1, s3);
after = System.currentTimeMillis();
System.out.println(".equals " + (after - before));
cmpequals(s1, s3);
cmpequals(s1, s3);
before = System.currentTimeMillis();
cmpequals(s1, s3);
after = System.currentTimeMillis();
System.out.println("== || .equals " + (after - before));
}
public static void cmp(String s1, String s2) {
for (int i = 0; i < 1; i++) {
if (s1 == s2) {
continue;
}
}
}
public static void equals(String s1, String s2) {
for (int i = 0; i < 1; i++) {
if (s1.equals(s2)) {
continue;
}
}
}
public static void cmpequals(String s1, String s2) {
for (int i = 0; i < 1; i++) {
if (s1 == s2 || s1.equals(s2)) {
continue;
}
}
}
}
Re: cvs commit: xml-fop/src/java/org/apache/fop/area/inline InlineParent.java
[EMAIL PROTECTED] wrote: gmazza 2005/03/16 15:18:43 Modified:src/java/org/apache/fop/layoutmgr LineLayoutManager.java StaticContentLayoutManager.java AbstractLayoutManager.java PageSequenceLayoutManager.java BlockLayoutManager.java LeafNodeLayoutManager.java LayoutManager.java BlockContainerLayoutManager.java InlineStackingLayoutManager.java BlockStackingLayoutManager.java FlowLayoutManager.java ContentLayoutManager.java TextLayoutManager.java LeaderLayoutManager.java src/java/org/apache/fop/layoutmgr/table Cell.java Caption.java Body.java TableLayoutManager.java Row.java TableAndCaptionLayoutManager.java src/java/org/apache/fop/area LineArea.java Area.java src/java/org/apache/fop/layoutmgr/list ListItemLayoutManager.java Item.java ListBlockLayoutManager.java src/java/org/apache/fop/area/inline InlineParent.java Log: Changed from addChild(Area) to clearer addChildArea(Area). Yes, that looks like a good example of the kind of change which Jeremias kindly asked you not to do right at this moment. sigh. regards, finn
