(In reply to jimnong from comment #0)
> STEPS TO REPRODUCE
> 1. Add Subtitles. And click "Show style options" button.
> 2. Check "Opaque background" and "Custom Outline Color".
> 3. Change Outline Color. And set "Alpha channel" to 155.

This has all changed a bit since the version you reported this for, and is about to change a bit more,
but the essence of this issue remains the same.

> The superimposed background color of the subtitles looks darker than the
> non-overlapping ones.

That's kind of fundamental to how alpha works.  If you overlap translucent layers
they will become more opaque, so this part is "expected".

> The background of the subtitles should not overlap.

Which means this is the core of the problem with what you tried to do.

> It seems necessary to add options such as up/down/left/right margin or
> padding.

You can try to fiddle this with vertical scale and the like, but that won't work
very reliably, because "overlapping" subtitles appear to have slightly different
vertical spacing to "multi-line" subtitles with an embedded line break - so if
you do this you can 'fix' one at the cost of breaking the other.

And chances are it changes depending on the metrics of the font used too.
So for embedded subtitles this is probably all going to depend on the player
used and its environment, and will be quite fragile too.

Part of the problem here is that you are using border style '3', which is
defined as "Opaque box around text" (in the 25.04 style editor shown as
"Box as outline").

This seems to work ok if instead of embedding a newline in a subtitle you use
separate subtitles for each line of text.  That seems to get the vertical spacing
between lines correct.

But I'd probably instead suggest you use border style '4' for this sort of use.
It is defined as "Alpha shaded box around text" (shown as "Box as shadow"
in 25.04).  That will give you a clean translucent box bounded around the
entire subtitle instead of the 'stacked' boxes style 3 uses, which is less
troublesome (and I personally think looks cleaner and easier to read).


And that's the real crux of the matter here - kdenlive doesn't actually control
how this will be rendered.  The best we can do is provide a sane default style
and suggestions for other use cases.  We could argue there's a bug in the
line spacing for border style 3 in the case you encountered, but we can't fix it
in kdenlive, and even if we passed it on to MLT (which in turn punts that through
ffmpeg, which I think in turn passes it to libass to handle), there's still other
alternative renderers which may treat this differently in different players, and
you'd need to fix them all to be able to rely on doing it the way you currently are.

So I'm closing this as a bug in the kdenlive software, since we can't fix it there.
But it might be worth opening a discussion on the forum about it, where people
can share hints about what is known to work 'portably', which might turn into
something worth including in a section of the main documentation.

It is a 'real problem' for some use cases, we just can't fix it in our code, or easily
and reliably in every other piece of code that would need tweaking.

*** Bug 497209 has been marked as a duplicate of this bug. ***