Oleg Oshmyan [Thu, 13 Mar 2014 01:07:47 +0000 (01:07 +0000)]
Remove dirty pixels from ASM be_blur output
A loop initializer was missing, so output started one row too early.
A loop condition check was missing, so output sometimes stopped
one column too late.
Oleg Oshmyan [Wed, 12 Mar 2014 22:06:28 +0000 (22:06 +0000)]
Fix handling of top two pixel rows in be_blur_c
5dd56af2 replaced our implementation of \be with xy-VSFilter's.
This error is not present in the xy-VSFilter code; it was introduced
by accident in a merge that was later squashed as part of 5dd56af2.
Note: the new \be reads in but does not write out
the first and last row and column of pixels.
wm4 [Thu, 6 Mar 2014 21:23:01 +0000 (22:23 +0100)]
Fix change detection in presence of vector clips
Fixes this test case:
Dialogue: 0,0:00:00.00,0:00:02.00,,,0,0,0,,{\fs50\pos(250,250)\iclip(m 0 0 l 400 0 l 400 220 l0 220)}Hello
Dialogue: 0,0:00:02.00,0:10:00.00,,,0,0,0,,{\fs50\pos(250,250)\iclip(m 0 0 l 400 0 l 400 230 l0 230)}Hello
The problem here is that the rendered output bitmap list itself does
not change, only its contents (due to the different vector clip).
ass_render_frame() will not set *detect_change correctly, and an
application using this flag (like mplayer or mpv) will not update
the screen as needed.
Fix this with a very cheap hack: always report a full change if
there's a vector clip. This is basically an emergency fix until
we have a proper way to detect the change.
wm4 [Mon, 3 Mar 2014 14:52:54 +0000 (15:52 +0100)]
Don't crash on \fscx0
Freetype can return a bounding box with all fields set to INT_MIN if an
outline with all points set to 0 is used. This can happen e.g. with
\fscx0, but also in more complicated cases. (In the original crashing
sample, this was probably caused in combination with an embedded font.)
Such a bounding box causes libass to crash, because it will enlarge the
combined bitmap bounding box to a ridiculous size.
Just skip outlines that have en empty bounding box. This is probably
the correct thing to do, and won't pass INT_MAX down to other parts
of libass.
Grigori Goronzy [Wed, 29 Jan 2014 04:23:55 +0000 (05:23 +0100)]
shaper: use global features correctly
start/end of feature tags is unsigned, so use the proper constant
to signal to HarfBuzz that these features are global. This allows
HarfBuzz to cache shape plans, and that can considerably speed up
shaping, especially if many small runs need to be shaped.
Grigori Goronzy [Sun, 26 Jan 2014 02:30:45 +0000 (03:30 +0100)]
shaper: rewrite and simplify harfbuzz shaping
Rewrite the core of the harfbuzz shaping function. Gets rid of the
MAX_RUNS limit of runs per line and reuses a single hb_buffer_t,
which should be more efficient.
wm4 [Mon, 20 Jan 2014 23:32:28 +0000 (00:32 +0100)]
Remove some ass_msg() calls
These aren't very useful for debugging due to the high volume of the log
output in problem cases. In fact, all they do is making the code slower
(the message callback can easily appear in the profiler output, even if
the callback doesn't actually print the messages).
Oleg Oshmyan [Tue, 7 Jan 2014 21:41:43 +0000 (23:41 +0200)]
Don't try to remove end-of-line \fsp
VSFilter does not do this.
The code being removed was already buggy: i > 0 should
have been "got any non-skipped glyphs since last_break?",
and hspacing should have been taken from glyphs[i-1].
Oleg Oshmyan [Tue, 7 Jan 2014 13:32:05 +0000 (15:32 +0200)]
Fix \pbo
b61d260b attempted to add support for \p scaling to \pbo.
However, while it fixed the exact sample originally reported,
it broke \pbo with other \p values, including \p1, by confusing
the direction of scaling and the units in which \pbo is measured.
In addition, the descenders assigned to drawings have always
had a wrong sign, causing lines that contain drawings with \pbo
to be shifted in the wrong direction: negative \pbo raised bottom-
aligned lines, while positive \pbo lowered top-aligned lines.
All errors and fixes have been confirmed with VSFilter.
Thomas Goyne [Wed, 11 Dec 2013 00:21:53 +0000 (16:21 -0800)]
Fix compilation with VC++ 2013
For whatever reason FT_Vector points[4] = { ... }; needs to come at the
beginning of a scope. Since that block was duplicated, just extract it
to a function.
This does not include buildsystem support, so actually compiling with
VC++ requires creating a project and supplying a config.h file.