[FFmpeg-devel] proposal for a minor change in the behavior of the drawtext filter

[Francesco Carusi]

On 22/04/2022 12:30, Michael Niedermayer wrote:
> On Fri, Apr 22, 2022 at 12:01:31PM +0200, Francesco Carusi wrote:
>> Hello ffmpeg team,
>>
>> I'm working on an enhanced version of the drawtext filter and would like to
>> discuss with you about a minor change in its behavior related to line
>> spacing management.
>> In the current implementation the space between two lines of text is set
>> equal to the height of the highest glyph found in the text plus the optional
>> user defined "line_spacing" parameter (which defaults to 0):
>>
>> line_height = max_glyph_h + line_spacing
>>
>> This has some drawbacks:
>> 1) the line height depends on the text
>>      See image "line_height-old.png" (the blue lines where added by me)
>>      The filter is applied three times with tree slightly different texts:
>> the line_spacing parameter was not specified,
>>      but the actual line height changes due to the different heights of the
>> glyphs
>> 2) the line height is not consistent between the same text being rendered by
>> the filter and by external tools
>>
>> The proposed change is:
>> 1) the default line height is set to the font-defined line height
>> 2) the line_spacing parameter, if specified, sets the actual line height
>> (line_height = line_spacing)
>> 3) the default value of line_spacing is set to -1 (which means: use the
>> default line height)
>>
>> The image "line_height-new.png" shows the effect of the new behavior.
>>
>> Which is the impact of the change?
>> A) users using the line_spacing parameter would see less space between lines
>> B) users not using the line_spacing parameter would see (in most cases) more
>> space between lines
>>
>> Can the impact be mitigated?
>> Well, yes, we may add a new parameter named 'line_height' and deprecate
>> 'line_spacing', in this way anyone using line_spacing explicitly would not
>> see any change in the filter behavior. I don't like this solution but it may
>> help reducing the impact of the change.
> just looking at the pngs, the old looks bad, the new looks like it has alot
> more space then reasonable.
> If i just compare this to any GUI text editor theres not that much space
> between lines and at the same time the spacing is constant.
> why can that not be achieved ?
>
> thx

Hi Michael,

the space you see is the one defined at the font level. I created the 
same images using the Arial font, which has a smaller height, please see 
the attachments. The height must also leave enough space for cases in 
which a glyph with a long descender on the upper row "meets" a glyph 
with a long ascender on the bottom row (see "line_height-new-arial2.png").

thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: line_height-new-arial.png
Type: image/png
Size: 16775 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220422/b171570b/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: line_height-new-arial2.png
Type: image/png
Size: 20547 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220422/b171570b/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: line_height-old-arial.png
Type: image/png
Size: 22756 bytes
Desc: not available
URL: <https://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20220422/b171570b/attachment-0002.png>