https://issues.apache.org/bugzilla/show_bug.cgi?id=49913
--- Comment #3 from Peter Hancock <[email protected]> 2010-09-10 09:43:50 EDT --- Development notes: Temporary System properties During development I have found it useful to switch between different execution paths (for performance testing, implementation comparisons etc) by using System properties. I have decided to include them with the patch with the intent to remove them before any trunk integration. The properties are: fop.round-corners = true|false (default true) Seting this to false turns off the rounded-corner code which I find useful for debugging and performance testing fop.round-corners.corner-join-style=css When adjacent borders differ in colour the joining line can be defined in a few ways (see the attached doc/wiki - when updated). I decided not to implement the css3 recommendation by default but I have included the option for discussion. fop.round-corners.afp=seperate|all-in-one(default) I have implemented rounded corners in AFP using IOCA: the corners are generated as rasters using Java2D which is then converted to an IOCA Image Object. These are cached at the document level in the AFP. The seperate setting instructs FOP to create 4 images for each corner which are overlayed over the original bordered block. Due to a printing descrepancy between the IOCA corner and the PTOCA rectangular border and ackground area, I have also implemented the functionality to create the entire rounded area as an IOCA image (all-in-one), trading file size for acceptable prining results. Ideally the reason for the printing descrepancy can be resolved and the 'all-in-one' functionality removed. Considerations Currently the abstraction shared by the AFP border painting code and the PDF/PS border painting is high level, reflecting the marked differences between the renderers. It may be possible to share a bit more between the two processes with a bit of refactoring. The color mode and resolution of rounded borders in AFP is controlled with the fop.xconf. A bug with high resolution images may be incountedred however this is not rc-specific and fixed in https://issues.apache.org/bugzilla/show_bug.cgi?id=49893 Currently some of the methods in (PDF|PS)BorderPainter have parameter lists that are currently too long. I intend to try and encapsulate border properties in a better way that reduces parameter passing and perhaps performs some of the funcitonality in a more OO way: currently the BorderPainters are passing around these dumb parameters ins a procedural manner to perform the drawing logis. A smatter representation of the borders might 'draw themselves' etc. -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
