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 Jeremias Maerki <de...@jeremias-maerki.ch> on 2006/02/15 14:23:18 UTC
Re: svn commit: r378003 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Why did you discard my suggestion about PropertyTokenizer? Is there
something wrong with that? I think it would be a more general solution.
On 15.02.2006 14:07:59 adelmelle wrote:
> Author: adelmelle
> Date: Wed Feb 15 05:07:57 2006
> New Revision: 378003
>
> URL: http://svn.apache.org/viewcvs?rev=378003&view=rev
> Log:
> Added default empty String to the border shorthand. Avoids NPE mentioned in Bugzilla 38648. Still need to add a warning, since property now silently falls back to the default(s).
>
> Modified:
> xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
>
> Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
> URL: http://svn.apache.org/viewcvs/xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java?rev=378003&r1=378002&r2=378003&view=diff
> ==============================================================================
> --- xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java (original)
> +++ xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java Wed Feb 15 05:07:57 2006
> @@ -2623,6 +2623,9 @@
> // background-position
> m = new ListProperty.Maker(PR_BACKGROUND_POSITION);
> m.setInherited(false);
> + m.addKeyword("left", "0% 50%");
> + m.addKeyword("center", "50% 50%");
> + m.addKeyword("right", "100% 50%");
> m.setDefault("0% 0%");
> m.setDatatypeParser(new BackgroundPositionShorthandParser());
> addPropertyMaker("background-position", m);
> @@ -2630,6 +2633,7 @@
> // border
> m = new ListProperty.Maker(PR_BORDER);
> m.setInherited(false);
> + m.setDefault("");
> m.setDatatypeParser(new GenericShorthandParser());
> addPropertyMaker("border", m);
Jeremias Maerki
Re: svn commit: r378003 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Thanks for explaining. That's ok for me then.
On 15.02.2006 14:37:13 Andreas L Delmelle wrote:
> On Feb 15, 2006, at 14:23, Jeremias Maerki wrote:
>
> > Why did you discard my suggestion about PropertyTokenizer? Is there
> > something wrong with that? I think it would be a more general
> > solution.
>
> Oh, sorry, it's not really about 'discarding'... It just seemed more
> 'proper'.
> Allow me to explain: The way I understand the Properties API, a null
> is simply never meant to make it into the PropertyParser/
> PropertyTokenizer. As a last resort, the whole chain of calls
> starting at PropertyList.get() should ultimately return the default
> value if a value cannot be obtained by any other means (inheritance,
> shorthands and the like). This default value is, I admit, undefined
> for a few shorthands. Setting their default value to an empty string
> avoids a null from being handed over to PropertyParser.
>
> Which solution is better? Gosh, I wish Finn were online now to share
> some insights...
Jeremias Maerki
Re: svn commit: r378003 - /xmlgraphics/fop/trunk/src/java/org/apache/fop/fo/FOPropertyMapping.java
Posted by Andreas L Delmelle <a_...@pandora.be>.
On Feb 15, 2006, at 14:23, Jeremias Maerki wrote:
> Why did you discard my suggestion about PropertyTokenizer? Is there
> something wrong with that? I think it would be a more general
> solution.
Oh, sorry, it's not really about 'discarding'... It just seemed more
'proper'.
Allow me to explain: The way I understand the Properties API, a null
is simply never meant to make it into the PropertyParser/
PropertyTokenizer. As a last resort, the whole chain of calls
starting at PropertyList.get() should ultimately return the default
value if a value cannot be obtained by any other means (inheritance,
shorthands and the like). This default value is, I admit, undefined
for a few shorthands. Setting their default value to an empty string
avoids a null from being handed over to PropertyParser.
Which solution is better? Gosh, I wish Finn were online now to share
some insights...
Cheers,
Andreas