If you add to Standard.sod the following line <draw:stroke-dash draw:name="Dash" draw:style="rect" draw:dots1="1" draw:dots1-length="600%" draw:dots2="1" draw:dots2-length="600%" draw:distance="300%"/> but draw:style="circle" than the style isn't named "Dash". It doesn't matter if the draw:style is circle or rect it's always the style "Dash" only the end style of dots are different (which option is not possible in LibO). The issue is that MS Visio use draw:style="circle" by default and MSO use draw:style="rect".
The class is "XDash". https://opengrok.libreoffice.org/xref/core/include/svx/xdash.hxx https://opengrok.libreoffice.org/xref/core/svx/source/xoutdev/xattr.cxx#407 The comparison == considers all members. It is hard to search for code, which uses this. It is as least used in: https://opengrok.libreoffice.org/xref/core/svx/source/xoutdev/xattr.cxx#601 Or (I think so) for to select the dash definition in the list, which is used in the current object in: https://opengrok.libreoffice.org/xref/core/svx/source/sidebar/line/LinePropertyPanelBase.cxx?r=a6469294#810 Changing something in the implementation of == would be against the meaning of "equal". You would need a new method "ArePatternEqual()", which excludes the "eDash" member from comparison. While working on ooxml import/export of dash definitions, I have thought about the problem with round caps too: In case the definition in the document has draw:style="round", it is found in the list, if the list has an item with DashStyle_ROUND or DashStyle_ROUNDRELATIVE. That is the case, if the palette has an item with draw:style="round". So my idea had been, to extend the ooxml-compatible palette with those styles. For example have a "o_sysDot" in addition to a "sysDot". That works to get the item selected. I had tested it at that time. But the user experience would be bad, because applying such dash-definition, would not result in rounded dots and dashes. The reason is, that getting rounded dots and dashes is only possible by setting the line cap style to "Round". My idea was, to automatically set line cap style to "Round", if the user applies a style, which has draw:style="round" in its definition. That would mean a change in the UI and was therefore out-of-scope for me. But the interoperability problem with rounded dots and dashes has further problems: MS Office rounds the dots and dashes itself, so that the total length of the dot or dash is not changed. That gives e.g. a circle for a length of 100%. But LibreOffice adds the half-circles to the dots and dashes. So a length of 100% does not result in a circle, you would need a length of 1% in LO. But that will give no visible dot at all in MS Office. I don't know how MS Visio generates round dots and dashes. The way of LO is not unusual, SVG adds the caps too. In theory, ODF has the distinction between whether a dot inside a line is rounded or the line becomes round at its end. But that has never been implemented in the history of LibreOffice and would be different from MS Office. You see, I do not have a ready solution. I think, it should be discussed in the UX team.
Different Line Styles: - 11 LibO - 8 Word - 22 Visio The thing is if we have for each Line Style draw:style="rect" and draw:style="circle" no UI change is needed, but than we get to much different Line Styles. As LibO didn't respect draw:style="circle" and use ALWAYS draw:style="rect" I'm for have all styles with draw:style="rect" and in the comparision for the name don't respect draw:style"" item (cause this feature isn't available).
Created attachment 154141 [details] Document with styles from different origin + used palette (In reply to andreas_k from comment #2) > Different Line Styles: > - 11 LibO > - 8 Word > - 22 Visio Without "solid" I get LibO: As much as current palette has in UI, arbitrary in file MS Office: prstDash OOXML 10, in UI 7, arbitrary as custDash in file > The thing is if we have for each Line Style draw:style="rect" and > draw:style="circle" no UI change is needed, but than we get to much > different Line Styles. For me not the number of styles is the problem, but that a "round" style does not generate round dashes. > As LibO didn't respect draw:style="circle" It is "draw:style="round". > and use ALWAYS draw:style="rect" That is not true. If a palette has a "round" version, then LO will use this "round" version. And in case of import from OOXML, LibreOffice will generate draw:style="round" on export to ODF, if the original style has rounded dots and dashes. User defined palettes are possible since nearly 20 years now, and "round" and "rect" is published API. I cannot estimate how many documents are out, which use it, and how many palettes and macros and user defined graphic styles are in use, which rely on "round". The document has the palette name in the settings.xml. If the palette is where specified when opening the document, that palette will be loaded. > I'm for have all styles with draw:style="rect" and in the comparision for > the name don't respect draw:style"" item (cause this feature isn't > available). I prefer to have both "round" and "rect" and automatically apply linecap="round", in case the user applies a style, which has draw:style="round". That would have the advantage, that rounded dots can be applied from the sidebar without any further action needed by the user. Line caps are not available in the sidebar. Such might be combined with a checkbox to have either round or rect styles shown in the list.
(In reply to Regina Henschel from comment #1) > You see, I do not have a ready solution. I think, it should be discussed in > the UX team. We either are not compatible or introduce regressions; though I prefer the first none is our goal. No solution here. About the actual ticket, I understand it as WONTFIX. The format provides both options and we shouldn't drop one. Or how can the UX team be of service otherwise?
I'm too for WONTFIX for this bug. But discussion what behavior is wanted and expected by users and how the UI should be changed to better support the user is still needed. Please notice bug 53276, bug 127266 and bug 127348.
So closing this, bug 127348 has UX flag set.