[FFmpeg-devel] [PATCH] vf_drawtext: drop text wrapping feature

[Stefano Sabatini]

On date Wednesday 2011-09-21 16:45:25 +0200, Michael Niedermayer encoded:
> On Wed, Sep 21, 2011 at 11:17:42AM +0200, Stefano Sabatini wrote:
> > On date Tuesday 2011-09-20 23:30:42 +0200, Michael Niedermayer encoded:
> > > On Tue, Sep 20, 2011 at 08:30:39PM +0200, Stefano Sabatini wrote:
> > > > Or in other word, do not go to the next line when the text cannot be
> > > > rendered within the frame.
> > > > 
> > > > The rationale is that wrapping is hard to manage, as it depends on the
> > > > position of the text, thus making hard/impossible to compute the size
> > > > occupied by the rendered text, and makes the filter behavior
> > > > unpredictible with moving text (implemented in a pending patch).
> > > > ---
> > > >  libavfilter/vf_drawtext.c |    6 ------
> > > >  1 files changed, 0 insertions(+), 6 deletions(-)
> > > > 
> > > > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > > > index fbb1e53..d7447c2 100644
> > > > --- a/libavfilter/vf_drawtext.c
> > > > +++ b/libavfilter/vf_drawtext.c
> > > > @@ -655,12 +655,6 @@ static int draw_text(AVFilterContext *ctx, AVFilterBufferRef *picref,
> > > >              x += delta.x >> 6;
> > > >          }
> > > >  
> > > > -        if (x + glyph->bbox.xMax >= width) {
> > > > -            max_text_line_w = FFMAX(max_text_line_w, x - dtext->x);
> > > > -            y += max_text_line_h;
> > > > -            x = dtext->x;
> > > > -        }
> > > 
> > > This could be made conditional on a user set flag
> > 
> > That was my first implementation, then I realized that this option
> > clashes with parametric x/y evaluation, and drawbox is not supposed to
> > be a word processor so I don't want to add too much complexity for
> > dealing with that case.
> > 
> > I could add a wrapline option, which disables x and y evaluation (so
> > basically x and y are evaluated only during the configuration stage
> > when wrapline=1), that would be a bit clumsy, but I can implement this
> > behavior if you think it is worth to do so.
> 
> I dont know, iam no "user" of this code. Its a question the users
> should awnser. Iam fine with anything our users are fine with here

I decided to drop the feature, explanation is in the commit log, and
the feature was half-baked anyway. 

In case there is interest, we should add support for a library which
offers rich text capabilities rather than implement them from scratch
(that would confirm the rule that all sophisticated enough programs
tend to have editor and mailer features, FFmpeg is no exception).
-- 
FFmpeg = Forgiving and Forgiving Mean Philosofic Elfic Game