Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG generation bug for OttavaSegment #23306

Open
eiffel31 opened this issue Jun 19, 2024 · 4 comments
Open

SVG generation bug for OttavaSegment #23306

eiffel31 opened this issue Jun 19, 2024 · 4 comments
Labels
community Issues particularly suitable for community contributors to work on

Comments

@eiffel31
Copy link

Issue type

Import/export issue

Bug description

When ottava alta or bass are used, the generated SVG file is not usable with common tools such as inkscape or openoffice.

Steps to reproduce

Create new score, add few notes with ottava, export as SVG.
Open the SVG file with inkscape: big display problems, zoom dependant
If the SVG is imported in openoffice document, the vertical part of the ottava delimiter is not displayed.

In the generated SVG file, there are 2 polylines for the ottava segments. The vertical one defines a "stroke-dasharray" with a negative value. Removing the minus sign solves the display problem.

Screenshots/Screen recordings

MuseScore display:
image

Inkscape opening the SVG file:
image
with different zoom:
image
image

Inkscape view with the minus sign removed:
image

MuseScore Version

4.3.2

Regression

I don't know

Operating system

Debian 12.5

Additional context

No response

@bkunda bkunda added the community Issues particularly suitable for community contributors to work on label Jun 21, 2024
@eiffel31
Copy link
Author

I just edited a new .svg file, here is the changes I made with a text editor in the produced svg file:
<polyline class="OttavaSegment" fill="none" stroke="#33d17a" stroke-dasharray="16.501,-6.62542" stroke-dashoffset="0" stroke-width=...
Turned into:
<polyline class="OttavaSegment" fill="none" stroke="#33d17a" stroke-dasharray="16.501,6.62542" stroke-dashoffset="0" stroke-width=...
(minus sign removal in stroke-dasharray definition)

@Jojo-Schmitz
Copy link
Contributor

Seems to be a Mu3 regression

@eiffel31
Copy link
Author

I just observed the same problem with a "dim._ _ _"
<polyline class="HairpinSegment" fill="none" stroke="#000000" stroke-dasharray="17.856,-13.599" stroke-dashoffset="0"...
The minus sign has to be removed in the stroke-dasharray definition.

@Jojo-Schmitz
Copy link
Contributor

I suspect it'll be an issue what all dashed lines

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
community Issues particularly suitable for community contributors to work on
Projects
Status: Available
Development

No branches or pull requests

3 participants