--- Comment #3 from Peter Hancock <> 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

    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

    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.


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

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:
------- You are receiving this mail because: -------
You are the assignee for the bug.

Reply via email to