Text over bar line

I must have not seen this.

I had posted about it on the forum .

Is it required to be able to overwrite bar lines ONLY or anything?

In the second case, adding a solid background to the text and some layering would probably be the easiest thing to implement (and maybe also to explain in the documentation?). Thus, the text would blank whatever happens to occur underneath it.

M.

There is already something since a couple of commits f6947290d4 to be able to have a background for a text frame. It needs testing before marking this issue as fixed.

This is fixed.

1. Create a text
2. Right click it -> Text properties
3. Check styled, check frame, click on background color, choose a white, change alpha to 255
4. OK
5. Move on top of a barline

Result :

Thanks lasconic (and Werner!).

I'm sorry to re-open.

It maybe challenged if the background of the score is a colour, or image that can't match the background colour of the text (like lasconic's example actually).

Can we perhaps make a proper setting which specifically allows text (and indeed images, etc?) to penetrate the bar line (it basically has no background colour)?

Does anyone know of examples in which text actually penetrates an intact bar line, or do bar lines always make way for text? Perhaps both exist.

I think it will be over engineering to do a special case only for that. The background color of text is a nice solution that solves other issues #17402: Colored background for odd/even lyrics lines. My example is indeed a bad one, because the PNG is transparent and the background of the text is white but still, it will solve 99% of the case.

For images over barlines, it should already be possible to change the Z order of images to put them above anything.

The coloured background is suitable for lyrics - that issue indeed appears to be fine.

However, the more I think about it, I feel this is a genuine feature and meant to be.

It is a special case, but not likely to be over-engineering, or unheard of. It would make everything easier, instead of having to mess around with the background colours, plus the result may not be very desirable for aforementioned reasons (also, what if you have paper that's not white, or whatever?).

You click on the text and in the 'Inspector', you tick 'make bar line give way' (or something better).

I don't see how that is easier or better than setting the background color of your text to match your paper color. And of course, we're talking about the paper color as set in MuseScore - white is still the proper background color to choose within MuseScore if you are simply printing on colored paper. I can't imagine there exist any real life cases where the solution as implemented won't be sufficient or even any more difficult than a solution where it is a barline property rather than a text property.

Won't there be an inconsistency?

For the text background:

If you choose the MuseScore paper colour, the print will appear different.

If you choose the printed colour, it'll appear different in MuseScore.

With what I propose, you won't have to bother about this - both viewing and printing will appear the same.

How are you proposing changing the paper color in MuseScore? Dropping a graphic over the entire page? I am not aware of any feature in MuseScore that changes the paper color. Perhaps you mean just the on-screen "canvas" color? Yes it is true that text with a white background will stick out, but it will look correct when printed. What are the real life scenarios in which this would matter? And in how many of those cases would someone need this non-standard text behavior anyhow?

What you propose seems to be a solution in search of a problem. No doubt, it works, but in every real world scenario I can think of, so does what has already been implemented.

Yes, I meant the canvas - thanks.

It is a somewhat special case, but not completely improbable (as are probably a couple of things currently in MuseScore?). I definitely don't think we should ignore it on that basis.

Text penetrating a bar line has been seen in a couple of examples so far, so it's not completely unheard of (here's mine ).

A background image maybe used (not necessarily using MuseScore to include it?) if it pertains to the music (e.g. production photo - faintly visible), or whatever.

I don't think I'm including background images in this, but if a publisher uploads a score for people to download, someone could print it and see the background colour of the text.

Also, what if other people viewing the score change, or have a different canvas (or anything else that depends on certain settings)?

I believe what we have right now is just a workaround for certain situations.

There's been no response and I don't want this to disappear.

I know there's disagreement, but I still feel this is valid. Please re-consider.

What info do you think this still needs, then? Seems to me the only we don't know is if there exists any real world case where a real user will ever find the already-implemented behavior insufficient. Why not leave it closed and wait for someone to complain that the current solution works "only" in the 99.99% of cases where the music is printed or viewed on a plain background? Or set it active but set priority to minor?

Or maybe I am just not understanding the cases where you think this won't work.

As far as I can see, printing on paper works every time, no exceptions. Doesn't matter the color of the paper or whether pre-printed graphics are present. Printing works, period - yes?

On screen viewing of generated PDF's works also, regardless of whether you have temporarily altered your canvas color within MuseScore, since there is no option to export canvas color to the generated PDF as far as I know. The only case where you could get a generated PDF to fail is if you are have superimposed some sort of graphic onto your score to act as a watermark, but there would be easy workarounds to that case (use external program to add the watermark instead of doing it in MuseScore).

So as far as I can tell, we are really just talking about a temporary glitch visible only to the creator of the score and only while editing it within MuseScore and only if for some reason he alters his canvas color even though he knows this is not going to be the actual background color anyone else sees when viewing a print of a generated PDF. And if really wanst that altered canvas color while editing within MuseScore and is bothered that these few text elements show with a white background, I'll bet a plugin could be written (if this new background color property is exposed to the framework) to automatically change the text background colors to match the canvas.

Am I missing something here? I am just not seeing why we can't consider this matter closed.

I agree with Marc here.

This feature request is now effectively fixed.

As far as I can see the only possible issue is purely cosmetic and easily solved by the user defining a background colour to match the canvas.

But then I again I only print in black and white :)

I was sort-of trying to be less crude with 'needs info' ;).

Printing could work on non-white paper, but you'd need to know the exact colour of the paper to change in MuseScore. If there's something on the paper, then it won't look nice.

Chen lung, printers don't have white ink. If you print on blue paper (for example) anything that appears white on the screen will not get any ink on the paper. So white will match any paper color perfectly :)

You can verify this by creating a score with text on a white background and then printing to a colored piece of paper.

Right. "White" is not a printable color; it is just a placeholder for, "don't print anything at all". If you print on white paper, it comes out white. If you print on blue paper, it comes out blue.

Meaning, you don't have to "match" anything. Simply set your background color to white for any text you wish to cover a barline, and it should print perfectly every time regardless of paper color. White is the only background color you should ever need when using this feature.

The only case I can see where someone other than the person editing the score would see an an issue is if the score contains a watermark, but as I mentioned, there are other / better ways of achieving watermarks anyhow. Does 2.0 even support watermarks right now? I can't get images to work at all. 1.x seems to lay images below notes but on top of staff lines,

lasconic's example above fails only because it is a screen capture, not a regular generated image. That is, it is showing the mismatch that indeed could occur on screen only for the person editing the file. And to me, that particular mismatch is arguably a feature, not a bug - it makes the nature of the text more clear. Kind of like the greyed out symbols that appear by default for invisible objects.

I suppose for completeness, the text background color dialog could be extended to include "paper" as one of the background color choices, and we could recommend people use that instead of white. That way, if MuseScore ever did implement a "paper color" option that would create colored PDF's or use ink to create colored papers, that color would automatically be used for any such texts. And if MuseScore implements a watermark feature, "paper" could be defined to include that.

The upshot would be, people would be encouraged to use "paper" instead of "white" in the text background color dialgo. But for now, there would be no difference.

It's difficult to check things at the moment, because of this: #17643: Weird behaviour on editing existing textual elements

Surely the white background for text is misleading? If I hadn't known about the placeholder, I would have possibly expected to have a white background. Ignoring this issue with the bar line, what if you want to print a score featuring text with a white background, on non-white pages, or paper?

Admittedly, I'm probably not likely to do much of this myself, but I just want to highlight (so to speak) possible disadvantages.

Until someone invents a printer with white ink, you'd be out of luck if you wanted a white background on any color paper but white. That's not unique to MuseScore; that's kind of a basic computer concept. I would think most people are probably aware of this already, but certainly anyone who prints on colored paper is going to figure it out soon enough. Again, it's not just MuseScore but every program in the world in which a white background translates to "paper color" when printed.

Although white ink does exisit in the print world.

If you are putting your scores through a professional print firm they would be able to use the exact colours you specify. I doubt whether this would cover the jobbing printers such as VistaPrint which you find on the internet, however.

Automatically closed -- issue fixed for 2 weeks with no activity.