GNOME Bugzilla – Bug 475168
DiaRenderer::draw_*_with_arrows() should not change object data
Last modified: 2019-03-20 11:33:13 UTC
All the draw_*_with_arrows() functions are adjusting the start- and end-point of the lines/curves/beziers. This is problematic from the design point of view because the movements as well as the arrows have an impact on the bounding box, which is supposed to be calculated by the object itself. IMO the right way to fix this would be to remove all these draw_*_with_arrows functions from the renderer interface. Another option could be to better encapsulate the algorithm of point movements to make it useable from draw_*_with_arrows as well as DiaObject::update_data() where the bounding box calculation is supposed to happen.
Created attachment 95218 [details] bezier with same control points but different bbox The attached PNG shows the mismatch between calculated an real bounding box. Green the bezier w/o arrows -> bounding box is correct. Red: the arrow head as well as the curve itself do not fit in the bounding box. It seems as if the bbox calculation is done for the old arrow placement (at the end of the line). To have visible bounding boxes set in your .dia/preferences file <dia:boolean role="render_bounding_boxes"> <dia:attribute name="booleanvalue"> <dia:boolean val="true"/> </dia:attribute> </dia:boolean>
This bug is part of the issue at bug #145575 because almost all of the exporters depend on correct extents (calculated from bounding boxes)
Removing the draw_*_with_arrows would be a major step backwards. The move of the endpoints is a lot more intuitive than just not rendering that far, so making the interface for arrow adjustment available for BBox calculations would be much preferable.
Sorry for not being clear enough, the full sentence should have been: "IMO the right way to fix this would be to remove all these draw_*_with_arrows functions from the renderer interface" and implement that functionality on the object side. The renderer is supposed to render, not changing the layout of the objects. Having the facility to adapt the line objects to their (arrow-)endings is highly appreciated.
That makes a lot more sense. The draw_*_with_arrows functions were made thinking that some renderers (e.g. ODF, XFIG, VDX) would rather make a real arrow in their own format than a line with a couple extra lines somehow hanging on. Note that it's not the draw_*_with_arrows functions that take care of the midpoint-related movement, so they don't actually alter the objects -- how could they, they don't know the objects.
I see the problem in the beziers only now. Can't think of a good way to generally handle this in the renderer alone. Back to the ol' thinking board.
While I completely agree with comment #5 I don't get comment #6. Part of the objects point adaption is already done in the object (the mid-point movement). To me it looks logical to do also the arrow related movements within the object and calculate the full bounding box there from the arrow box plus the modified line points. The draw_*_with_arrows function would then take the modified line points plus the calculated arrow end points. And the render can just render these. without modifying any point. BTW: the bounding box problem is at least also visible for the arc object, thus giving "arc traces" like the beziergon traces from bug #300055
The errors are mostly gone, the implementaiton could still be improved. But that's not a bug any longer.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/dia/issues/208.