You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by Simon Pepping <sp...@leverkruid.eu> on 2008/05/07 22:00:52 UTC

Re: svn commit: r649657 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOPropertyMapping.java flow/table/TableFObj.java properties/NumberProperty.java

On Sat, May 03, 2008 at 01:29:57PM +0200, Andreas Delmelle wrote:
> On Apr 18, 2008, at 21:08, spepping@apache.org wrote:
>> Author: spepping
>> Date: Fri Apr 18 12:07:57 2008
>> New Revision: 649657
>>
>> URL: http://svn.apache.org/viewvc?rev=649657&view=rev
>> Log:
>> An implementation of a positive integer property maker. It implements
>> convertProperty, which is the correct method to implement if one wants
>> to add to the make process. This fixes bug 44619.
>
> Sorry to respond to this so late, but I just noticed that this change  
> seems to have broken a feature we had in place for column-number.
>
> The new PositiveIntegerMaker always returns a property with value of 1 if 
> the specified value is negative or zero. Now, for column-number, it used 
> to be so that those values were replaced by the next free column-number. 
> After the change, we get overlap errors in the fotree testsuite because 
> of this.

That is right, PositiveIntegerMaker does not look for the next free
column-number. I would have minded that better if there would have
been junit test errors. But there are none:

junit-fotree:
     [echo] Running fo tree tests
    [junit] Testsuite: org.apache.fop.fotreetest.FOTreeTestSuite
    [junit] Tests run: 57, Failures: 0, Errors: 0, Time elapsed: 2.232 sec
    [junit] 

Oh wait, when you tell me that there are errors, I can find them too, e.g.:

    [junit] ------------- Standard Output ---------------
    [junit] Test: column-number_non-integer.fo
    [junit]   [FATAL] fo:table overlaps in column 2.
    [junit]   [ERROR] Invalid property value encountered in column-number="-1": org.apache.fop.fo.expr.PropertyException: fo:table overlaps in column 2. (See position 34:64)

But why does this not result in a positive error count?

-- 
Simon Pepping
home page: http://www.leverkruid.eu

Re: For years I was asking...

Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
You can unsubscribe from the mailing list by sending an empty mail to
fop-dev-unsubscribe@xmlgraphics.apache.org.

Unsubscribing from Bugzilla notifications is difficult if not impossible.
You can remove your mail address from CC entries but if you're the
creator, that's just it.

On 09.05.2008 20:29:34 b.ohnsorg wrote:
> ...to do something and it turned out, that I won't have the time to do
> so...I tried to unlist from this list as well as bugzilla's but I can't.
> Can someone with admin role do this for me? Thanks...
> 
> -- 
> ------
> 
> http://krachlattenpaul.homelinux.org
> 
> Home of Trackbase (1.3.0), VoiceLeadingCalculator (1.2.1) and
> the immortal Swear-O-Tron...




Jeremias Maerki


Re: svn commit: r649657 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOPropertyMapping.java flow/table/TableFObj.java properties/NumberProperty.java

Posted by Andreas Delmelle <an...@telenet.be>.
On May 8, 2008, at 00:03, Andreas Delmelle wrote:
>>>>
>>>>
>>>     [junit] ------------- Standard Output ---------------
>>>     [junit] Test: column-number_non-integer.fo
>>>     [junit]   [FATAL] fo:table overlaps in column 2.
>>>     [junit]   [ERROR] Invalid property value encountered in  
>>> column-number="-1": org.apache.fop.fo.expr.PropertyException:  
>>> fo:table overlaps in column 2. (See position 34:64)
>>>
> Already looking at this closer, the error message looks a bit  
> strange too.
> The overlap is supposedly taking place in column 2, instead of 1...

... and it is a fo:table that overlaps, not a fo:table-cell. :-/

<snip />
> That should probably simply be isColumnNumberUsed(i)
>


Errm, of course it's not /that/ simple ;-P

We also need:

int i = columnNumber - 1;
int lastIndex = columnNumber + colspan - 1;
while (++i < lastIndex) {
   if (isColumnNumberUsed(i)) {
   ...
   }
}

Commit fixing both issues to follow soon.



Cheers

Andreas 

Re: svn commit: r649657 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOPropertyMapping.java flow/table/TableFObj.java properties/NumberProperty.java

Posted by Andreas Delmelle <an...@telenet.be>.
On May 7, 2008, at 22:34, Andreas Delmelle wrote:
> On May 7, 2008, at 22:00, Simon Pepping wrote:
>>>
>>     [junit] ------------- Standard Output ---------------
>>     [junit] Test: column-number_non-integer.fo
>>     [junit]   [FATAL] fo:table overlaps in column 2.
>>     [junit]   [ERROR] Invalid property value encountered in column- 
>> number="-1": org.apache.fop.fo.expr.PropertyException: fo:table  
>> overlaps in column 2. (See position 34:64)
>>
>> But why does this not result in a positive error count?
>
> Now that you mention it... Looks like a condition that the current  
> test code does not account for.
> On FOP's side, if property parsing for the parent fails, then the  
> extension AssertElement that tests for the property value will  
> never even be processed.
>
> I was looking to make a few adjustments in the test-package anyway,  
> so I'll check and try to fix this too.

Already looking at this closer, the error message looks a bit strange  
too.
The overlap is supposedly taking place in column 2, instead of 1...

This seems to be an error in ColumnNumberPropertyMaker.make().
We 'make' the value, which returns a NumberProperty with numeric  
value 1 and specified value -1.

Now, it seems that the loop is 'off'.

int columnIndex = p.getNumeric().getValue();
...
int i = -1;
while (++i < colspan) {
   if (columnIndexManager.isColumnNumberUsed(columnIndex + i)) {
   ...
}

So, if 'columnIndex' is 1, then we erroneously check whether column 2  
is occupied...?

That should probably simply be isColumnNumberUsed(i)


Cheers

Andreas

For years I was asking...

Posted by "b.ohnsorg" <b....@freenet.de>.
...to do something and it turned out, that I won't have the time to do so...I tried to unlist from this list as well as bugzilla's but I can't. Can someone with admin role do this for me? Thanks...

-- 
------

http://krachlattenpaul.homelinux.org

Home of Trackbase (1.3.0), VoiceLeadingCalculator (1.2.1) and
the immortal Swear-O-Tron...

Re: svn commit: r649657 - in /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo: FOPropertyMapping.java flow/table/TableFObj.java properties/NumberProperty.java

Posted by Andreas Delmelle <an...@telenet.be>.
On May 7, 2008, at 22:00, Simon Pepping wrote:
>>
>> <snip />
>> The new PositiveIntegerMaker always returns a property with value  
>> of 1 if
>> the specified value is negative or zero. Now, for column-number,  
>> it used
>> to be so that those values were replaced by the next free column- 
>> number.
>> After the change, we get overlap errors in the fotree testsuite  
>> because
>> of this.
>
> That is right, PositiveIntegerMaker does not look for the next free
> column-number. I would have minded that better if there would have
> been junit test errors. But there are none:
>
> junit-fotree:
>      [echo] Running fo tree tests
>     [junit] Testsuite: org.apache.fop.fotreetest.FOTreeTestSuite
>     [junit] Tests run: 57, Failures: 0, Errors: 0, Time elapsed:  
> 2.232 sec
>     [junit]
>
> Oh wait, when you tell me that there are errors, I can find them  
> too, e.g.:
>
>     [junit] ------------- Standard Output ---------------
>     [junit] Test: column-number_non-integer.fo
>     [junit]   [FATAL] fo:table overlaps in column 2.
>     [junit]   [ERROR] Invalid property value encountered in column- 
> number="-1": org.apache.fop.fo.expr.PropertyException: fo:table  
> overlaps in column 2. (See position 34:64)
>
> But why does this not result in a positive error count?

Now that you mention it... Looks like a condition that the current  
test code does not account for.
On FOP's side, if property parsing for the parent fails, then the  
extension AssertElement that tests for the property value will never  
even be processed.

I was looking to make a few adjustments in the test-package anyway,  
so I'll check and try to fix this too.


Cheers

Andreas