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-requ...@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-requ...@ffmpeg.org with subject "unsubscribe".
