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

[Francesco Carusi <klimklim@tiscali.it>]

Hi Nicolas,

thanks for your feedback. I think there is a misunderstanding due to my 
little experience with this community.
I'm actually modifying the drawtext filter to enhance some of its 
features, as I described in the IRC channel, but in my message I 
mentioned only the "line spacing" since it would be the only one change 
that would break the compatibility with the old interface. I apologise 
for that and I think I should better describe all the changes I'm 
working on.

The main reason for me to modify the drawtext filter, is that I need a 
way to write text on a video that is consistent with other tools, like 
text editors, browsers, or GIMP. I mean: what users see on the other 
tools should be almost identical to what they see on the video. The 
changes I'm implementing to achieve this objective (and some other minor 
features I need in my project, but that may be useful for all users) are:

1) Use the libharfbuzz library to shape text
2) Use the font-defined line height as default spacing between lines
3) Introduce 1/4 pixel precision for glyph positioning
4) Extend the concept of "box" around text, allowing the user to specify 
its with and height or to have them be computed automatically
5) Allow users to specify text alignment in horizontal and vertical 
directions
6) Add some variables that the users can insert in expressions (to add 
more flexibility to text positioning)

-- New configuration parameters:
boxw        -> the box width (default: automatically computed to include 
all text)
boxh        -> the box height(default: automatically computed to include 
all text)
text_align  -> the alignment of text inside the box. The value must be a 
string of lenght 2,
                one character for horizontal alignment: L(eft), 
C(enter), R(ight)
                and one for vertical alignment T(op), M(iddle), B(ottom)
                The default value would be 'LT'

-- Changed configuration parameters:
line_spacing
     -> the default line height is set to the font-defined line height
     -> the line_spacing parameter, if specified, sets the actual line 
height
        (line_height = line_spacing)
     -> the default value of line_spacing is set to -1 (which means:
        use the default line height)

-- New variables (for expressions):
top_a       -> the maximum glyph ascender of the first line
bottom_d    -> the maximum glyph descender of the last line
font_a      -> the font-defined ascender
font_d      -> the font-defined descender

Apart from the line_spacing parameter, I'm trying to keep the maximum 
compatibility with the current drawtext interface. As Michael Koch 
mentioned in his message, also the meaning of the 'y' parameter may be 
changed to improve the filter interface, but it would also break its 
compatibility with the current implementation.

Thanks for reading!


On 24/04/2022 12:07, Nicolas George wrote:
> Francesco Carusi (12022-04-22):
>> 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.
> Hi. While your proposal shows merit in itself, it also feels like the
> first towards re-inventing a layout engine. The problem with line
> spacing is the tiniest of drawtext problems: look for right-to-left,
> ligatures and so much more.
>
> If you want to enhance the output of drawtext, I think it would be more
> efficient to choose a good layout engine library, Libre and portable,
> and to make it use it optionally.
>
> Regards,
>
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".

_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".