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 188.8.131.52
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
[Information automatically included from LibreOffice]
[Information guessed from browser]
OS: Windows (All)
OS is 64bit: no
Reset User Profile?No
Created attachment 118278 [details]
Created attachment 126633 [details]
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
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
> 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
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.
"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":
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:
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