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 Andreas L Delmelle <a_...@pandora.be> on 2005/08/23 21:01:13 UTC
Non-implemented props: border-*-precedence
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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?
+ 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? I know every
PropertyList holds a reference to its parent FObj, but checking the
runtime-type of that FObj for each of the individual PropertyLists
seems a rather cumbersome approach. I somehow feel it would be tidier
if we use the FObj class hierarchy here, and let each subclass decide
for itself what default value to assign if the value is "none" at that
point ("none" = the default that is set in FOPropertyMapping)
* In the table objects' bind() methods, I was thinking of reading these
from the property list into a small array, where the indices correspond
to constant values for the four sides --the ones defined in
CommonBorderPaddingBackground?--, so that layout can conveniently
access the precedence values through a method like:
public int getBorderPrecedence(int side) {
return borderPrecedence[side];
}
Comments/suggestions welcome.
That's it for now.
Cheers,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDC3KDyHTbFO9b8aARAmpNAKCfwZklGAdD5/vvXmEV0vnbJBsspQCfWlbj
oeGfci96Y9WBEgH6bzpo7A0=
=CsfB
-----END PGP SIGNATURE-----
Re: Non-implemented props: border-*-precedence
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 23.08.2005 21:01:13 Andreas L Delmelle wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> 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,
Wohoooo! Thanks for taking this not quite trivial task upon yourself.
You know we're going to be heroes if we get the collapsing border model
working!
> 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...
Can't wait!
> 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.
That's ok.
> 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?
I think it would be a normal NumberProperty to which you add enums by
calling addEnum().
...but IANFOTS = I am no FO tree specialist. :-)
> + Another question concerning the possible value of 'inherit': does it
> suffice to have Maker.setInherited() set the flag to true (in
> FOProperyMapping)?
No, the border precedence properties are not inherited. I think the
"inherited" value is automatically handled. You don't need to do
anything special.
> * 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? I know every
Can't tell. Sorry.
> PropertyList holds a reference to its parent FObj, but checking the
> runtime-type of that FObj for each of the individual PropertyLists
> seems a rather cumbersome approach. I somehow feel it would be tidier
> if we use the FObj class hierarchy here, and let each subclass decide
> for itself what default value to assign if the value is "none" at that
> point ("none" = the default that is set in FOPropertyMapping)
>
> * In the table objects' bind() methods, I was thinking of reading these
> from the property list into a small array, where the indices correspond
> to constant values for the four sides --the ones defined in
> CommonBorderPaddingBackground?--, so that layout can conveniently
> access the precedence values through a method like:
>
> public int getBorderPrecedence(int side) {
> return borderPrecedence[side];
> }
>
> Comments/suggestions welcome.
>
> That's it for now.
Good luck!!!
Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Posted by Jeremias Maerki <de...@greenmail.ch>.
It works now. The only remaining problem is a warning message for all
the properties defined by the assert element because I had to make
AssertElement a subclass of FONode so it has a PropertyList which it
wouldn't have were it a subclass from XMLObj only.
Shall I commit this stuff?
On 29.08.2005 22:29:19 Jeremias Maerki wrote:
> 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.
>
> Right now, I'm simply running a normal FOP processing run, but the
> layout engine wouldn't actually need to be called at all. And I get
> warnings about unsupported properties but that's a detail. The
> integration into a JUnit test case is easy.
>
> So, if anyone's eager to write test cases for the FO tree, I can commit
> what I already have.
>
> On 29.08.2005 21:28:20 Finn Bock wrote:
> > >>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:
> >
> > <fo:block border-before-style="solid" border-before-width="10pt" >
> > <fox:assert property="border-top-width" result="10000mpt"/>
> > </fo:block>
> >
> > but I'm not sure how it can be made part of a junit suite.
>
>
>
> Jeremias Maerki
Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Aug 29, 2005, at 22:29, Jeremias Maerki wrote:
<snip />
>
> So, if anyone's eager to write test cases for the FO tree, I can commit
> what I already have.
Jeremias / Finn,
Thanks a lot to the both of you!
Considering what I'm working on, this may come in *very* handy, since
in a number of cases the border property values in our FOTree will
actually have to differ from the ones specified in the actual source
document.
No need to rush just yet, but if you could commit them somewhere in the
next week or two, that would be very much appreciated.
Cheers,
Andreas
Re: Non-implemented props: border-*-precedence
Posted by Finn Bock <bc...@worldonline.dk>.
[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 <test:assert>, <eval> and <true> 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
Posted by Jeremias Maerki <de...@greenmail.ch>.
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.
Right now, I'm simply running a normal FOP processing run, but the
layout engine wouldn't actually need to be called at all. And I get
warnings about unsupported properties but that's a detail. The
integration into a JUnit test case is easy.
So, if anyone's eager to write test cases for the FO tree, I can commit
what I already have.
On 29.08.2005 21:28:20 Finn Bock wrote:
> >>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:
>
> <fo:block border-before-style="solid" border-before-width="10pt" >
> <fox:assert property="border-top-width" result="10000mpt"/>
> </fo:block>
>
> but I'm not sure how it can be made part of a junit suite.
Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Posted by Finn Bock <bc...@worldonline.dk>.
>>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:
<fo:block border-before-style="solid" border-before-width="10pt" >
<fox:assert property="border-top-width" result="10000mpt"/>
</fo:block>
but I'm not sure how it can be made part of a junit suite.
regards,
finn
Re: Non-implemented props: border-*-precedence
Posted by Jeremias Maerki <de...@greenmail.ch>.
On 26.08.2005 09:09:45 Finn Bock wrote:
> [Andreas L Delmelle]
>
> > Any hint appreciated.
>
> I have added support for the default values in a TableBorderPrecedence
> property maker class.
Cool. It's so good to see names other than mine on the commits list.
> Since I have added a new file to SVN must I do something to make line
> ending right?
I've just added svn:keywords ("Id") and svn:eol-style ("native") to the
file.
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.
> 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.
Jeremias Maerki
Re: Non-implemented props: border-*-precedence
Posted by Chris Bowditch <bo...@hotmail.com>.
Finn Bock wrote:
> [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?
Yes you need to set the SVN property svn:eol-style=native
>
> Is there a way in our test system to check the values of properties in
> the fo tree?
No. The layout engine tests can only check values in the Area Tree XML.
So you could modify the XML Renderer to output FO Tree values that you
want to check. ALthough you might want to make this optional as I'm not
very keen on having FO Tree data in the Area Tree output.
Chris
Re: Non-implemented props: border-*-precedence
Posted by Finn Bock <bc...@worldonline.dk>.
[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: Non-implemented props: border-*-precedence
Posted by Andreas L Delmelle <a_...@pandora.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 24, 2005, at 19:15, Andreas L Delmelle wrote:
>
> Wouldn't inheritance still work as desired --by the Property
> subsystem-- if the default value is set in the FObj's bind() method?
Hmm. ATM, it doesn't seem to be working...
I tried using Property.setSpecifiedValue() in Table.bind(), but no
effect. The descendant nodes still inherit the initial default of
EN_NONE, so the 'inherit' value is already resolved before the
ancestor's PropertyList is bound.
The search continues...
Any hint appreciated.
Cheers,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDDMkdyHTbFO9b8aARAneSAKCgTrCJ/v6H2dux+epF7kjz6In3EwCfQt31
Qzm1TmzHFnHCj7a9IHeh9LM=
=q7yu
-----END PGP SIGNATURE-----
Re: Non-implemented props: border-*-precedence
Posted by Andreas L Delmelle <a_...@pandora.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 23, 2005, at 23:32, Andreas L Delmelle wrote:
> On Aug 23, 2005, at 22:09, Finn Bock wrote:
>
>> 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).
>
> Oh, I definitely think it's possible. It will just take some more time
> to figure it out.
Just FYI: Eureka! I think... ;-)
(No need to reply, actually; just going to try it out and see if it
works...)
Wouldn't inheritance still work as desired --by the Property
subsystem-- if the default value is set in the FObj's bind() method? I
mean, for example: in Table.bind(), check if the precedence received
the default value in FOPropertyMapping (getEnum() == EN_NONE). If so,
force the value to the integer 6. IIUC, if the column inherits that
value, then the PropertyList should handle this very nicely, and return
an integer value of 6 when the property is queried for its value in
TableColumn.bind()
Cheers,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDDKtRyHTbFO9b8aARAjqPAJ0Wpu4axtxKQBikq+YP0Llpw06wNwCdEDXo
3t4935m6x7vgO1D3WjeWv9Q=
=nwcO
-----END PGP SIGNATURE-----
Re: Non-implemented props: border-*-precedence
Posted by Andreas L Delmelle <a_...@pandora.be>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Aug 23, 2005, at 22:09, Finn Bock wrote:
> Andreas L Delmelle wrote:
>
> 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.
(Just the man whose input I was looking for :-) )
OK, thanks for clarifying.
>> * 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.
That's what I suspected, hence my question.
If we consider inheritance in the following simple case:
<fo:table>
<!-- no border precedence specified, so all default to 6 -->
<fo:table-column border-before-precedence="inherit" ... />
If I interpret the Rec correctly (5.1.4 Inheritance) the column
inherits the computed value of 6 from the table (as opposed to getting
its own default value of 4).
That complicates matters... but maybe only a bit, since I already
hinted at the other option: from within the property subsystem, check
the runtime-type of the FObj to which the PropertyList is attached, and
use that type to determine the default value.
My only remaining question is: where exactly should that happen?
Can anyone think of another property where the default value depends on
the type of object it is attached to? Maybe that'll give me some idea.
> 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).
Oh, I definitely think it's possible. It will just take some more time
to figure it out.
Thanks for your input.
Cheers,
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDC5X1yHTbFO9b8aARAruDAKCvwewDpY29d5Yf5R2zhDyRjq1S3wCgslaj
lQd10RWhp9Hvsjj8U82GR5k=
=piTN
-----END PGP SIGNATURE-----
Re: Non-implemented props: border-*-precedence
Posted by Finn Bock <bc...@worldonline.dk>.
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