Points / Pixels as Page Layout Units
Full details of the code changes are in the attached doc.
I have a branch that implements all these changes and is current with today's master, here (comparison page):
https://github.com/musescore/MuseScore/compare/master...sidewayss:PtPx
The one issue with this branch is that when you close and reopen MuseScore, a file with Points/Pixels as the Page Layout units opens with Millimeters as the Page Layout units. So Points/Pixels doesn't save properly with the file. Though if I close and open the file within a single MuseScore session it works properly. Somehow closing and reopening MuseScore is causing this.
Justification
I am using MuseScore to create animated SVG exports. The exported files are designed to be placed directly in an HTML page or opened by a browser without an HTML wrapper at all.
- The native units of HTML and SVG are pixels
- HTML and SVG are constantly increasing in popularity and usage, globally.
- For my purposes, as I imagine for many future applications, I want to size my scores in pixels, not inches or millimeters. Inches and millimeters are for printing on physical paper. Many of my scores are designed specifically for display on a screen, not to be printed.
- Fortunately, MuseScore recently aligned its core units, Points, with Pixels. Ever since the 72dpi changes, points and pixels are equivalent in MuseScore. This means that adding Points and Pixels as a combined type of Page Layout unit makes great sense.
- Not only does it make sense to add the user functionality, but in doing so I have eliminated unnecessary unit conversions in the code, and simplified the usage of Page Layout units. Currently Page Layout units are stored internally in Inches, and then converted into all the other units on demand. Making points/pixels the core units means that Millimeters and Inches are treated the same way, as converted unit types for printing/exporting only. The result is fewer, simpler conversions.
Thankfully, the file where this causes the most change has not been modified much since 2.3: pagesettings.cpp
| Attachment | Size |
|---|---|
| MuseScore_pt-px.pdf | 87.66 KB |
Comments
I believe the capitalisation changes are wrong, not what we use elsewhere.
In reply to I believe the capitalisation by Jojo-Schmitz
Capitalization is easily reverted, but this is more correct English/UI standard. In English, every word in a title is capitalized, optionally you can not capitalize articles, like "a" and "the", and some prepositions, like "for" and "in". This style is generally observed in UI titles/labels/headings.
But in the end it's up to you guys. This is the least important part of this request, and easily reverted.
In reply to Capitalization is easily by sideways
Yes, in a title, but "Staff space" is not a title nor heading, and for lables we use Sentence case, hence its the spelling as shown here. But yes, this part is of the least importance here.
In reply to Yes, in a title, but "Staff by Jojo-Schmitz
A difference of opinion. I consider UI labels to be titles: they are the title of the field.
Look at many applications and you'll see this difference of opinion in action. I find that most Windows applications agree with my point of view. But that's just Windows, and MuseScore seems more oriented towards the Unix style of UI, which is definitely different.
Do you like the re-wording and hyphenation changes? It makes things clearer and more consistent IMO. But again, easily reverted if you don't like it.
I am much more concerned about the technical side of merging this code, and whether there are things in my code that should be done differently. The unitSuffixes const array, for example, generates a lot of warnings because it is in mscore.h - it should probably be moved to page.h or someplace else.
I'm concerned about the fact that it touches 21 files. I'm also concerned about a few specific questions in the document I posted. I'm also concerned about the way this new option is saved and restored in the .msc file.
In reply to A difference of opinion. I by sideways
Just look at other MuseScore dialogs.
In reply to Just look at other MuseScore by Jojo-Schmitz
I just updated my branch on github with Sentence case labels in pagesettings.ui. see here:
https://github.com/sidewayss/MuseScore/tree/PtPx
The screen capture is now updated in the attached PDF file.
I've attached the .odt (open office writer) file too, in case anyone wants to respond inline in the document.
Any way to prioritize this feature request or get a sense of when it might be plausible to seriously review it? I ask because the scope of the changes here, 21 files, makes my personal git workflow a nightmare, especially now that I'm on the bleeding edge with this Qt 5.6 upgrade.
I realize that this same fact makes it more time-consuming to review, and thus more difficult to merge into the master code. Is there anything I can do to help the process along?
The primary thing I can think of is fixing the one outstanding issue I have, saving the setting and restoring the radio button in the dialog properly. I'll work on that.
I also realize that one user with git difficulties is not a reason to introduce a new feature. I really do believe that this feature has general-purpose merit, as explained in the original posting. Thanks.
In reply to Any way to prioritize this by sideways
Realistically, best thing I can think to do to help significant changes get meregd would be to first help fix the many regressions in the current master due to the big layout change. My guess is that stabilizing the master would be top priority. Seems having that happening before the Google Summer of Code work gets underway would be really really nice.
In reply to Realistically, best thing I by Marc Sabatella
Once again, please excuse my ignorance, but I'm not clear on the process for "fixing regressions" here. I looked around the site and didn't find any instructions in the Developer's Handbook either. Is this explained somewhere? And how to add "regressions", as I can certainly contribute to the SVG regressions, as discussed on the mailing list. I'm putting stuff in quotes because I recognize the words, but I am not familiar with the way they are being used here.
Thanks.
In reply to Once again, please excuse my by sideways
Newly introduced bugs
In reply to Once again, please excuse my by sideways
Right. Regression = newly introduced bug. So you don't want to *add* regressions, you want to *fix* them. The big layout change broke a lot of things, and I have to imagine top priority is fixing those. That is what I am suggesting you could help with if you want to speed the process along.
In reply to Right. Regression = newly by Marc Sabatella
OK, I was confusing regressions with the vtests, which seem to me to be part of some kind of repeatable regression testing scheme. What are the vtests, and/or where can I find out more about them besides simply the location of these files?
http://vtest.musescore.org/index.html
I'll devote what time I can to testing and reporting issues, and I'll try to solve my own issues as I encounter them. Beyond that I can't promise anything. But I'm stuck with the latest master and Qt 5.6 for all my branches, so I'm testing things most every day.
In reply to OK, I was confusing by sideways
vtests are indeed a form of regression *test* - a way of checking that we haven't created regressions. The main regression tests we have are the mtests, which are completely automated; a PR won't be mergeable until the mtests pass. The vtests require a human to check the results - a quick scan of the diff's to make sure there isn't anything significant.
The vtests run by generating PNG output for a given test file then doing a graphcial diff against a score referenced. Any pixels out of place show in the result. So ideally, the output of a successful vtest run would be a bunch of empty boxes showing no pixels out of place. In practice, floating point roundoff and font rendering differences and other issues tend to cause the diffs to show very fain outl;ines where things are off by a pixel.
In reply to vtests are indeed a form of by Marc Sabatella
Using SVG for these rater than PNG may eneable us to do the comparison without the need of human eyes.
In reply to Using SVG for these rater by Jojo-Schmitz
Yes, as mentioned by @lasconic on the mailing list, but now I actually understand a bit more about how that might happen. Where can I learn about how the mtests are setup, so that I might assist with that?
In reply to Yes, as mentioned by by sideways
I'm not sure if any particular documentation exists, but I can tell you these are "stub" programs that test specific features. Most do this by reading in a score, performing some operation then saving the result and comparing it against a saved reference. Go to mtest/libmscore and any of the subfolders underneath there and examine the cpp file to see how they work.
In reply to I'm not sure if any by Marc Sabatella
So, the convert a PNG vtest to an SVG mtest, would first involve changing an mtest's output from PNG to SVG. Then there would have to be an automated process to diff the files and report on differences encountered. ???
I'm going to continue this on the mailing list, where it started. Thanks.
Could you create a PR out of your code? I believe we are ok on the principle (adding pt/px), with a PR we can review the code and merge it.
In reply to Could you create a PR out of by [DELETED] 5
Done: https://github.com/musescore/MuseScore/pull/2573
There is no issue number, just this forum topic. I included a link to this topic in the PR comment.
There are 3 commits now, but I can squash it into 1 if that's a problem.
In reply to Done: by sideways
Sideways, I was just going over the commit for this, and wondered why the variable IPMM is defined? Is it needed as I don't see it used anywhere in the code.
In reply to Sideways, I was just going by schepers
probably just for symetry and maybe for futur use, certainly doesn't harm
In reply to probably just for symetry and by Jojo-Schmitz
Good catch. Yes, I wrote that part of the code earlier in the year, and I think at one point I used it. As I was putting this feature request together I noticed that it wasn't being used, but as Jojo says, it's not a problem to leave it there to complete the concepts, so I left it.
In reply to Good catch. Yes, I wrote by sideways
You just caused me to verify if PPI was ever used. Did you check that? The one place it's used it probably shouldn't be:
https://github.com/musescore/MuseScore/blob/master/mscore/harmonyedit.c…
The raw literal 20.0 is also suspicious, in that it's the height of a default 5-line staff:
Staff Space = SPATIUM20 = 5
Full set of staff lines = Staff Space * 4 Spaces = 20
Seems like I should modify this file too, and elimate the DPI/PPI conversion. What about the raw literal? Is it SPATIUM20 *4, or does it have a different purpose?
In reply to You just caused me to verify by sideways
No, I didn't check things that deeply. The mind-bending concept of "inches per mm" and IPMM jumped out at me, and I investigated.
I was unable to rebase to the latest master as of a few weeks ago, so I created a new PR here:
https://github.com/musescore/MuseScore/pull/2624
The old PR is still there, so none of those comments are lost:
https://github.com/musescore/MuseScore/pull/2573