Rounded Corners

[Peter Hancock <pe...@gmail.com>]

Hi,

I have been working on rounded border support in FOP recently and I
have come to a sticking point which I hope you can help with.

First a little info regarding my work:  I have used fox extension
attributes to prescribe the elliptic properties of the corners as
suggested in http://wiki.apache.org/xmlgraphics-fop/RoundedBorders

I have not presented my code to the FOP community yet for a few
reasons: The code is currently rather experimental in parts and breaks
some of the design considerations currently in the painters. AFP
support requires much more work: I have not implemented a solution
using GOCA yet, instead opting for IOCA rendering of the whole block.
This decision was driven by in house requirements and not as elegant
perhaps as the GOCA solution.
I am not sure whether there would be enough interest in this feature
to warrent starting a process a la the Complex Scripts feature? Should
I continue to  work in isolation and submit a patch for community
review at a time I feel it is ready?

My agenda here is to hopefully receive some help: I have come to a
sticking point with the IF format.  Currently block-like areas with a
border are represented in the form
<g>
<rect .../>
</g>
<border-rect x="" y="" width="" height=""
    before="(solid,#ff0000,10000)"
    ...
/>

The rect element is used for the background colour of the block, and
the border-rect element is used to draw the border.

Currently I have overloaded the before|after|start|end attribute to
include the ellipse radii (their meaning is not important in this
query).  When I produce a PDF from IF I am able to generate curved
borders however I have not changed rect to incorporate rounded corners
as I am not sure whether this would be deemed appropriate.  What
should I do?  Should rect be overloaded?  Should the
<g><rect/></g><border-rect/> be replaced by something else?  I am
aware that structural changes to the IF should not be taken lightly
but I also worry that overloading rect is a hacky solution.

Any thoughts welcome

Kind Regards,

Pete

Re: Rounded Corners

[Peter Hancock <pe...@gmail.com>]

Thanks for your comments Jeremias!

I will prepare a patch with some test files for the community to take
a look at.

Working from a branch would certainly ease some of the merging
headaches I have been getting.

Pete


On Thu, Sep 9, 2010 at 1:41 PM, Jeremias Maerki <de...@jeremias-maerki.ch> wrote:
> Hi Peter
>
> My comments below...
>
> On 09.09.2010 11:57:51 Peter Hancock wrote:
>> Hi,
>>
>> I have been working on rounded border support in FOP recently and I
>> have come to a sticking point which I hope you can help with.
>>
>> First a little info regarding my work:  I have used fox extension
>> attributes to prescribe the elliptic properties of the corners as
>> suggested in http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
>>
>> I have not presented my code to the FOP community yet for a few
>> reasons: The code is currently rather experimental in parts and breaks
>> some of the design considerations currently in the painters. AFP
>> support requires much more work: I have not implemented a solution
>> using GOCA yet, instead opting for IOCA rendering of the whole block.
>> This decision was driven by in house requirements and not as elegant
>> perhaps as the GOCA solution.
>
> I'm not so sure. GOCA is relatively simplistic IMO and not supported
> well enough everywhere. At least I don't like GOCA at all and prefer a
> bitmap image for a fixed-resolution environment like AFP. But not
> everyone thinks like that. The common ground is always page segments. I
> learned that when rounded borders are required in the AFP environment,
> that people often create pre-generated page segments (IOCA in the end)
> to paint the borders (especially the rounded ones) in exactly the way
> they need it. The advantage of bitmaps in AFP is:
> since you know exactly the resolution the printer will work with, you
> can produce bitmaps tailored exactly for this resolution with a high
> quality tool (Java2D).
>
>> I am not sure whether there would be enough interest in this feature
>> to warrent starting a process a la the Complex Scripts feature? Should
>> I continue to  work in isolation and submit a patch for community
>> review at a time I feel it is ready?
>
> First, I think there is interest in this feature. I remember multiple
> inquiries on our user list. It is in the works for CSS3. It was in the
> XSL 2.0 requirements, but surprisingly not in the first working draft.
> Still, some commercial implementations have extensions for this.
>
> Second, if you find yourself in a tight corner, it makes sense to reach
> out. You do that now and I've had to do it this week, too. So, why not
> put this in a branch where people can look at it and maybe help? Well,
> we do have to be careful not to create too many branches which never get
> finished, but more often that not they are. For example, my color
> branches are almost ready to be merged back into the trunks. Just a
> final effort left.
>
>> My agenda here is to hopefully receive some help: I have come to a
>> sticking point with the IF format.  Currently block-like areas with a
>> border are represented in the form
>> <g>
>> <rect .../>
>> </g>
>> <border-rect x="" y="" width="" height=""
>>     before="(solid,#ff0000,10000)"
>>     ...
>> />
>>
>> The rect element is used for the background colour of the block, and
>> the border-rect element is used to draw the border.
>>
>> Currently I have overloaded the before|after|start|end attribute to
>> include the ellipse radii (their meaning is not important in this
>> query).  When I produce a PDF from IF I am able to generate curved
>> borders however I have not changed rect to incorporate rounded corners
>> as I am not sure whether this would be deemed appropriate.  What
>> should I do?  Should rect be overloaded?  Should the
>> <g><rect/></g><border-rect/> be replaced by something else?  I am
>> aware that structural changes to the IF should not be taken lightly
>> but I also worry that overloading rect is a hacky solution.
>
> IMO, the IF has to grow with the requirements, be that complex scripts
> or rounded borders. Where possible we should be backwards-compatible.
> Implementations will simply ignore what they don't support. Let's design
> it on the Wiki page and bring it to a point where we're all happy.
>
> I suspect you mention rect and border-rect because, at the moment, they
> are used independently. And they may need to be specified together for
> rounded borders? IMO, border-rect doesn't have to stay a single-element
> with no content. If it unclutters the attributes, a defined set of child
> elements may be totally OK.
>
> After all, we get feedback every now and then that the PDF borders don't
> look to good in Adobe Acrobat Reader due to anti-aliasing side-effects.
> Maybe we can even optimize a bit in this direction, namely to paint more
> than one border segment at a time.
>
> My suggestion is that you bring your code to a presentable state and
> submit it as a patch and I can then look into it with you. I'm pretty
> sure this is important enough for your employer so I can get a few hours
> to help you.
>
>
> Jeremias Maerki
>
>

Re: Rounded Corners

[Jeremias Maerki <de...@jeremias-maerki.ch>]

Hi Peter

My comments below...

On 09.09.2010 11:57:51 Peter Hancock wrote:
> Hi,
> 
> I have been working on rounded border support in FOP recently and I
> have come to a sticking point which I hope you can help with.
> 
> First a little info regarding my work:  I have used fox extension
> attributes to prescribe the elliptic properties of the corners as
> suggested in http://wiki.apache.org/xmlgraphics-fop/RoundedBorders
> 
> I have not presented my code to the FOP community yet for a few
> reasons: The code is currently rather experimental in parts and breaks
> some of the design considerations currently in the painters. AFP
> support requires much more work: I have not implemented a solution
> using GOCA yet, instead opting for IOCA rendering of the whole block.
> This decision was driven by in house requirements and not as elegant
> perhaps as the GOCA solution.

I'm not so sure. GOCA is relatively simplistic IMO and not supported
well enough everywhere. At least I don't like GOCA at all and prefer a
bitmap image for a fixed-resolution environment like AFP. But not
everyone thinks like that. The common ground is always page segments. I
learned that when rounded borders are required in the AFP environment,
that people often create pre-generated page segments (IOCA in the end)
to paint the borders (especially the rounded ones) in exactly the way
they need it. The advantage of bitmaps in AFP is:
since you know exactly the resolution the printer will work with, you
can produce bitmaps tailored exactly for this resolution with a high
quality tool (Java2D).

> I am not sure whether there would be enough interest in this feature
> to warrent starting a process a la the Complex Scripts feature? Should
> I continue to  work in isolation and submit a patch for community
> review at a time I feel it is ready?

First, I think there is interest in this feature. I remember multiple
inquiries on our user list. It is in the works for CSS3. It was in the
XSL 2.0 requirements, but surprisingly not in the first working draft.
Still, some commercial implementations have extensions for this.

Second, if you find yourself in a tight corner, it makes sense to reach
out. You do that now and I've had to do it this week, too. So, why not
put this in a branch where people can look at it and maybe help? Well,
we do have to be careful not to create too many branches which never get
finished, but more often that not they are. For example, my color
branches are almost ready to be merged back into the trunks. Just a
final effort left.

> My agenda here is to hopefully receive some help: I have come to a
> sticking point with the IF format.  Currently block-like areas with a
> border are represented in the form
> <g>
> <rect .../>
> </g>
> <border-rect x="" y="" width="" height=""
>     before="(solid,#ff0000,10000)"
>     ...
> />
> 
> The rect element is used for the background colour of the block, and
> the border-rect element is used to draw the border.
> 
> Currently I have overloaded the before|after|start|end attribute to
> include the ellipse radii (their meaning is not important in this
> query).  When I produce a PDF from IF I am able to generate curved
> borders however I have not changed rect to incorporate rounded corners
> as I am not sure whether this would be deemed appropriate.  What
> should I do?  Should rect be overloaded?  Should the
> <g><rect/></g><border-rect/> be replaced by something else?  I am
> aware that structural changes to the IF should not be taken lightly
> but I also worry that overloading rect is a hacky solution.

IMO, the IF has to grow with the requirements, be that complex scripts
or rounded borders. Where possible we should be backwards-compatible.
Implementations will simply ignore what they don't support. Let's design
it on the Wiki page and bring it to a point where we're all happy.

I suspect you mention rect and border-rect because, at the moment, they
are used independently. And they may need to be specified together for
rounded borders? IMO, border-rect doesn't have to stay a single-element
with no content. If it unclutters the attributes, a defined set of child
elements may be totally OK.

After all, we get feedback every now and then that the PDF borders don't
look to good in Adobe Acrobat Reader due to anti-aliasing side-effects.
Maybe we can even optimize a bit in this direction, namely to paint more
than one border segment at a time.

My suggestion is that you bring your code to a presentable state and
submit it as a patch and I can then look into it with you. I'm pretty
sure this is important enough for your employer so I can get a few hours
to help you.


Jeremias Maerki