Margins should be shared between multiple subs in same alignment group

[Dador]

Margins should be shared between multiple subs in same alignment group

[Arnavion]

Yes, it applies the outer margin (bottom margin for \an2, etc.) to every dialogue, whereas VSFilter / libass only apply it to the outermost dialogue and use no margin for the others.

Currently each dialogue is rendered in isolation, so making it aware of other dialogues will be tricky (especially taking into account that the diaogue is rendered from cache).

Edit: One possibility is to set the margin as CSS padding on the layer div instead of the CSS margin on the individual sub divs. I think I investigated this long ago but I can't remember why I didn't do it. If doing this, it might still be necessary to put CSS margin for absolutely-positioned subs.

[Arnavion]

Actually, the real behavior is more complex. The margin is always applied from the bottom of the viewport. If you have two subs in \an2 with vertical margin == 20px, then both will try to be 20px above the bottom of the viewport. Of course the second one cannot be there since it will overlap the first one, so it moves up till it's above the first one. (*)

Instead suppose one sub was \an2 with 20px margin, and another was \an2 with 200px margin. Then the first one would appear 20px above the bottom of the viewport, and the second one would appear 200px above the bottom of the viewport. That is, it will not appear directly above the first one.

In other words it's wrong to just set the margin to 0 for all subs except the lowest one in the \an2 div.

A proper fix will be hard for this, since CSS doesn't have a way to specify a distance between child and parent while also not letting the children overlap.

---

(*) And since the margin is only relative to the viewport and not to the individual subs, that's why the two subs won't have any margin between then.

[XCanG]

What about calc() function? May be use some algorithm co calculate heigh of stroke? (relative %, vh and fixed px, other)

[Arnavion]

@XCanG Not sure I understand what you mean.

[XCanG]

@Arnavion https://developer.mozilla.org/en/docs/Web/CSS/calc

[Arnavion]

I know what calc is. I'm asking how you propose to use it to solve this problem.

[XCanG]

Using negative order, for example:
first line subtitle will have position: top: 100%
when second line incoming
first stay at top: calc(100%-0) and second will be at top: calc(100%-30px)
when first finished second recalculating to 100%-0px

[Arnavion]

Sure, but that requires knowing that the first is 30px high. If libjass knew that then it wouldn't need to use calc at all since it could just absolutely position everything...

[XCanG]

In my idea this relative 100% calculating by one method, other fixed 30px calculated by another metod and both of them resolve problem.

As the backup I know other method, but it require wrapper, see example http://jsfiddle.net/b9hg3kag/1/ So, this method call the only problem with adding a lot of strokes (3 or more), but it also possible to sorting this lines.

[XCanG]

For more 2 lines it will look like this: http://jsfiddle.net/b9hg3kag/2/

[Arnavion]

Again, my point is that libjass doesn't know the height of the subs to be able to position things with calc. If it did know the height of the subs, then it wouldn't even need to bother with calc because it could just position everything absolutely.

[XCanG]

Ok, but how about this example? If it can apply on subs lines.

[nickfujita]

@Arnavion Thanks for quickly fielding issue #102 . I read through the thread, and it sounds like the tradeoffs at this point in time are to have the elements margins interact with one another or to have them overlap.

For example:

So without fully resolving the issue, it seems that the lesser of the 2 evils (at least in my use-case) would be to let the 2 subs overlap if the dialog sets them as such, instead of having the margins of the two elements affect each others position. This will assume that the author of the subs had considered overlap, and did not position the margins in a way that would make them overlap if the libass rule of non-overlapping text were not in place.

Would this be possible? Possibly as an option until the issue is fully resolved?

[Arnavion]

Making subs overlap if they have the same margin is strictly worse than showing them with more margin that necessary. The latter allows you to atleast read them.

[nickfujita]

While I agree that in the cases where there are overlapping content that it is better to show the content offset instead of as shown in the example I previously provided, the assumption for the request that followed was that this would not occur. Assuming that the subtitles that I am looking to render were created in such a way that the above overlapping example would not occur, and I am encountering more of the following scenario, where it seems that "overlapping" the margins would be the desired option. The following example illustrates cases where not overlapping the margins makes the subs infact less readable since they are pushed off the viewing area.

[Script Info]
ScriptType: v4.00+
Collisions: Normal
WrapStyle: 0
PlayResX: 640
PlayResY: 360

[V4+ Styles]
Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic, Underline, Strikeout, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, MarginV, Encoding
Style: one,Ariel,18,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,0,0,2,0278,0226,0200,1
Style: two,Ariel,24,&H00FFFFFF,&H000000FF,&H00000000,&H00000000,-1,0,0,0,100,100,0,0,1,0,0,2,0010,0010,0018,1

[Events]
Format: Layer,Start,End,Style,Name,MarginL,MarginR,MarginV,Effect,Text
Dialogue: 0,0:00:00.00,0:00:30.00,one,,0,0,0,,Should be on bottom 1
Dialogue: 0,0:00:00.00,0:00:30.00,two,,0,0,0,,Should be on top 1

The second dialog is not visible because it has been pushed out of the viewing area.

[Arnavion]

I am encountering more of the following scenario

It is absolutely not a common scenario. The behavior your subs are trying to achieve is more commonly done by positioning one of the lines with \pos or \an8. In the case where two subs do have non-absolute positioning and the same alignment it's far more common for them to have the same small margin so that they're close to each other, such as the example in the OP.

I'm not saying that the current behavior is good because it's obviously wrong, but it is the least worst outcome and there's no reason to make it worse for the common scenario.

[nickfujita]

Thanks for the tips on how to achieve the desired positioning in the subfile. Unfortunately I have no control over the content in the files, and am looking to find a solution to deal with the current state of the files I need to render.

The request is not to necessarily change the behavior outright, as I completely understand that there are others using the lib, and depend on it's current behavior. What I am looking for is more of an option that, if explicitly set, can augment this current rendering approach in favor of the alternative outcome I described. This would allow the library to accomodate both imperfect behaviors until the single proper behavior is achieved.

[Arnavion]

If there is a PR with the option I will consider it. Alternatively you can look at https://github.com/Dador/JavascriptSubtitlesOctopus instead. With the direction browsers are moving in with respect to SVG rendering vs WASM, that library is the more likely future.

[nickfujita]

Thanks for recommending JavascriptSubtitlesOctopus, I looked into it, and it seems a little too future for the browsers that I need to support. If now asm.js were supported more broadly. I supposed I will just have to look into modifications that I can make to the rendering approach to support absolute positioning with frame by frame collision detection on a local fork...

[Dador]

browsers that I need to support

BTW, what browsers you would like to support?
asm.js isn't really required so it'll work in IE.

[nickfujita]

@Dador Thanks for following up! I am looking to support the following:

Desktop

• IE
• Edge
• Firefox
• Chrome
• Safari

Mobile web iOS

• Safari
• Chrome

Mobile web Android

• Chrome
• Android browser

Native iOS

• WKWebView

Native Android

• webkit.WebView

[nickfujita]

Migrating this discussion to JavascriptSubtitleOctopus issue#14