Not precisely collisions but...

Is it OK for a tail to be too close to (almost touch) a rest? and
Wouldn’t it be better if ties that cross over a time signature stop right before it and then restart on the other side?
I don’t consider these errors but I personally don’t like either one. (See attachments)

Antonio
Screenshot 2016-12-02 22.28.05.png
Screenshot 2016-12-02 22.26.29.png

Also perhaps not precisely a collision, but doesn’t the left parenthesis of “(f)” look unideal?

(I am still sad that typing “(f)” into the Shift-D dynamics popover results in absolutely nothing happening; I have to enter a dynamic and then click twice in the properties panel to make a parenthetical dynamic.)

It looks just “wrong” to me, not “unideal”. The gap between the “f” and the right parenthesis also looks different in “f)” and “mf)” - FWIW I think the “mf)” version is better.

I would want those brackets round dynamics non-italic. Is that possible (yet)?

You could make them non-italic by making all dynamics words (things like molto, poco, etc.) non-italic as well, but otherwise not. However, doesn’t using non-italic parentheses with italic characters cause problems of its own?

Just to be clear, my vote is for the parentheses to be italic but have appropriate, equal amounts of space on each side, and not collide with anything.

There is or was a convention in typography that brackets of any kind ([]) are not italicised, even in italic contexts. See e.g. Bringhurst: The Elements of Typographic Style. In Sibelius you have control over the style of individual characters; I think it’s regrettable if Dorico doesn’t provide similar control.
As for problems — you may have to insert space before/after the parentheses to avoid collisions with some of the letters (though ideally this would be handled automatically by the kerning of the font).

I went looking in Behind Bars for Elaine’s thoughts on parentheses around dynamics, and while she says nothing about their style, check out page 107—they do in fact appear to be roman type!

You learn something new every day… Having just attempted to duplicate this idea in Sibelius, it is a huge pain. :slight_smile: But it is possible.

I’ve just come across the tie/time signature collision asveginor originally posted about here - see attached screenshot

Could a fix be added somewhere on the development roadmap please, if it hasn’t been already?
Screen Shot 2017-10-14 at 13.38.33.png

I think the ability to erase the background of objects has been requested before, but I can’t recall what the response was.

Regarding the parenthesis, I agree perhaps it would be useful to have them in roman. Also, Daniel: how can we make sure that the kerning is appropriate? This doesn’t seem something to be specified in the font or in the metadata, or else it would be fine with Bravura.

LSalgueiro, I don’t believe “erase background” is quite the same thing. Though it’s a pain and should only be done after all other engraving’s been done, it’s possible using blank graphics frame.

If we were to erase background in this situation, we’d lose some of the “8” of the time signature, and some of the staff lines in addition to the bit of tie we want to hide.

… which is why it would be applied not to the tie but to the time signature, which seems to be on top of the tie in such a situation in Sibelius.

We definitely do plan to make it possible for ties, slurs, etc. to be clipped either side of time and key changes, but it’s not something that will be included in the forthcoming update, I’m afraid to say.

Regarding the kerning of parentheses around the bold italic dynamics characters, that is a very vexed issue, and we currently have a pretty coarse approach to it (some special case code that inserts additional space characters before or after certain characters under certain circumstances). In the future I hope we’ll be able to do something more clever, and yes, it will probably need to involve a kind of abstract kerning approach, similar to what we have done for chord symbols (which also need to mix characters from different fonts with some flexibility in horizontal positioning).

I know Dorico’s approach is to make everything as easy as possible to everything, but can’t you just dump this one on the users? I mean, I usually tweak my typography manually when I have the time, anyway…

Do that, and you get the ugly mess you see in hundreds of Finale scores made by people who don’t know any better (or Sibelius scores with dynamics in Times Roman, and not even bold). We don’t need another notation app to do that - there are several on the market already!

Nicely summed up, Rob.

I want the software to get it just right and to show the same amount of incredible attention to detail it has done so far, but this seems needlessly complicated to handle backstage, it will become more so as SMuFL-compliant fonts become prevalent…

I suspect the root cause of the problem is that there is no “simple” way to define the kerning between glyphs in two different fonts, and italic, bold, etc usually are defined as “different fonts”. In the font standards like TrueType, OpenType, etc there isn’t anywhere for that sort of data to live.

Of course in general it’s an open-ended question, since conceptually you could have glyphs from any of thousands of different fonts next to each other!

That is certainly a limitation with TeX and LaTeX, and if there was a work round, I expect they would have already implemented it!

Rob, that is why I use XeLaTeX… But I admit I do not mess with kernings, I only like the ability to use any font I want.

Just following up on this thread from last year to say that while it’s nice that the parentheses around dynamics are now non-italic (as Elaine Gould advises), more of them collide with their respective dynamics than not. Last December only the open parenthesis of a (f) collided; now the opening of § does as well, plus the closing parenthesis of (f).


Also, I’ve found often a parenthetical dynamic at the beginning of a bar will collide with the barline. It would be nice if Dorico could adjust the dynamic for me the way it makes micro-adjustments to lyrics for better spacing — just move the dynamic a little bit to the right so it doesn’t collide.