Unnecessary use of hard formatting for text
I would like to touch the basic way MuseScore handles text formatting. Presently, text style definitions ('Style' => 'Edit Text Style') affect only text elements, created after a change of style definitions. This happens, because MuseScore saves each text element with inline formatting, derived from the style definitions, valid at the time of creation of the text element. As global style definitions altogether are saved in the XML file, is it planned to reduce the use of hard formatting only to values like positioning where it is unavoidable?
The present solution is mostly redundant, bloats file size and hampers text editing.
One example: r2726 added the possibility to change instrument in staff properties dialog, which is a great enhancement. Using this option resets the inline formatting for InstrumentLong in the edited staff always to DejaVu Sans, 9pt. An attempt to reformat the text with MuseScore adds a span inside this text element with one more level of inline styles. This is not very elegant and would be solved IMVHO in one go if inline styles would be used only if really necessary.
Comments
MuseScore uses the high level QDocument class for implementing all of its text elements. This allows multi line text, mixing of different fonts, font sizes, styles and more. This text elements are serialized to html by a qt method and we have no influence of this generated code.
Its a design decision to use text style only for new created text. To change existing text you have to select it and change it via the property dialog. This allows for more control of what should be changed and what not. For ease of use there are more sophisticated functions to select groups of elements.
In reply to Text implementation by [DELETED] 3
I'm particularly interested in changing lyrics style. I have often files with a given style (either old scores or imported scores), which I want to print in a different lyrics style (for instance have larger letters for old persons). So of course I'm interested in some global command turning all lyrics to the wanted style.
Meanwhile, rather than modifying each lyrics parcel, I used sometimes a more radical method implying to modify directly in the xml file.
Select the mscz file, have a copy for safety, open it in the archive program, extract the mscx file which is inside.
Open the mscx file with a texte editor.
Somewhere in the beginning are the specifications for even and odd lyrics, with a reference number.
Further, for each implied measure you find marks "Lyrics" and "/Lyrics" between which lay the lyrics.
In some of them there is only a reference to the style given in the beginning. And they display according to this style.
In some others there are marks "html-data" and "/html-data" between which a local text appearance is specified.
So I memorize the lyrics text of the concerned syllable, and prepare a replacement box to replace the html-data block by a "normal" block using the same syllable (one can even use "replace all").
A "normal block" is just the syllable between the marcks text and /text, in plac e of the whole html-data block. Then going to the next html-data block I charge it in the "find" combo, and have just to change the syllable text in the "replace with" combo.
Then saving the file, and opening it with Musescore, and if correct saving from Musescore to the mscz format.
If I'm right, the overall styles given in the beginning are the counterparts of the Edit Styles menu entry, and they obey to the changes you do. Alternatively one could modify them in the mscx file......
Not very easy, but better than to modifiy each syllable from within usescore, because at least you get a "fresh file" into which you can, again, have an overall control of lyrics style.
In reply to Text implementation by [DELETED] 3
First of all, thank you so much for your dedicated work on this fantastic application!
This text elements are serialized to html by a qt method and we have no influence of this generated code.
Thank you for the insight into the way text is handled by MuseScore. Does it mean, that there is no way to tell QDocument not to insert any font properties at all by default?
Its a design decision to use text style only for new created text.
Of course, it would be bad if the default text style would overwrite user applied hard formatting. But it contradicts all the experience from standard word processors like OpenOffice.org Writer where documents are styled primarily with style templates, if changing a default style has no effect on elements, which have been formatted solely with the default style.
Another point is that one often doesn't know exactly in advance, which font family, weight, decoration etc. he or she will use in a score, so applying a new style to a big number of already existing similar elements is more the rule.
The problem with the present situation is that there is no simple way to distinguish user defined hard formatting, which must be preserved and default formatting, which should be centrally modifiable.
To change existing text you have to select it and change it via the property dialog. This allows for more control of what should be changed and what not. For ease of use there are more sophisticated functions to select groups of elements.
This doesn't work e.g. for a frequent case of staff text. It is impossible to assign a new font to all text elements of the category "staff text", because font is applied only to a selection of text within a single text element. The same applies to instrument names, not mentioning that they don't have a 'Text Properties...' option in their context menu at all.
I think that an option 'Apply default Style' in context menu of all text elements would pretty much make everyone happy.
In reply to Text implementation by Ilja Sekler
I do agree with your conclusion.
but: by the way, what happens when one uses "Import style sheet" on a (partially) hard-coded score?
In reply to Oh yes! by robert leleu
(robert leleu:) what happens when one uses "Import style sheet" on a (partially) hard-coded score?
Inline formatting overrides all other styles. The imported MuseScore style will affect only elements created after the import and elements, manually freed from inline styles as well (these elements will get their hard formatting again as soon you save the score).
I assume, you mean 'Style' => 'Load Style...' option.
In reply to 'Load Style' by Ilja Sekler
By me the menue entry is
Style>Charger un style
and I had to guess a translation....
In reply to Charger un style by robert leleu
I had to guess a translation....
You can always launch MuseScore in English with the command
LANG=en_US.UTF-8 mscore
or
LANG=en_US.UTF-8
export LANG
mscore
In reply to $LANG by Ilja Sekler
Or by using the Edition -> Preferences -> Général -> Langues
In reply to Text implementation by Ilja Sekler
"It is impossible to assign a new font to all text elements of the category "staff text", because font is applied only to a selection of text within a single text element."
It is possible with the latest prereleases and nightly builds:
In reply to "It is impossible to assign a by David Bolton
from which revision is available this possibility.
Is it present in 0.9.6b 2438
which is the more recent available for debian systems?
thanks.
In reply to from which revision? by robert leleu
The last four digits are the revision number. The highest revision number is the most recent. I think any revision after 2044 should have this. For details see #2472: Lyrics don't always resize
In reply to "It is impossible to assign a by David Bolton
It is possible with the latest prereleases and nightly builds:
As stated above this doesn't work for font (font-family) property. Though this might be somewhat intentional, because setting accidently parts of text which use "mscore-20.ttf" and "mscore1-20.ttf" to any other font would look quite odd, if someone uses this font for staff text and not only for dynamics. To avoid this it would be important to be able to distinguish between default and user defined inline styles.
In reply to font-family by Ilja Sekler
The font change problem is a known bug. See #4216: Text properties font change doesn't work (0.9.6)
In reply to The font change problem is a by David Bolton
The font change problem is a known bug. See #4216: Text properties font change doesn't work (0.9.6)
Oh, I see, thanks. Once this bug gets fixed, are there any plans to add text properties dialog to context menu of other text elements like instrument name? This (and an "apply default style" option) would be very helpful for orchestra scores IMHO.
In reply to font change issue by Ilja Sekler
I created a new issue report for the missing text properties dialog for instrument names: #4651: Text properties for InstrumentLong and InstrumentShort
I would also like to see less in-line formatting but it sound like this is not feasible for the time being.