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
