On 20.02.2016 21:06, Dan Dennedy wrote:
> I am not opposed to wrap_type, but can we avoid adding wrap_width? If
> so, then change wrap_type to simply "wrap" where 0 = no wrapping and +1
> for all the other modes.
i think it is possible to combine all width limiting features into two
properties:
On 20.02.2016 22:06, Dan Dennedy wrote:
On Sat, Feb 20, 2016 at 12:04 PM Maksym Veremeyenko mailto:ve...@m1stereo.tv>> wrote:
On 20.02.2016 20:17, Maksym Veremeyenko wrote:
> Hi,
>
> attached patch do some optimization of blending then source alpha
is 0.
please cancel
On Sun, Feb 21, 2016 at 12:33 AM Maksym Veremeyenko
wrote:
> On 20.02.2016 21:06, Dan Dennedy wrote:
> > I am not opposed to wrap_type, but can we avoid adding wrap_width? If
> > so, then change wrap_type to simply "wrap" where 0 = no wrapping and +1
> > for all the other modes.
>
> i think it is
On Sun, Feb 21, 2016 at 11:25 AM Brian Matherly
wrote:
> What does width_type=none do?
>
It does what is does today by default. It creates an image large enough to
hold all of the text you entered. Then, that gets scaled by a normalization
filter per the profile.
>
> Does width_type=fit shrink
What does width_type=none do?
Does width_type=fit shrink the size? If so, how about "shrink" instead of "fit"?
Also, is "width_type" the best name? How about "fit_mode" or "overflow"?
~BM
From: Dan Dennedy
To: Maksym Veremeyenko ; mlt-devel@lists.sourceforge.net
Sent: Sunday, February 2
On 21.02.2016 21:25, Brian Matherly wrote:
> What does width_type=none do?
it does not apply any width scaling/cropping recently implemented and
proposed. i can drop it and use width != 0 as enablers...
> Does width_type=fit shrink the size? If so, how about "shrink" instead
> of "fit"?
because o
