View Bug Details

IDProjectCategoryView StatusLast Update
0000744DCP-o-maticBugspublic2018-10-17 20:16
Reporterrobn Assigned Tocarl  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSFedoraOS Version22
Product Version2.5.0 
Target Version2.6.0 
Summary0000744: single line subtitles not on lowest position
Description

A single line subtitle should use the lower position instead of the top position.
(eg. the position where the second line of a double line subtitle appears).

Did not test with a final DCP yet, only with the preview window.


top line of a 2 line subtitle
bottom line of a 2 line subtitle

Steps To Reproduce

Check the preview of a single line .SRT subtitle.


top line of a 2 line subtitle
bottom line of a 2 line subtitle


wrong position of a 1 line subtitle



correct position of a 1 line subtitle

TagsNo tags attached.
Branch
Estimated weeks required
Estimated work requiredAverage

Activities

carl

2015-11-10 01:12

administrator   ~0000965

Hi, thanks for the report, do you have a reference to say which is the correct position of a 1-line .srt subtitle?

robn

2015-11-10 01:32

reporter   ~0000966

I don't have a direct reference at hand.

But being a projectionist I notice that most (if not all) DCPs, DVDs,
Blu-rays, mediaplayers, video players etc. use the lower position
for a single line subtitle.
This is probably because this way the image is obscured less.

robn

2015-11-10 02:05

reporter   ~0000967

Couldn't find any "hard evidence" after some googling .. :-)

But I verified that both VLC and MPlayer use the lower position for 1-line subtitles. And if I remember correctly the standard FFmpeg "subtitles" filter
has this behaviour.
And I found a suggestion here:

http://translationjournal.net/journal/04stndrd.htm

"In the case of a single-line subtitle, this should occupy the lower of the two lines, rather than the top line in order to minimise interference with the background image action."

Of course this is not a proof or a specification.
But I personally think it is the preferred behaviour!

carl

2015-11-10 09:05

administrator   ~0000968

Fair enough ;) Thanks for looking into it.

carl

2015-11-13 14:57

administrator   ~0000979

Fixed in e6f4cff3b6cf1ac680940b16187f74e22848d825; will be in 2.5.3.

Bug History

Date Modified Username Field Change
2015-11-10 01:00 robn New Bug
2015-11-10 01:12 carl Note Added: 0000965
2015-11-10 01:12 carl Assigned To => carl
2015-11-10 01:12 carl Status new => feedback
2015-11-10 01:32 robn Note Added: 0000966
2015-11-10 01:32 robn Status feedback => assigned
2015-11-10 02:05 robn Note Added: 0000967
2015-11-10 09:05 carl Note Added: 0000968
2015-11-10 09:05 carl Status assigned => confirmed
2015-11-10 09:05 carl Target Version => 2.6.0
2015-11-13 14:57 carl Note Added: 0000979
2015-11-13 14:57 carl Status confirmed => resolved
2015-11-13 14:57 carl Resolution open => fixed
2018-10-17 20:16 carl Status resolved => closed