fix bug lineheight was not correctly applied

[Florent-Bouisset]

The lineheight attribute for TTML subtitle was not correctly applied.

trimmedLineHeight is a string and trimmedLineHeight[0] is a single character,
Regex was never matching a single character and always returned null.

I guess the devs expected to acces first element of the array when doing trimmedLineHeight[0]
(as it is done in a similar way in `apply_padding.ts)

[peaBerberian]

Nice, I want to merge it as it is a real fix. Some of canal+ contents are poorly-packaged but we already have some ways of doing a special treatments for them.

Maybe in the longer term, a useful subtitle styling API which would overwrite some properties could be added. It does not look so simple to define though.

[Florent-Bouisset]

Nice, I want to merge it as it is a real fix. Some of canal+ contents are poorly-packaged but we already have some ways of doing a special treatments for them.

Maybe in the longer term, a useful subtitle styling API which would overwrite some properties could be added. It does not look so simple to define though.

I can create merge it and create an other PR specific for the branch canal where I set manually the lineHeight to default (around 120%)

[peaBerberian]

I think we'll just create a patch with the other work-arounds we currently set on specific releases:

• if the second origin number (y position) is more than 100% or less than 0%, we put the cue at a fixed position centered at the bottom of the screen instead.

• if the second extent number (height) is more than 100% or less than 0%, we set an automatic height and a width of 80% (subtitles are still usually centered)

• For v3.x.x releases only*, if playback is stuck at a given position and our heuristic has a good reason to think that's because the browser is not relying on the decryption key we pushed (it's a PlayReady issue as you would imagine), we reload/

  *This patch is not needed in v4 because we already reload in the base v4. We cannot do this in base v3 because reloading is linked to a subtle API breakage of the playerStateChange event and wasn't present in v3.0.0

This would be yet another addition here.

For now those are just in two commits:

• 8c24b11 (TTML work-arounds)
• fce5971 (PlayReady work-around)