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

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

[Francesco Carusi]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

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.

[-- Attachment #2: line_height-new.png --]
[-- Type: image/png, Size: 19328 bytes --]

[-- Attachment #3: line_height-old.png --]
[-- Type: image/png, Size: 22474 bytes --]

[-- Attachment #4: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 2532 bytes --]

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


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Francesco Carusi]

[-- Attachment #1: Type: text/plain, Size: 2658 bytes --]


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

[-- Attachment #2: line_height-new-arial.png --]
[-- Type: image/png, Size: 16775 bytes --]

[-- Attachment #3: line_height-new-arial2.png --]
[-- Type: image/png, Size: 20547 bytes --]

[-- Attachment #4: line_height-old-arial.png --]
[-- Type: image/png, Size: 22756 bytes --]

[-- Attachment #5: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Michael Koch]

Hi Francesco,

in my opinion the line spacing looks good. But there is still the 
problem that the y position of the baseline depends on the height of the 
characters in the first line. You see that when you switch between your 
pictures line_height_net_arial.png  and line_height_new_arial2.png.
I know that it can be corrected by specifying the y position as 
"40-ascent" for example. Is it possible to make that the default?

Michael
_______________________________________________
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".

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

[Francesco Carusi]

Hi Michael,

you're right, the default y position is not referred to the baseline but 
to the upper left corner of the text. I initially referred it to the 
baseline but that is not the default used by the current drawtext 
filter, so I thought it would be better to keep compatibility with the 
current filter.
I'm open to both solutions: if I refer the y parameter to the text 
baseline, than the current default can be achieved using the expression:

y = <value> + top_a

being "top_a" a new variable I'm introducing with the meaning "maximum 
ascent of the first line".
If I keep the current default, than what you're asking can be obtained 
using:

y = <value> - top_a

I'm new to the ffmpeg devs community so I'm not sure whether it is 
preferred to keep backward compatibility or to change the behavior in 
the name of a better interface.

What do you think?

Thanks
Francesco

On 22/04/2022 15:22, Michael Koch wrote:
> Hi Francesco,
>
> in my opinion the line spacing looks good. But there is still the 
> problem that the y position of the baseline depends on the height of 
> the characters in the first line. You see that when you switch between 
> your pictures line_height_net_arial.png  and line_height_new_arial2.png.
> I know that it can be corrected by specifying the y position as 
> "40-ascent" for example. Is it possible to make that the default?
>
> Michael
> _______________________________________________
> 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".

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

[Michael Koch]

Hi Francesco,

I think the y position of the baseline should be independent of the 
content of the textfile.
For example, you might want to change the color in the middle of a text. 
That can only be done by invoking drawtext two times. To make sure that 
both texts share the same baseline, the workaround with y=40-ascent has 
to be used. In my opinion same baseline position should be the default.

The question remains if the y option refers to the baseline or to the 
top of the text (assuming the text contains a full height character). I 
would prefer the latter.

Backward compatibility or better interface? I vote for better interface.

Michael
_______________________________________________
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".

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

[Nicolas George]

[-- Attachment #1.1: Type: text/plain, Size: 2332 bytes --]

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,

-- 
  Nicolas George

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

_______________________________________________
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".

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

[Francesco Carusi]

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".