"sub." vs "sub"

No, defaults are saved in the user folder, which is left untouched if/when you update Dorico.

Right, except aren’t Dorico 2 and Dorico 3 separate subfolders in the user folder? Which means that defaults done in Dorico 2 won’t carry over to 3?

My custom PT’s carried over.

Interesting, I might start using the “save as default” feature then (I had been avoiding that option before partly because I figured I would most likely lose them on upgrade, as this happens with certain settings for Cubase upgrades). I imagine, if this is the case, that Dorico 3 on first startup for a user must check the Dorico 2 folder for the user for changes to defaults and convert those over to Dorico 3 format.

I think some of it happens on Dorico 3 closing for the first time. But yeah, that’s the gist of it.

The question of a period at the end of an abbreviation/contraction is a good one. Using Shift X / Shift Alt X is of course simple enough. Editing the PT I guess is also simple, but time consuming.

I wonder whether the Dorico team might introduce a simple toggle function somewhere in the Engraving Options dialogue box for something like this? I realise it’s a relatively polarising topic in general, but Dorico’s advantage at the moment is that it gives a consistent outcome throughout a project (and consistency is one of the most important things in any engraving, I think we all agree).

Marrying such consistency with a simple on/off toggle would be excellent. Especially if one is going between different publisher house styles regularly (eg Boosey’s UK style guide has a very strict no-period rule, but others are strictly for the period).

I think it’s asking quite a lot to expect the Dorico Team to dedicate time and resources (at least at this stage) to reprogram their popover feature for something easy enough to do with SHIFT+X text on the off chance that someone who religiously wants to omit a period might accidentally type one. If one wants consistency, be consistent.

I don’t think we could practically add just a single option in Engraving Options for whether all abbreviations should have a period or not, but there may well be a case for some specific options, e.g. one for “subito” in the case of dynamics, and another for always adding a period at the end of an abbreviated staff label (at the moment Dorico does the sensible thing of adding a period when the last letter of the abbreviation is not the last letter of the name, so it’s “Pno” for “Piano” with no period and “Cl.” for “Clarinet” with a period).

Yes and no. I don’t think it’d be a particularly time-intensive thing to add. But I get that it’s not the most exciting thing to add as a feature and I definitely get that it’s not a priority either. Such a toggle would/could extend across more than just the popovers but to instrument labels, etc, in one fell-swoop.

I’d argue it’s not all that different to being able to set Dorico to be consistent in its handling of a good number of things, as one can currently (end points of ties, angles of beams, splitting note durations across the beats, to name a few - all areas in which Dorico offers the user various options for handling).

Well, sure, but isn’t the point of Dorico to just make things that bit easier/quicker? That doesn’t negate responsibility of the engraver, just adds to their toolkit. The more elements of both macro and micro control Dorico offers its user, the more powerful and malleable it will become. That seems a win/win scenario for both Steinberg and Dorico users.

Thanks for chiming in Daniel. That’s a valid point of course. Perhaps there could be a number of options:

  1. All abbreviations/contractions ending with a period
  2. All abbreviations/contractions ending with no period
  3. Only those not ending with the final character of the full word get a period (I agree with you that this is the most sensible, but we have to be honest and accept that it’s often not our choice…)

But, as I previously said, I get that it’s not a priority nor that exciting. It is, however, something that comes up a lot and the ability to toggle between various options (with peace of mind that a consistent stance has been applied) can only be advantageous.

No, the point is that it would be impractical to create a single engraving option that would apply to all text across the program (including playing techniques, dynamics, staff labels, tempos, etc., etc.), because they are all implemented differently.

Just want to add that these options as described by galambborong would fit perfectly with other languages.
In German, we always add the dot to abbreviations.

Since you said “always,” that sounds more like a localization issue than something that needs an option.

There are no different options for the localized versions. Only the description is translated.

It may be “sensible” (according to current UK, though not US, general practice), but is this actually used in any published orchestral scores? I see “period for all instruments” often, as it was the standard in the past. I see “no periods” in some newer publications (and in fact am editing scores for two musical series that adopt this practice). But I have yet to encounter an orchestral score that varies its use of periods according to the nature of the abbreviation; I admit (without any sarcasm) that I may be out of touch and haven’t seen the right contemporary orchestral scores.

Guys, come on. You know this is used all the time.

With period instruments.


I’ll show myself out.

Thanks everyone for thoughtful replies!

Dear fellow Doricians,
Daniel has clearly explained the typographic rules that apply when the last letter of the abbreviation is the last letter of the abbreviated word or not. This is a rule in English, I recall it’s the same rule in French, but it might be different in Germany.
What strikes me since I started this work is how poorly typographic rules are followed in engraving (in the litterature). I think the first thing to do would be to check out the typographic rules of the language in which the score will be engraved and follow them, right? I mean, don’t we do the same with other parts of Engraving, looking up for things in Behind bars or other guides ? I’ve written many posts about French typography, how short unbreakable spaces are compulsory in this language (before any double ponctuation like ;:!?) while they do not exist in English. The problem is the only way I found to input these was to create the glyph in the fonts I use (including Academico), which should really not be the case — and this is probably the easiest glyph to add.
In the fullness of time, I expect that every major Engraving language (Italian, German, French, English, Russian) will be given every necessary tool to fulfill the right typography requirements. And I do not complain about Dorico making me work with good rules, I think it’s a good idea, given the bad habits that I see here and there reading “real-life” scores.

Marc, I don’t know that that’s a realistic expectation of the development team. Multilingual tempo markings on Dorico have fallen by the wayside (only the Italian ones exist), and there are problems with the instrument name translations. There’s at least one user on this thread who’s brought up the question of individual publisher “house styles”. Some (large, well-respected) publishers have one house style that applies to all of their output, regardless of where the composer was born or what language the text is in, and so tying these decisions down to language could be frustrating for the user (as well as for the development team).

Yes, Leo, I understand that. What I really mean is that, even if there are no fixed rules for languages that make the job for us, it should be possible to respect all the rules without having to create glyphs and fight the software — I noticed that the beautiful lyrics editor adds me some · between syllables where I put a hard space (quite common in opera litterature, especially in Italian and French) if I use that editor to correct some misspelled word… I certainly NEVER want to see that glyph in my lyrics.
This is no rant, I love Dorico and everybody here knows it. This is feedback to make it better.