there are now 11 line styles available by default. There is e.g. Ultrafine Dashed and Dashed, but Dashed is finer than Ultrafine Dashed? In addition I would rearrange the list - Continuous - Dot Ultrafine - Dot Fine - Dot - Dot Long - Dash Ultrafine - Dash Fine - Dash - Dash Long - Dash - Dot - Dash Long - Dot - Dash - Dot - Dot - Dash Long - Dot - Dot - Dash Long - Dash
Created attachment 153083 [details] LineStyle in 6.3 what is Line Style 9?
Examples: https://matplotlib.org/gallery/lines_bars_and_markers/line_styles_reference.html https://docs.roguewave.com/visualization/views/6.1/views.html#page/UserManuals/graphicresources.04.07.html http://reference1.mapinfo.com/software/spectrum/lim/8_0/developerguide/Spatial/source/Development/styles/patterncodes/patterncodes_line.html https://www.wavemetrics.com/products/igorpro/creatinggraphs/2dgraphs/linegraphs https://en.wikipedia.org/wiki/Engineering_drawing https://heasarc.gsfc.nasa.gov/docs/xanadu/ximage/pgplot/quickref.html
Like in bug 126648 I don't think a sorted list is too much beneficial. But also open for other opinions.
in standard.sod where the line styles were defined, there is draw:style="rect" are there other options possible like, circle, diamond, ... I already test circle, diamond but didn't work.
You are aware, that the names will be localized? Does sorting makes sense? You are aware, that there exists draw:name and draw:display-name attributes? In case you decide to alter the names, then please add the information, whether dash length and spacing will adapt to the line width. The suffix (var) for those styles still exists for some names in the source, but is somewhere stripped (yet another bug). Using [var] would work. And please make names, that really describe the content, because dots and dashes are hard to distinguish in the preview. Remove duplicate styles in the palette. Just created bug 126736. Before that is not fixed, new line styles cannot be made in the UI, but you need to edit the palette. Fortunately it is plain XML and you likely want to work on the source anyway. (In reply to andreas_k from comment #4) > in standard.sod where the line styles were defined, there is > draw:style="rect" are there other options possible like, circle, diamond, ... > > I already test circle, diamond but didn't work. No, already attribute values "rect" and "round" are allowed. But I do not find an implementation for draw:style="round", although the enum DashStyle with values ROUND and ROUNDRELATIVE is published API.
thanks for the feedback as always very usefull for me. I will have a look at border line style to and have a look if it's really needed to change the line style. yes the var styles are good but at least this information should be visible somewhere in the name to see that this styles depend on the line width. do you know what Line Style 9 is, regina?
Is there an big difference between boarder style and linestyle from an UX perspective? Can we have the same boarder line styles also for draw line styles? Cause in general the boarder line styles will work also for drawing line styles. I would add only some more for drawing but use the same label if the boarder and drawing line styles are the same.
(In reply to andreas_k from comment #7) > Is there an big difference between boarder style and linestyle from an UX > perspective? Don't think so. But I'm afraid of bloating the styles since borders have these double lines (which is used for financial tables), for example. Right now we do not need to scroll border or line styles and the dropdown also does not expand to the bottom of the screen.
(In reply to Heiko Tietze from comment #8) > Don't think so. But I'm afraid of bloating the styles since borders have > these double lines (which is used for financial tables), for example. Right > now we do not need to scroll border or line styles and the dropdown also > does not expand to the bottom of the screen. boarder style: - have the styles that MSO has line styles: - have the boarder styles (I'm not sure if double lines is possible as line style, would be usefull for some flowchart types where the connector line style is =) - have line styles that will be needed for flowcharts, ... - have line styles that chart plot apps has (R, gnuplot, ...) Now the label of boarder styles and line styles are different and I'm for sync everything a bit. And yes as less styles as needed.
(In reply to andreas_k from comment #7) > Is there an big difference between boarder style and linestyle from an UX > perspective? Can we have the same boarder line styles also for draw line > styles? > > Cause in general the boarder line styles will work also for drawing line > styles. I would add only some more for drawing but use the same label if the > boarder and drawing line styles are the same. There are large differences between line style and border style. Border styles are written to ODF file as fo:border attribute. The definition refers to XSL and that refers to https://www.w3.org/TR/CSS2/box.html#value-def-border-style. Styles are defined by keywords: none, hidden, dotted, dashed, solid, double, groove, ridge, inset, outset. OOXML uses keywords (27!) too, see section 18.18.3 ST_BorderStyle (Border Line Styles) in ISO/IEC 29500-1:2016(E). These styles are applicable to text portions, tables and pages. The line styles are written to ODF as <draw:stroke-dash> element. Graphical objects have the styling aspects "stroke" for their lines and "fill" for their area. Line styles format the "stroke". They are only applicable to objects, which have a "stroke". Similar in OOXML, there it is the custDash or prstDash element. The OOXML preset styles are labeled: solid, dot, dash, lgDash, dashDot, lgDashDot, lgDashDotDot, sysDash, sysDot, sysDashDot and sysDashDotDot in file format (not in UI). Their metric is illustrated in L.4.8.5.2 Line Dash Properties in the OOXML spec. So "border line styles" never work for "drawing line styles". Of cause you will have styles in both systems, that look similar.
*** Bug 58218 has been marked as a duplicate of this bug. ***
I think, this problem should be postponed until bug 126741 and bug 126746 are solved. @Andreas, you might want to get my zip-container attachment to bug 126741. It contains some information about line styles and some example files.
(In reply to andreas_k from comment #1) > what is Line Style 9? I don't know the origin of "Line Style 9" but these styles are explicitly treated in source, see https://opengrok.libreoffice.org/xref/core/oox/source/export/drawingml.cxx?r=3feaff84#911 and following lines.
Created attachment 153756 [details] line style palette with OOXML preset line styles I have investigated a little bit in regard to line style palettes. The palette standard.sod was delivered already in StarOffice 5.2, however in binary format. OOo1.1.5 is able to read the old file format and convert it to XML format. The content has not changed compared to our version. The other file style.sod seems to be a dummy. There had been localized versions with really different styles. Now this palette is useless. It has 6 similar styles, were "2" and "3" are identical, and "4", "5" and "6" are identical. I suggest to remove this file. I suggest to use the attached file as ersatz. It contains the line styles as they are defined in the OOXML standard, transformed to ODF format. This could be done independently of all the other improvements needed for line styles. Andreas, I didn't want to get in your way. But I needed the styles for test documents for my current developer work on the import/export filters. And so I thought, if I have already created the file, I can make it available.
(In reply to Regina Henschel from comment #14) > Created attachment 153756 [details] > line style palette with OOXML preset line styles Thanks for your patch, Regina. Removing needsUX as there is work ongoing. Hopefully, Andreas finds the time to submit.
The line styles get already updated, can this bug be closed? Regina?
*** Bug 131322 has been marked as a duplicate of this bug. ***
(In reply to Heiko Tietze from comment #17) > *** Bug 131322 has been marked as a duplicate of this bug. *** => Component "LibreOffice"
Dear andreas_k, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug