Bug 45822 - [PATCH] AFP Renderer: Minor border Painting Inconsistencies
Summary: [PATCH] AFP Renderer: Minor border Painting Inconsistencies
Alias: None
Product: Fop - Now in Jira
Classification: Unclassified
Component: general (show other bugs)
Version: 0.95
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: fop-dev
Depends on:
Reported: 2008-09-16 02:53 UTC by Chris Bowditch
Modified: 2012-10-30 09:28 UTC (History)
1 user (show)

Good Output (6.06 KB, application/pdf)
2008-09-16 02:53 UTC, Chris Bowditch
Bad Output (4.98 KB, application/x-afp)
2008-09-16 02:54 UTC, Chris Bowditch
proposed patch to fix bug# 45822 (37.32 KB, patch)
2010-10-25 06:04 UTC, Mehdi Houshmand
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Bowditch 2008-09-16 02:53:41 UTC
Created attachment 22592 [details]
Good Output

There are some minor problems with border painting in the AFP Renderer. These are highlighted with the layout test case block_border-style. I have attached good output from PDF and bad AFP output to illustrate the problem.
Comment 1 Chris Bowditch 2008-09-16 02:54:30 UTC
Created attachment 22593 [details]
Bad Output
Comment 2 Adrian Cumiskey 2008-09-25 01:57:02 UTC
Hi Chris,

Could you please confirm that this is a problem on 0.95 (as noted in this bug report) or with trunk or the Temp_AFPGOCAResources branch.

Comment 3 Chris Bowditch 2008-09-25 02:20:52 UTC
The problem exists in both trunk and Temp_AFPGOCAResources branch.
Comment 4 Mehdi Houshmand 2010-10-14 07:26:36 UTC
I've had a look at this issue for dashed borders ONLY. There are some inconsistencies between PS/PDF and AFP as to how these borders are drawn. There are a couple issues here:
1) For dashed borders the "dash" and the white-space between are the same length. This may seem trivial but doesn't quite look right, and isn't the same behaviour as XEP. (This applies to PS/PDF and AFP.)
2) Since PS/PDF have almost identical code (duplicated) for this function (and other methods), there really should be proper centralisation to prevent duplication. Since both PDF and PS classes inherit from BorderPainter.java, if we create a class to sandwich in between this inheritance stack it could contain utility methods such as this. So it will be: BorderPainter->AdobeBorderPainter then either PS/PDF-BorderPainter.

I'll make a slight change how both of them draw the borders (the change will make them behave the same). Currently the ratio between dash-whitespace is 1:1, this is implicitly a "magic number". I'll make a variable called DASHED_BORDER_SPACE_RATIO that make this configurable, it will also ensure that the output is the same between the various formats.
Comment 5 Mehdi Houshmand 2010-10-14 08:30:34 UTC
After a little further investigation, it appears in this particular instance the middle class "AdobeBorderPainter" is unnecessary since AFP also needs the same function to define the length of the dash. So this will be put into BorderPainter, so as all classes can inherit this method.
Comment 6 Mehdi Houshmand 2010-10-25 06:04:32 UTC
Created attachment 26209 [details]
proposed patch to fix bug# 45822

Changes made:
-Code style improvements (removed magic numbers etc...)
-Added JUnit tests for testing borders in PDF, PS and AFP
-Architectural improvements (made AFP rendering more like PS/PDF by removing anonymous class)
-Made dashed borders more resemble a "dash" rather than a "dot"
Comment 7 Glenn Adams 2012-04-07 01:41:23 UTC
resetting P2 open bugs to P3 pending further review
Comment 8 Glenn Adams 2012-04-10 14:49:19 UTC
mehdi, do you plan to commit the attached patch? thanks, g.
Comment 9 Glenn Adams 2012-04-11 03:20:28 UTC
increase priority for bugs with a patch
Comment 10 Mehdi Houshmand 2012-10-30 09:28:20 UTC
Amended and fixed in trunk@1403643.