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 <[email protected]> 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 > >
