Re: [Vote] for the merge of Temp_RoundedCorners

2012-10-24 Thread 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 lmpmberna...@gmail.com 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

2012-10-23 Thread 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 peter.hanc...@gmail.com:
 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
 d...@jeremias-maerki.ch 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

2012-10-23 Thread 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 peter.hanc...@gmail.com 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

2012-10-23 Thread mehdi houshmand
+1 from me

On 23 October 2012 13:25, Clay Leeds the.webmaes...@gmail.com 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 peter.hanc...@gmail.com
 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

2012-10-23 Thread 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

2012-10-22 Thread 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

2012-10-22 Thread 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
d...@jeremias-maerki.ch 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

2012-10-22 Thread 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 vhenneb...@gmail.com 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

2012-10-22 Thread 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 peter.hanc...@gmail.comwrote:

 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

2012-10-19 Thread 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

2012-10-15 Thread 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
d...@jeremias-maerki.ch 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

2012-10-14 Thread 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

2012-10-12 Thread mehdi houshmand
+1

On 12 October 2012 10:40, Peter Hancock peter.hanc...@gmail.com 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

2012-10-12 Thread Pascal Sancho
Hi,
Very good job!
+1

2012/10/12 Peter Hancock peter.hanc...@gmail.com:
 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

2012-10-12 Thread The Web Maestro
Sounds good!

+1 from me!

Kind regards,

Web Maestro Clay
--
the.webmaes...@gmail.com - http://ourlil.com/
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 peter.hanc...@gmail.com 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

2012-10-12 Thread 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 peter.hanc...@gmail.comwrote:

 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

2012-10-12 Thread Peter Hancock
Thanks for taking the time to review this!

On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams gl...@skynav.com 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

2012-10-12 Thread 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 peter.hanc...@gmail.com wrote:

 Thanks for taking the time to review this!
 
 On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams gl...@skynav.com 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

2012-10-12 Thread 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 the.webmaes...@gmail.com:
 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 peter.hanc...@gmail.com wrote:

 Thanks for taking the time to review this!

 On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams gl...@skynav.com 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

2012-10-12 Thread The Web Maestro
On Fri, Oct 12, 2012 at 7:25 AM, Pascal Sancho psancho@gmail.com 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

2012-10-12 Thread 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  URL: http://crism.maden.org/ 
LIVE FREE: vote for Gary Johnson, Libertarian for President.
 URL: http://garyjohnson2012.com/   URL: 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

2012-10-12 Thread 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 peter.hanc...@gmail.comwrote:

 Thanks for taking the time to review this!

 On Fri, Oct 12, 2012 at 2:12 PM, Glenn Adams gl...@skynav.com 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