User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.157 Safari/537.36 Build Identifier: LibreOffice 5.0.1.2 In databases arows, looking like reversed triangles and like leg of a bird are very useful, but LO doesn't support them. On screenshot both of them Reproducible: Always [Information automatically included from LibreOffice] Locale: ru Module: DrawingDocument [Information guessed from browser] OS: Windows (All) OS is 64bit: no Reset User Profile?No
Created attachment 118278 [details] screenshot
Sounds OK.
Created attachment 126633 [details] er arrows I've created ER arrows and reversed one. Review please. I plan to add two more (with unfilled circles https://d2slcw3kip6qmk.cloudfront.net/marketing/pages/chart/ER-diagram-symbols-and-meaning/ERD_notation-416x315.PNG )but current master builds display unfilled svg paths as curved
as filled* BTW this notation is called Martin / IE / Crow's foot , not ER
(In reply to Yan Pas from comment #3) > I've created ER arrows and reversed one. Review please. Great! Perhaps you want to have a look at bug 92152 (alignment is not perfect when zoomed in). The only thing I would change is the naming to allow "One" as another type of ending. Something like Martin-One, Martin-Many, Martin-OneOnly, Martin-ZeroOne, Martin-OneMany, Martin-ZeroMany. Even better we introduce groups so the plethora of line endings would be organized better.
(In reply to Yan Pas from comment #3) > I plan to add two more (with unfilled circles > https://d2slcw3kip6qmk.cloudfront.net/marketing/pages/chart/ER-diagram- > symbols-and-meaning/ERD_notation-416x315.PNG )but current master builds > display unfilled svg paths as filled (orig "closed") The current implementation always uses closed polygons, so that the line, which you see as marker is actually not a line but a fill. If you want to get markers with a hole, you have to make a closed subpath for the outer contour and a closed subpath for the inner contour. Because of the evenodd fill-rule, the inner part will become unfilled. Because of the evenodd fill-rule you need to take care about overlapping subpaths in your other markers too. Draw them with large width and look, whether you get white areas, where it should be filled. Please try your markers too in Calligra Stage (LINUX). It didn't draw the markers at the correct position in my test. The reason might be, that the actual point coordinates are about factor 100 different from the viewBox values. But to be honest, I do not know the reason of the bad drawing in the test in Calligra yet. As the current implementation only uses filled polygons, you should make this explicit in your paths and close them.
Missing keyword difficulty<foo> Missing code pointer (mandatory for a easyHack) setting to NEEDINFO
(In reply to jan iversen from comment #7) > Missing keyword difficulty<foo> > Missing code pointer (mandatory for a easyHack) > > setting to NEEDINFO Arrow heads are XML files with ending soe in instdir/share/palette or /opt/libreoffice5.2/share/palette. It's a design only task (skilldesign/topicdesign).
Thanks for adding the code pointer, please remember to add difficulty<foo> Remark, setting "needsUXEval", typically means nobody will take the task, as they will wait for the evaluation. You do not need needsUXEval to see the result, since the UX team will be added to patches containing UX elements.
Created attachment 126640 [details] CF arrows and reversed one 2nd try I've drawn two arrows with circles, now the set is complete. I've tried to open previous set in calligra - calligra fails to place two which you mentioned and stops working after selecting two other arrows (UI disappears). The paths are simple enough, I guess it's calligra's bug. Chrome displays this paths correct
Created attachment 126647 [details] Comment on CF Only One The screenshot shows the "CF Only one" applied. The line has 0.2cm width and the marker 3cm width. The green circle contains the automatic overlapping. It is not really possible to avoid, that the line width is different from the stroke width in your marker, because the marker cannot get informations about the line width. The user can influence it by choosing suitable line width and/or marker width. You should ensure, that the ratio of marker width to line width, which gives the best fit, is the same for all of the CF markers, because they are used together. The red circle shows the missing part because of evenodd fill-rule. Make your path along the outer outline, without any overlapping, that should solve the problem. Change "CF Only one" to "CF Only One". Currently all paths are treated as if they were closed. But in a further implementation that might change. If you do not close the paths, they will look different as before, in case open paths are implemented. Therefore close the paths to be on the safe side.
Created attachment 126648 [details] Comment on CF Zero One The green circle contains the overlapping. There is nothing, you can do about it, besides making the stroke of the circle very thick. But that would be ugly. The red circle contains a problem. I have searched, how others draw this symbol. It seems to me, that it is common to draw the bar with some distance to the circle, e.g http://www.vivekmchawla.com/erd-crows-foot-relationship-symbols-cheat-sheet/. You should change your symbol. Using the arc command, is really nice and easier to understand than Bezier-curves. Change "Reversed arrow" to "Reversed Arrow". The markup for the reversed arrow contains the attribute 'fill="none"'. It is not allowed for the draw:marker element and useless anyway. So remove it. I have looked again at Calligra. It seems, that Calligra has a problem with viewBox. I think, your use of viewBox is correct in relation to the specifications.
(In reply to Regina Henschel from comment #12) > Created attachment 126648 [details] > Comment on CF Zero One > > The green circle contains the overlapping. There is nothing, you can do > about it... > > The markup for the reversed arrow contains the attribute 'fill="none"'. It > is not allowed for the draw:marker element and useless anyway. So remove it. Fill="" may solve the circle issue, if allowed and possible, but I guess white is not always the appropriate color.
No, attribute fill is not allowed at all. Find the allowed attributes in the gray frame on http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416474_253892949
Created attachment 126913 [details] CF arrows and reversed one 3 I've reworked most of arrows, according to your notes. If I understood you correctly, to close the path I need to enter z at the end of each path.
High! Could you take a look pls?
Created attachment 127681 [details] File used for the screenshots In LibreOffice they look usable. In Karbon they look bad. See attached screenshots. The question is, whether we should be so friendly to consider, that Karbon is not able to draw them, and change the viewBox and the coordinates to please Karbon.
Created attachment 127682 [details] How attachment 127681 [details] looks in Karbon
Created attachment 127683 [details] How attachment 127681 [details] looks in LibreOffice
Created attachment 127686 [details] Test scenario with various CF and half arrow heads We should not aim for a good integration in Karbon but the ODF should be covered perfectly. And the question remains what tool is more precise in those regards.
More insights from Karbon: when I rotate arrows the heads are still at the end of the line, in attachment 127681 [details] it looks like a huge gap. But more interesting is the fact that the ordinary circle head is not aligned with the line end in Karbon. So my vote is to ignore Karbon, Yan Pas did a great job.
The deeper I look at it, the more I think, that there is a problem in ODF. The relevant part is section 16.40.8<draw:marker> in part 1. http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1416474_253892949 "When the marker is painted, its geometry is first mapped to the stroke start or end point as follows: [.../about scaling/...] The geometry is horizontally centered." But later on in the same section, "It is painted to the stroke so that the origin of the coordinate system of the mapped marker geometry is positioned at the start point's position." LibreOffice seems to ignore the viewBox and only uses the path and center it then. Karbon seems to consider the viewBox in some way, but from outside it is not obvious, what it does. The specification needs to be clearer on how to position the marker. Neither "geometry" nor "coordinate system of the marker geometry" is carefully defined.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b15fef02c9311e0c160906769abbf96a96e56c73 tdf#93782 Reversed line endings and tdf#92152 half-arrow heads It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Solved together with 92152 at https://gerrit.libreoffice.org/#/c/29555/ All Kudos to Yanpas!
It's a very good work It's possible to have a wavy line and a wavy arrow Thank you very much
please have a look at this Bug 103616
(In reply to Heiko Tietze from comment #24) > Solved together with 92152 at https://gerrit.libreoffice.org/#/c/29555/ > > All Kudos to Yanpas! Thanks for the update and to Yanpas, but do we still have other sources that can help us to fix this one? I wonder. Thank you again. Michelle https://andwebtraffic.com