Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

With 7 +1 votes and a 0.5 for limited CSS3 support I am able to close
the vote and perform the merge.

Thank you to all those who explored the feature and provide feedback!

Peter

On Tue, Oct 23, 2012 at 11:36 PM, Luis Bernardo  wrote:
>
> my vote: +1
>
>
> On 10/12/12 10:40 AM, Peter Hancock wrote:
>>
>> Hi,
>>
>> Luis Benardo and Myself have just done some clean up to the branch
>> Temp_RoundedCorners.  This branch implements support for 'fox'
>> extension properties  for specifying borders with rounded corners.
>> Please refer to [1] and [2] for details.
>>
>> There is an example fo [3] that demonstrates the feature.
>>
>> Currently we are supporting:
>>PDF, PS and AFP outputs
>>'border-style' property with values of  'solid', 'none', 'hidden'
>> and, to a limited degree, 'dashed'
>>
>> I would like to start a vote to merge feature branch to trunk, with my +1.
>>
>> Thanks,
>>
>> Peter
>>
>> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
>> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
>> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners
>> branch
>
>

Re: [Vote] for the merge of Temp_RoundedCorners

[Luis Bernardo]

my vote: +1

On 10/12/12 10:40 AM, Peter Hancock wrote:

Hi,

Luis Benardo and Myself have just done some clean up to the branch
Temp_RoundedCorners.  This branch implements support for 'fox'
extension properties  for specifying borders with rounded corners.
Please refer to [1] and [2] for details.

There is an example fo [3] that demonstrates the feature.

Currently we are supporting:
   PDF, PS and AFP outputs
   'border-style' property with values of  'solid', 'none', 'hidden'
and, to a limited degree, 'dashed'

I would like to start a vote to merge feature branch to trunk, with my +1.

Thanks,

Peter

[1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
[2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
[2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch

Re: [Vote] for the merge of Temp_RoundedCorners

[mehdi houshmand]

+1 from me

On 23 October 2012 13:25, Clay Leeds  wrote:

> +1 from me...
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
> On Oct 22, 2012, at 8:04 AM, Peter Hancock 
> wrote:
>
> > Hi Glenn,
> >
> > I have just committed to Temp_RoundedCorners to address some of the
> > concerns raised.
> >
> >> My preference would be to provide both the CSS3 named properties and
> also
> >> writing system relative properties, giving the user the preference of
> which
> >> to use. But I would suggest using the same pattern as CSS3 for property
> >> names for these latter:
> >>
> >> border-top-left-radius
> >> border-top-right-radius
> >> border-bottom-right-radius
> >> border-bottom-left-radius
> >>
> >> border-before-start-radius
> >> border-before-end-radius
> >> border-after-start-radius
> >> border-after-end-radius
> >
> > I have now implemented border properties of the form
> > border-before-start-radius, that take one or two values, in line with
> > the CSS3 recommendation.  However, I have not been able as yet to
> > implement properties for the absolute properties
> > (border-top-left-radius, etc).  I am unable to prove concretely that
> > the property resolution system can or cannot support my requirements
> > here, but either way I have decided to put this requirement on hold
> > for now.  The omission of these properties will not affect backwards
> > compatibility going forward and so I do not personally consider it to
> > be a show stopper.
> >
> >> it would also be useful to support the border-radius shortcut from CSS3
> >> (mapping to the above CSS3 longhand flavors)
> > This was done previously if we accept that the second value refers to
> > the block progression direction and not the absolute top-to-bottom
> > direction.
> >
> > I have updated the example fo and the CMS to reflect these changes.
> >
> > If you are happy with the change I can proceed with the merge.
> >
> > Thanks,
> >
> > Peter
>

Re: [Vote] for the merge of Temp_RoundedCorners

[Clay Leeds]

+1 from me...

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Oct 22, 2012, at 8:04 AM, Peter Hancock  wrote:

> Hi Glenn,
> 
> I have just committed to Temp_RoundedCorners to address some of the
> concerns raised.
> 
>> My preference would be to provide both the CSS3 named properties and also
>> writing system relative properties, giving the user the preference of which
>> to use. But I would suggest using the same pattern as CSS3 for property
>> names for these latter:
>> 
>> border-top-left-radius
>> border-top-right-radius
>> border-bottom-right-radius
>> border-bottom-left-radius
>> 
>> border-before-start-radius
>> border-before-end-radius
>> border-after-start-radius
>> border-after-end-radius
> 
> I have now implemented border properties of the form
> border-before-start-radius, that take one or two values, in line with
> the CSS3 recommendation.  However, I have not been able as yet to
> implement properties for the absolute properties
> (border-top-left-radius, etc).  I am unable to prove concretely that
> the property resolution system can or cannot support my requirements
> here, but either way I have decided to put this requirement on hold
> for now.  The omission of these properties will not affect backwards
> compatibility going forward and so I do not personally consider it to
> be a show stopper.
> 
>> it would also be useful to support the border-radius shortcut from CSS3
>> (mapping to the above CSS3 longhand flavors)
> This was done previously if we accept that the second value refers to
> the block progression direction and not the absolute top-to-bottom
> direction.
> 
> I have updated the example fo and the CMS to reflect these changes.
> 
> If you are happy with the change I can proceed with the merge.
> 
> Thanks,
> 
> Peter

Re: [Vote] for the merge of Temp_RoundedCorners

[Pascal Sancho]

Hi,

great job, Peter.
I have just a comment: when using invalid *-radius property (IE
fox:border-end-after-radius, inverting b-p-d and i-p-d radices), FOP
should warn or throw an exception, but I guess this is a more general
fox behaviour.

still +1 for me.

2012/10/22 Peter Hancock :
> Hi Jeremias,
>
> I have updated the CMS to document that there are limitations with
> tables.   I have suggested that setting the 'border-collapse' property
> on tables to 'separate'  will allow the support of rounded corners on
> tables.
>
> I am currently fighting with FOPropertyMapping to support the absolute
> properties and I am not having much luck.
>
> Thanks again for your help with this feature!
>
> Peter
>
> On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki
>  wrote:
>> I took a peek since I helped with the branch in the beginning. Nice job
>> over all!!! Good looking borders!
>>
>> I agree with Glenn that the extension should be aligned with CSS3 as
>> closely as possible. In the usual XSL manner there should ideally be
>> both relative (start, end...) and absolute (top, left...) properties.
>>
>> While there seem to be unit tests for the generation of painting
>> operators there are no layout engine tests that verify area tree
>> generation as well as area tree and IF parsing/round-trips.
>>
>> Also I haven't found any mention in the docs or the demo file that
>> rounded borders on tables are not implemented, yet. I found that out the
>> "hard way". Seems like border radius information is lost during border
>> collapse processing. However, that should be easy to fix and is probably
>> a matter of adding a few lines to CollapsingBorderModelEyeCatching.java.
>> Some layout engine tests will help here.
>>
>> +0.5 as the current state goes. +1 if CSS3 alignment is achieved and
>> there are a few layout engine tests (at least one for fo:block and one
>> for fo:inline) checking the decoding of the enhanced border function
>> and the AT/IF round-trip.
>>
>> The missing table border support is surely not blocking.
>>
>> Jeremias Maerki
>>
>>
>> On 12.10.2012 11:40:19 Peter Hancock wrote:
>>> Hi,
>>>
>>> Luis Benardo and Myself have just done some clean up to the branch
>>> Temp_RoundedCorners.  This branch implements support for 'fox'
>>> extension properties  for specifying borders with rounded corners.
>>> Please refer to [1] and [2] for details.
>>>
>>> There is an example fo [3] that demonstrates the feature.
>>>
>>> Currently we are supporting:
>>>   PDF, PS and AFP outputs
>>>   'border-style' property with values of  'solid', 'none', 'hidden'
>>> and, to a limited degree, 'dashed'
>>>
>>> I would like to start a vote to merge feature branch to trunk, with my +1.
>>>
>>> Thanks,
>>>
>>> Peter
>>>
>>> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
>>> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
>>> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners 
>>> branch
>>



-- 
pascal

Re: [Vote] for the merge of Temp_RoundedCorners

[Glenn Adams]

thanks, i'm good to go then, so you  have my +1

On Mon, Oct 22, 2012 at 11:04 PM, Peter Hancock wrote:

> Hi Glenn,
>
> I have just committed to Temp_RoundedCorners to address some of the
> concerns raised.
>
> > My preference would be to provide both the CSS3 named properties and also
> > writing system relative properties, giving the user the preference of
> which
> > to use. But I would suggest using the same pattern as CSS3 for property
> > names for these latter:
> >
> > border-top-left-radius
> > border-top-right-radius
> > border-bottom-right-radius
> > border-bottom-left-radius
> >
> > border-before-start-radius
> > border-before-end-radius
> > border-after-start-radius
> > border-after-end-radius
>
> I have now implemented border properties of the form
> border-before-start-radius, that take one or two values, in line with
> the CSS3 recommendation.  However, I have not been able as yet to
> implement properties for the absolute properties
> (border-top-left-radius, etc).  I am unable to prove concretely that
> the property resolution system can or cannot support my requirements
> here, but either way I have decided to put this requirement on hold
> for now.  The omission of these properties will not affect backwards
> compatibility going forward and so I do not personally consider it to
> be a show stopper.
>
> > it would also be useful to support the border-radius shortcut from CSS3
> > (mapping to the above CSS3 longhand flavors)
> This was done previously if we accept that the second value refers to
> the block progression direction and not the absolute top-to-bottom
> direction.
>
> I have updated the example fo and the CMS to reflect these changes.
>
> If you are happy with the change I can proceed with the merge.
>
> Thanks,
>
> Peter
>

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Hi Vincent,

In the last commit to Temp_RoundedCorners I have addressed all your
points, except:
> • o.a.f.render.intermediate.BorderPainterTestCase
>   the generics don’t seem necessary and could be removed altogether
I would like to improve that little micro-framework to eliminate the
need for generics (and the cast I had to do!) but I think it serves
it's purpose for now.

Thanks,

Pete

On Fri, Oct 19, 2012 at 4:43 PM, Vincent Hennebert  wrote:
> +1
>
> Having the ‘absolute’ versions of the properties would be nice but this
> is not IMO a blocker requirement for the merge of this work.
>
> Here are a few comments based on a quick look at the branch:
> • o.a.f.fo.Constants
>   PR_X_BORDER_START_RADIUS_START
>   PR_X_BORDER_START_RADIUS_END
>   PR_X_BORDER_END_RADIUS_START
>   PR_X_BORDER_END_RADIUS_END
>   Shouldn’t it be
>   PR_X_BORDER_START_RADIUS_BEFORE
>   PR_X_BORDER_START_RADIUS_AFTER
>   PR_X_BORDER_END_RADIUS_BEFORE
>   PR_X_BORDER_END_RADIUS_AFTER
>   ?
> • o.a.f.fo.properties.BoxCornerPropShorthandParser
>   some glitches in the javadoc for convertValueForProperty
> • o.a.f.fo.properties.CommonBorderPaddingBackground
>   there’s a commented out ‘if (style != Constants.EN_NONE) {’? Is that
>   left-overs from debugging that can be removed?
> • o.a.f.layoutmgr.TraitSetter
>   line ~100: it’s a shame to re-introduce Hungarian notation
> • o.a.f.render.intermediate.BorderPainter
>   left-over ‘TODO remove before integration’?
>   drawBorderSegment: don’t you want to use Math.round instead of
>   directly casting to int, for better precision?
> • o.a.f.render.intermediate.BorderPainterTestCase
>   the generics don’t seem necessary and could be removed altogether
> • o.a.f.render.pdf.PDFPainterTestCase,
>   o.a.f.render.ps.PSPainterTestCase
>   the ‘// mock’ comments are hardly helpful and could be removed; the
>   variables could instead be renamed into something that starts with
>   ‘mock’ so that we know what is what later in the code.
>   The try...catch should really be removed: if an exception occurs
>   during the test it will be swallowed (along with its stack trace) by
>   the catch and replaced with an unhelpful AssertionError with no stack
>   trace.
>
>
> Thanks,
> Vincent
>
>
> On 12/10/12 10:40, Peter Hancock wrote:
>> Hi,
>>
>> Luis Benardo and Myself have just done some clean up to the branch
>> Temp_RoundedCorners.  This branch implements support for 'fox'
>> extension properties  for specifying borders with rounded corners.
>> Please refer to [1] and [2] for details.
>>
>> There is an example fo [3] that demonstrates the feature.
>>
>> Currently we are supporting:
>>   PDF, PS and AFP outputs
>>   'border-style' property with values of  'solid', 'none', 'hidden'
>> and, to a limited degree, 'dashed'
>>
>> I would like to start a vote to merge feature branch to trunk, with my +1.
>>
>> Thanks,
>>
>> Peter
>>
>> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
>> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
>> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
>>

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Hi Jeremias,

I have updated the CMS to document that there are limitations with
tables.   I have suggested that setting the 'border-collapse' property
on tables to 'separate'  will allow the support of rounded corners on
tables.

I am currently fighting with FOPropertyMapping to support the absolute
properties and I am not having much luck.

Thanks again for your help with this feature!

Peter

On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki
 wrote:
> I took a peek since I helped with the branch in the beginning. Nice job
> over all!!! Good looking borders!
>
> I agree with Glenn that the extension should be aligned with CSS3 as
> closely as possible. In the usual XSL manner there should ideally be
> both relative (start, end...) and absolute (top, left...) properties.
>
> While there seem to be unit tests for the generation of painting
> operators there are no layout engine tests that verify area tree
> generation as well as area tree and IF parsing/round-trips.
>
> Also I haven't found any mention in the docs or the demo file that
> rounded borders on tables are not implemented, yet. I found that out the
> "hard way". Seems like border radius information is lost during border
> collapse processing. However, that should be easy to fix and is probably
> a matter of adding a few lines to CollapsingBorderModelEyeCatching.java.
> Some layout engine tests will help here.
>
> +0.5 as the current state goes. +1 if CSS3 alignment is achieved and
> there are a few layout engine tests (at least one for fo:block and one
> for fo:inline) checking the decoding of the enhanced border function
> and the AT/IF round-trip.
>
> The missing table border support is surely not blocking.
>
> Jeremias Maerki
>
>
> On 12.10.2012 11:40:19 Peter Hancock wrote:
>> Hi,
>>
>> Luis Benardo and Myself have just done some clean up to the branch
>> Temp_RoundedCorners.  This branch implements support for 'fox'
>> extension properties  for specifying borders with rounded corners.
>> Please refer to [1] and [2] for details.
>>
>> There is an example fo [3] that demonstrates the feature.
>>
>> Currently we are supporting:
>>   PDF, PS and AFP outputs
>>   'border-style' property with values of  'solid', 'none', 'hidden'
>> and, to a limited degree, 'dashed'
>>
>> I would like to start a vote to merge feature branch to trunk, with my +1.
>>
>> Thanks,
>>
>> Peter
>>
>> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
>> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
>> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
>

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Hi Glenn,

I have just committed to Temp_RoundedCorners to address some of the
concerns raised.

> My preference would be to provide both the CSS3 named properties and also
> writing system relative properties, giving the user the preference of which
> to use. But I would suggest using the same pattern as CSS3 for property
> names for these latter:
>
> border-top-left-radius
> border-top-right-radius
> border-bottom-right-radius
> border-bottom-left-radius
>
> border-before-start-radius
> border-before-end-radius
> border-after-start-radius
> border-after-end-radius

I have now implemented border properties of the form
border-before-start-radius, that take one or two values, in line with
the CSS3 recommendation.  However, I have not been able as yet to
implement properties for the absolute properties
(border-top-left-radius, etc).  I am unable to prove concretely that
the property resolution system can or cannot support my requirements
here, but either way I have decided to put this requirement on hold
for now.  The omission of these properties will not affect backwards
compatibility going forward and so I do not personally consider it to
be a show stopper.

> it would also be useful to support the border-radius shortcut from CSS3
> (mapping to the above CSS3 longhand flavors)
This was done previously if we accept that the second value refers to
the block progression direction and not the absolute top-to-bottom
direction.

I have updated the example fo and the CMS to reflect these changes.

If you are happy with the change I can proceed with the merge.

Thanks,

Peter

Re: [Vote] for the merge of Temp_RoundedCorners

[Vincent Hennebert]

+1

Having the ‘absolute’ versions of the properties would be nice but this
is not IMO a blocker requirement for the merge of this work.

Here are a few comments based on a quick look at the branch:
• o.a.f.fo.Constants
  PR_X_BORDER_START_RADIUS_START
  PR_X_BORDER_START_RADIUS_END
  PR_X_BORDER_END_RADIUS_START
  PR_X_BORDER_END_RADIUS_END
  Shouldn’t it be
  PR_X_BORDER_START_RADIUS_BEFORE
  PR_X_BORDER_START_RADIUS_AFTER
  PR_X_BORDER_END_RADIUS_BEFORE
  PR_X_BORDER_END_RADIUS_AFTER
  ?
• o.a.f.fo.properties.BoxCornerPropShorthandParser
  some glitches in the javadoc for convertValueForProperty
• o.a.f.fo.properties.CommonBorderPaddingBackground
  there’s a commented out ‘if (style != Constants.EN_NONE) {’? Is that
  left-overs from debugging that can be removed?
• o.a.f.layoutmgr.TraitSetter
  line ~100: it’s a shame to re-introduce Hungarian notation
• o.a.f.render.intermediate.BorderPainter
  left-over ‘TODO remove before integration’?
  drawBorderSegment: don’t you want to use Math.round instead of
  directly casting to int, for better precision?
• o.a.f.render.intermediate.BorderPainterTestCase
  the generics don’t seem necessary and could be removed altogether
• o.a.f.render.pdf.PDFPainterTestCase,
  o.a.f.render.ps.PSPainterTestCase
  the ‘// mock’ comments are hardly helpful and could be removed; the
  variables could instead be renamed into something that starts with
  ‘mock’ so that we know what is what later in the code.
  The try...catch should really be removed: if an exception occurs
  during the test it will be swallowed (along with its stack trace) by
  the catch and replaced with an unhelpful AssertionError with no stack
  trace.


Thanks,
Vincent


On 12/10/12 10:40, Peter Hancock wrote:
> Hi,
> 
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
> 
> There is an example fo [3] that demonstrates the feature.
> 
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
> 
> I would like to start a vote to merge feature branch to trunk, with my +1.
> 
> Thanks,
> 
> Peter
> 
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch
> 

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Great feedback everyone.  I will address property naming and document
the table limitation spotted by Jeremias.

On Sun, Oct 14, 2012 at 10:56 AM, Jeremias Maerki
 wrote:
> While there seem to be unit tests for the generation of painting
> operators there are no layout engine tests that verify area tree
> generation as well as area tree and IF parsing/round-trips.

Since the feature did not impact on the layout process other than
adding new area traits, I did not consider at the time that there was
a need for layout tests.  I agree that there is value in testing the
area tree and IF serialization/parsing and will create some tests.

Thanks,

Peter

Re: [Vote] for the merge of Temp_RoundedCorners

[Jeremias Maerki]

I took a peek since I helped with the branch in the beginning. Nice job
over all!!! Good looking borders!

I agree with Glenn that the extension should be aligned with CSS3 as
closely as possible. In the usual XSL manner there should ideally be
both relative (start, end...) and absolute (top, left...) properties.

While there seem to be unit tests for the generation of painting
operators there are no layout engine tests that verify area tree
generation as well as area tree and IF parsing/round-trips.

Also I haven't found any mention in the docs or the demo file that
rounded borders on tables are not implemented, yet. I found that out the
"hard way". Seems like border radius information is lost during border
collapse processing. However, that should be easy to fix and is probably
a matter of adding a few lines to CollapsingBorderModelEyeCatching.java.
Some layout engine tests will help here.

+0.5 as the current state goes. +1 if CSS3 alignment is achieved and
there are a few layout engine tests (at least one for fo:block and one
for fo:inline) checking the decoding of the enhanced border function
and the AT/IF round-trip.

The missing table border support is surely not blocking.

Jeremias Maerki


On 12.10.2012 11:40:19 Peter Hancock wrote:
> Hi,
> 
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
> 
> There is an example fo [3] that demonstrates the feature.
> 
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
> 
> I would like to start a vote to merge feature branch to trunk, with my +1.
> 
> Thanks,
> 
> Peter
> 
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch

Re: [Vote] for the merge of Temp_RoundedCorners

[Glenn Adams]

My preference would be to provide both the CSS3 named properties and also
writing system relative properties, giving the user the preference of which
to use. But I would suggest using the same pattern as CSS3 for property
names for these latter:

border-top-left-radius
border-top-right-radius
border-bottom-right-radius
border-bottom-left-radius

border-before-start-radius
border-before-end-radius
border-after-start-radius
border-after-end-radius

it would also be useful to support the border-radius shortcut from CSS3
(mapping to the above CSS3 longhand flavors)

On Fri, Oct 12, 2012 at 8:48 PM, Peter Hancock wrote:

> Thanks for taking the time to review this!
>
> On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams  wrote:
> >...
> > However, I also notice that the fox property name proposed in [1]
> contains
> > uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and
> > thus warrants a -1 vote until changed to LC. All LC please!
>
> The upper case BLOCK and INLINE were meant to represent variables with
> values before and after, and start and end, respectively.
>
> > I haven't had a chance to look at the details, but does this extension
> > follow the (property name and value) definitions found in CSS3
> Backgrounds
> > and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would
> vote
> > +1.
>
> I do concede that there is a departure from CSS3:
> To specify the top left corner in CSS3 you do
> border-top-left-radius="x y"
> and with the fox extension (assuming a viewport orientated with the page)
> fox:border-start-radius-before="x"
> fox:border-before-radius-start="y"
>
> If this is unsatisfactory then I guess it is back to the drawing board.
>
> Peter
>

Re: [Vote] for the merge of Temp_RoundedCorners

[Christopher R. Maden]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/2012 10:34 AM, The Web Maestro wrote:
> Yes... We've got two 'standards' to follow here: XSL-FO and CSS3. 
> Where possible, I'd like to err on the side of CSS3, since that is 
> so much more widely used. In fact, where (if?) there are 
> discrepancies between the CSS3 & XSL-FO methods, we may want to 
> consider creating 'aliases' for one, that translates to the
> other... That could introduce bugs, and maintenance might be
> another issue, but it's something to consider.

I don’t get a vote on this... but I think that the established
precedent within XSL shows the way forward.

The proposed patch uses monotonic properties with relative direction
terminology (start, before, etc.); CSS uses absolute position terms
and combines properties.  In XSL properties like margin and border,
this is handled by defining the relative, monotonic properties as
fundamental, and CSS equivalents as synonyms that expand to the XSL
versions.

If I had a vote, I would vote to accept this patch, but to add
mappings from the CSS versions to these monotonic relative properties.

IMO,
Chris
- -- 
Chris Maden, text nerd  http://crism.maden.org/ >
LIVE FREE: vote for Gary Johnson, Libertarian for President.
 http://garyjohnson2012.com/ >  http://lp.org/ >
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQEcBAEBAgAGBQJQeFJiAAoJEEpR26xcXD1eJrwIAL26hb3TNkIWJ7Wth3WA7gqW
P4Xwv30emQLpy+2HNBrv1zYGLBw0oSp61C3GghWqGJymtSVpuph58t0HZ7aWzXSD
sQW9lmglvEXesND2piZNJjvfOMMat/7KIegq/MVW+zqYnaxCnAyZW8T8LgeBqFJ6
dVBp76YP9VefSlkKTYcC6lZIxw102I8CH0rM0vIGpeJxpnCVdDCyLNbp2zaDjKb1
fMhTFYruQdidSRTV0N0Ynzn5yto+io0DSNdsSUWzf9xR35ygVFFL0BgiwJSlDf9Y
r/H3kfQ7SA7WFLiAze4VOeqIsyu4bSVc4w2XUZaxFnE3N7ym4Pu95CGTCx50Dm4=
=f+XN
-END PGP SIGNATURE-

Re: [Vote] for the merge of Temp_RoundedCorners

[The Web Maestro]

On Fri, Oct 12, 2012 at 7:25 AM, Pascal Sancho  wrote:
> Yes, CSS3 naming is easier to understand.
> And like other border-* properties, top, right, bottom, left should be
> mapped to equivalent FO directions in lr-tb mode (respectively before,
> end, after, start).

Yes... We've got two 'standards' to follow here: XSL-FO and CSS3.
Where possible, I'd like to err on the side of CSS3, since that is so
much more widely used. In fact, where (if?) there are discrepancies
between the CSS3 & XSL-FO methods, we may want to consider creating
'aliases' for one, that translates to the other... That could
introduce bugs, and maintenance might be another issue, but it's
something to consider.

Clay

Re: [Vote] for the merge of Temp_RoundedCorners

[Pascal Sancho]

Yes, CSS3 naming is easier to understand.
And like other border-* properties, top, right, bottom, left should be
mapped to equivalent FO directions in lr-tb mode (respectively before,
end, after, start).

2012/10/12 Clay Leeds :
> I would prefer CSS3 naming conventions as well.
>
> Clay
>
> "My religion is simple. My religion is kindness."
> - HH The Dalai Lama of Tibet
>
> On Oct 12, 2012, at 6:48 AM, Peter Hancock  wrote:
>
>> Thanks for taking the time to review this!
>>
>> On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams  wrote:
>>> ...
>>> However, I also notice that the fox property name proposed in [1] contains
>>> uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and
>>> thus warrants a -1 vote until changed to LC. All LC please!
>>
>> The upper case BLOCK and INLINE were meant to represent variables with
>> values before and after, and start and end, respectively.
>>
>>> I haven't had a chance to look at the details, but does this extension
>>> follow the (property name and value) definitions found in CSS3 Backgrounds
>>> and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would vote
>>> +1.
>>
>> I do concede that there is a departure from CSS3:
>> To specify the top left corner in CSS3 you do
>> border-top-left-radius="x y"
>> and with the fox extension (assuming a viewport orientated with the page)
>> fox:border-start-radius-before="x"
>> fox:border-before-radius-start="y"
>>
>> If this is unsatisfactory then I guess it is back to the drawing board.
>>
>> Peter



-- 
pascal

Re: [Vote] for the merge of Temp_RoundedCorners

[Clay Leeds]

I would prefer CSS3 naming conventions as well. 

Clay 

"My religion is simple. My religion is kindness."
- HH The Dalai Lama of Tibet

On Oct 12, 2012, at 6:48 AM, Peter Hancock  wrote:

> Thanks for taking the time to review this!
> 
> On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams  wrote:
>> ...
>> However, I also notice that the fox property name proposed in [1] contains
>> uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and
>> thus warrants a -1 vote until changed to LC. All LC please!
> 
> The upper case BLOCK and INLINE were meant to represent variables with
> values before and after, and start and end, respectively.
> 
>> I haven't had a chance to look at the details, but does this extension
>> follow the (property name and value) definitions found in CSS3 Backgrounds
>> and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would vote
>> +1.
> 
> I do concede that there is a departure from CSS3:
> To specify the top left corner in CSS3 you do
> border-top-left-radius="x y"
> and with the fox extension (assuming a viewport orientated with the page)
> fox:border-start-radius-before="x"
> fox:border-before-radius-start="y"
> 
> If this is unsatisfactory then I guess it is back to the drawing board.
> 
> Peter

Re: [Vote] for the merge of Temp_RoundedCorners

[Peter Hancock]

Thanks for taking the time to review this!

On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams  wrote:
>...
> However, I also notice that the fox property name proposed in [1] contains
> uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and
> thus warrants a -1 vote until changed to LC. All LC please!

The upper case BLOCK and INLINE were meant to represent variables with
values before and after, and start and end, respectively.

> I haven't had a chance to look at the details, but does this extension
> follow the (property name and value) definitions found in CSS3 Backgrounds
> and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would vote
> +1.

I do concede that there is a departure from CSS3:
To specify the top left corner in CSS3 you do
border-top-left-radius="x y"
and with the fox extension (assuming a viewport orientated with the page)
fox:border-start-radius-before="x"
fox:border-before-radius-start="y"

If this is unsatisfactory then I guess it is back to the drawing board.

Peter

Re: [Vote] for the merge of Temp_RoundedCorners

[Glenn Adams]

I haven't had a chance to look at the details, but does this extension
follow the (property name and value) definitions found in CSS3 Backgrounds
and Borders [4]? If it doesn't, then my vote is -1; otherwise, I would vote
+1.

However, I also notice that the fox property name proposed in [1] contains
uppercase (fox:border-BLOCK-radius-INLINE). That is a definite no-no, and
thus warrants a -1 vote until changed to LC. All LC please!

In general, the property names and values should exactly match what are
proposed in CSS3 unless there is *a really good reason* why that shouldn't
be the case.

[4] http://www.w3.org/TR/css3-background/#corners

On Fri, Oct 12, 2012 at 5:40 PM, Peter Hancock wrote:

> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
>
> There is an example fo [3] that demonstrates the feature.
>
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
>
> I would like to start a vote to merge feature branch to trunk, with my +1.
>
> Thanks,
>
> Peter
>
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners
> branch
>

Re: [Vote] for the merge of Temp_RoundedCorners

[The Web Maestro]

Sounds good!

+1 from me!

Kind regards,

Web Maestro Clay
--
 - 
My religion is simple. My religion is kindness.
- HH The 14th Dalai Lama of Tibet


On Fri, Oct 12, 2012 at 2:40 AM, Peter Hancock  wrote:
> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
>
> There is an example fo [3] that demonstrates the feature.
>
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
>
> I would like to start a vote to merge feature branch to trunk, with my +1.
>
> Thanks,
>
> Peter
>
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch

Re: [Vote] for the merge of Temp_RoundedCorners

[Pascal Sancho]

Hi,
Very good job!
+1

2012/10/12 Peter Hancock :
> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
>
> There is an example fo [3] that demonstrates the feature.
>
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
>
> I would like to start a vote to merge feature branch to trunk, with my +1.
>
> Thanks,
>
> Peter
>
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners branch



-- 
pascal

Re: [Vote] for the merge of Temp_RoundedCorners

[mehdi houshmand]

+1

On 12 October 2012 10:40, Peter Hancock  wrote:

> Hi,
>
> Luis Benardo and Myself have just done some clean up to the branch
> Temp_RoundedCorners.  This branch implements support for 'fox'
> extension properties  for specifying borders with rounded corners.
> Please refer to [1] and [2] for details.
>
> There is an example fo [3] that demonstrates the feature.
>
> Currently we are supporting:
>   PDF, PS and AFP outputs
>   'border-style' property with values of  'solid', 'none', 'hidden'
> and, to a limited degree, 'dashed'
>
> I would like to start a vote to merge feature branch to trunk, with my +1.
>
> Thanks,
>
> Peter
>
> [1] http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> [2] http://xmlgraphics.staging.apache.org/fop/trunk/extensions.html
> [2] examples/fo/advanced/rounded-corners.fo in the Temp_RoundedCorners
> branch
>