Bug 127348 - Improve use of line dash definitions with rounded dots/dashes
Summary: Improve use of line dash definitions with rounded dots/dashes
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.4.0.0.alpha1+
Hardware: x86-64 (AMD64) Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Shapes-Line
  Show dependency treegraph
 
Reported: 2019-09-04 22:09 UTC by Regina Henschel
Modified: 2021-04-30 14:50 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
Mockup (45.03 KB, image/png)
2020-12-14 10:18 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Regina Henschel 2019-09-04 22:09:02 UTC
I write this as issue, because first the goal has to be clear before any changes in code are down.
----

The ODF standard defines the element <draw:stroke-dash>. This has the attributes: name, display-name, style, dots1, dots1-length, dots2, dots2-length, distance. For the attribute 'style' the values 'round' and 'rect' are possible. The lengths can be absolute or a percentage relative to the line width. The line dash definitions in a foo.sod palette are written using the ODF standard.

This would fit perfectly to our API structure 'LineDash'. This has the components Style, Dots, DotLen, Dashes, DashLen, Distance where Style is a com::sun::star::drawing::DashStyle. This is an enum with the values RECT, ROUND, RECTRELATIVE, ROUNDRELATIVE.

But LibreOfffice determines whether a dash is rounded or square/flat not from DashStyle, but from the LineCap line property. LibreOffice is not alone in this, but OOXML and SVG also act in this way. Nevertheless the core works with the structure 'LineDash'.

This leads to the following problems:

A) If the user applies a line dash definition that contains style="round" from a palette, the dashes are not rounded. That prevents to provide a line style with round points in the sidebar, for example. The sidebar has no section to set the line cap.

B) If in a file only the stroke-dash definition contains the attribute draw:style="round", but the object does not have the line property svg:stroke-linecap="round", then the dashes are not rounded (tdf#53276).

C) If an object has the line property cap="round", but the stroke-dash definition in the current palette has draw:style="rect", the palette entry is not found and is not available in the dialogs, even if all other properties fit. Exception is our own palette standard.sod.

How can the two concepts LineCap vs LineDash.Style be brought together?

My ideas to improve the situation:

If the user assigns a dash definition with draw:style="round" to an object via sidebar, the line property linecap="round" is automatically set. The preview in the sidebar shows the style as if linecap="round" is already set.

The line style dialog is changed, so that it sets the linecap to "round", if a definition with draw:style="round" is selected, and disables the linecap drop-down for such definitions. That would not effect our standard.sod palette, because it has only definitions with draw:style="rect".

Keep the possibility to set a round cap for styles in standard.sod, although our standard.sod has only draw:style="rect" definitions. But an author of a custom palette has to provide all definitions in a "rect" and in a "round" version, so that they will be found, regardless of whether the user has set linecap to "round" or "square"/"flat". To keep the list of styles short for custom palettes, the dialog can have an option to show either styles with "round" or "rect" in case of custom palettes. But such would be a question of design.
Comment 1 Heiko Tietze 2019-09-19 13:17:05 UTC
needsUX needs CC to ux-advice. Good topic for next week's meeting.
Comment 2 Cor Nouws 2019-09-24 19:52:21 UTC
Thanks Regina. I see the advantages of the balanced proposal.
Comment 3 Heiko Tietze 2019-09-26 06:44:47 UTC
(In reply to Regina Henschel from comment #0)
> But LibreOfffice determines whether a dash is rounded or square/flat not
> from DashStyle, but from the LineCap line property. LibreOffice is not alone
> in this, but OOXML and SVG also act in this way. 

Why not change this and follow the format definition? Might lead to some regression and we may need some tweaks but it sounds like the correct approach.
Comment 4 Regina Henschel 2020-09-14 15:44:35 UTC
In the meantime we have ODF 1.3 and there it is clarified, that the settings at the linecap attribute of a line have precedence over round/rect in the <draw:stroke-dash> element and the setting in linecap is not only applied to the end of lines, but to the dashes too.
Comment 5 Heiko Tietze 2020-09-15 10:51:52 UTC
(In reply to Regina Henschel from comment #4)
> the setting in linecap is not only applied to
> the end of lines, but to the dashes too.

So no need for input from UX. Do we need the ticket now at all?
Comment 6 Regina Henschel 2020-09-15 11:24:29 UTC
(In reply to Heiko Tietze from comment #5)
> So no need for input from UX. Do we need the ticket now at all?

We still need this ticket. Please read the problems and my proposals in the bug description. It contains a lot, where UX should be involved.
Comment 7 Heiko Tietze 2020-12-14 10:18:25 UTC
Created attachment 168143 [details]
Mockup

Discussed this topic with Regina. Issue is that "Line Styles" defines what is shown in Line > Style but misses the Cap Style property. Solution is to "duplicate" the cap style option into the line style tab. And ideally we make this tab an extra dialog (same for arrow style). The dialogs could open per main menu but better also via button next to the dropdown. Rough mockup attached.