Because AFP doesn't use floating point numbers to define x,y co-ordinates (like PDF and PS) there are rounding error that cause border inconsistencies. However, because (I presume) most borders are very thin, they are barely visible. This issue became apparent when fixing Bug# 15368. When using dashed borders, this issue is much more visible since it manifests in non-squared borders i.e. there are white-spaces in corners rather than proper squared borders.
resetting P2 open bugs to P3 pending further review
please provide a test input FO file and an image of currently produced AFP (for those of us who don't have access to an AFP output device
This doesn't require a single FO to demonstrate the point, it was more of a marker for illustrating a flaw in how the AFP rendering works. The AFP painter does a lot of arithmetic and the floating-point -> integer conversion happens too early, magnifying rounding errors. As always, this just needs time... Sorry if that isn't very helpful
(In reply to comment #3) > This doesn't require a single FO to demonstrate the point, it was more of a > marker for illustrating a flaw in how the AFP rendering works. The AFP painter > does a lot of arithmetic and the floating-point -> integer conversion happens > too early, magnifying rounding errors. > > As always, this just needs time... Sorry if that isn't very helpful when someone gets around to looking at this, it will be important to have a test file that demonstrates the problem; i don't see why you can't construct such a test file
Well, because I could append the original FO but that would only show a subset of the problem. The issue is a systemic one, concerning how floating point numbers are handled, or not handled as the case may be in some cases, in the AFP rendering system. Coincidentally r1311638, which I've just applied also addresses one of many symptoms of this problem. But this issue isn't present and wouldn't have been noticed when this problem was initially recognised. If you are demanding an FO; playing with Bug#45822 would be sufficient, but again this is only subset of the symptoms.
(In reply to comment #5) > Well, because I could append the original FO but that would only show a subset > of the problem. The issue is a systemic one, concerning how floating point > numbers are handled, or not handled as the case may be in some cases, in the > AFP rendering system. > > Coincidentally r1311638, which I've just applied also addresses one of many > symptoms of this problem. But this issue isn't present and wouldn't have been > noticed when this problem was initially recognised. If you are demanding an FO; > playing with Bug#45822 would be sufficient, but again this is only subset of > the symptoms. yes, i'm asking for a minimal input FO, an output PDF, and any relevant console log;
Created attachment 28791 [details] test *.fo file
Created attachment 28792 [details] test *.afp output