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 <d...@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
>
>

Reply via email to