Render problems with the pdf.Arc() function #282
Comments
These results surprise me too. I'll look into this. |
I think the angle values used in the As an expedient in your particular example, eliminating one of the calls to |
Thanks for looking into this. The example is primary made to illustrate the alignment problem. In my actual use case, I am using the first parameter of I would be grateful if we could bump up the resolution because the parts have to be machine readable thus require high precision... |
I bumped the precision of all floats stored by gofpdf from 5 to 9 and there was no discernible difference with the arc misalignment that you demonstrate. Since everything is smooth when one line width is used, I am inclined to think that the misalignment derives from a slight influence of line width in the way arc endpoints are calculated. I'll think about how this could be verified and, if it can be shown to be a problem, how it can be corrected. |
Hi, is there a way to support you with this issue...? - I do not know the inner workings of the library but if there is something I can help you with - I do what I can... |
Thanks for the offer, @tindli. I haven't been able to figure out the source of this problem. One thing I have not investigated is whether the aberrations in the generated output are due to way a PDF renderer calculates arc angles with lines of varying thickness. Depending on the rendering engine's algorithm, the end point of an arc might only be approximately radial. (That is, the outside of the line might end at a different angle than the inside of the line.) In this case, the ending position would depend on where within the line the stop angle is applied. One approach would be to write the absolute smallest PDF with gofpdf that demonstrates the problem. See if you can come up with a much simpler example with just two arcs of different thickness and no loops. This generated PDF could then be compared with the documents generated by other PDF packages. |
@tindli, once you write a simplified demonstration of the problem, you could see if documents made with jsPDF (which supports arcs) have or do not have the alignment problem that you found. |
@jung-kurt Sorry for the late response. Was quite busy... Now some of my results:
I am not sure why this happens, and I am not sure why the function produces different results (using start+end+rotation vs. rotation only). Because jsPDF produces similar results, the problem might not be within gofpdf... For my use case, I can probably go with the method described on step 3 (although I have to verify that further)... Nevertheless, I am not really sure what to do with the issue... |
Thanks for the report, @tindli. These are really interesting findings. |
I need to create some very fine details (in the mm range) on certain parts of my PDF based on the pdf.Arc() function.
I found that if I create circle segments with the Arc() function using two different rx, ry settings, the endings of the segments do not align.
To illustrate the effect, I created the demo program (please see below), zoomed in with my PDF-viewer, and exported the image as a png. A few of the bad parts are encircled by a red circle. Some segments do align, like the one thats encircled with a green circle.
Because gofpdf creates the PDF as vector graphics, I expected the arc endings to align - independent of the size of the element.
I think that the effects seen within the red circles should not be there...
The text was updated successfully, but these errors were encountered: