Thanks to dmitrio95, mirabilos, and Jojo for chiming in on the spatium
issue. I have created a document to consolidate all the issues
surrounding these problems, and uploaded it in this comment on the
spatium issue page:
https://musescore.org/en/node/278889#comment-873838
The doc is not 100% complete, but it captures all the related issues I
have found, and reviews/proposes integrated solutions for them all.
There are also open questions raised in the document.
Thanks for listening. I still feel strongly that this is a critical set
of issues that should be included in the upcoming 3.0 beta. I have not
seen any timeline for that beta release, but I am working to deliver
some solution this week, if possible. Further feedback is much appreciated.
On 11/29/2018 10:27 AM, Sideways Skullfinger wrote:
This is a set of issues driven by a core problem inside MuseScore. I
have attempted to fix this as part of a larger PR over 2 years ago,
but it was rejected at the time. As the beta release of 3.0 nears, I
want to try once again to convince the community & decision makers of
the importance of this issue, so that I might find agreement on how to
fix it. I am willing to write the code and submit the PR(s).
The core problem is the file format, unfortunately. The page settings
data is stored in three different units: inches, staff spaces, and
millimeters. Inches are for the page size and margins, staff spaces
are for most everything else, and millimeters are for the spatium
itself. This arrangement inevitably causes rounding errors when
converting units. It also creates too many situations where units
must be converted. The worst rounding error is in the spatium itself,
and that error happens every time you switch from millimeters to
inches in the page settings dialog. Once it has been rounded, you
must edit the XML to reset it, otherwise the rounding just compounds
every time you switch between inches and mm.
The solution is to store data in only one kind of unit, not three.
This has various downstream impacts, and is related to several open
issues from users other than myself. For me it is a critical issue
because I do SVG exports, and rounding the spatium means that the SVG
export automatically scales everything to the non-standard spatium
value via full matrix transforms. It's ugly and it bloats the
exported file. Not to mention the incorrectness of the scaling itself
- I never change the staff space value in the dialog.
I am seeking feedback on my solution to this problem, and some
guidance. This is partly because of my prior rejection, but mostly
because the code has changed in the 2 and a half years since I first
raised this issue, and it is an issue that might have downstream
consequences I might not see immediately. Unfortunately is is a core
set of changes and there is substantial detail to understand in order
to review the changes. I am hoping at least a couple of you can
follow along and assist with the design of this new code.
I have some issues open and some forum discussions in various states
on musescore.org. It's probably best to have the discussion and
reviews there instead of the mailing list, but either way is fine with
me. I'm already making some changes in a branch as I muddle through
this, and I'm having to make some decisions that could use some
feedback. The best two places to start are these two issues I've posted:
https://musescore.org/en/node/278887
https://musescore.org/en/node/278889
The first one is about the UI for these units, which is 100% tangled
up in this overall issue.
Thanks for listening!
__
Sideways
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
_______________________________________________
Mscore-developer mailing list
Mscore-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mscore-developer
