ass_parse: remove 2 unused variables

Fallout from the previous commits.
configure.ac: Treat DragonFly as the rest of BSDs
Fix integer overflow in FT_Outline
Merge pull request #116 from hadvaid/dragonfly

configure.ac: Treat DragonFly as the rest of BSDs
Merge pull request #119 from MrSmile/fix-drawing-overflow

Fix integer overflow in FT_Outline
Fix \fade(7-argument version) parse
Implement LayoutResX/LayoutResY

This allows ASS scripts to be independent from video resolution.

Signed-off-by: Oleg Oshmyan <chortos@inbox.lv>
Do font supersampling the VSFilter way

To avoid jerking when font size scale is animated caused by grid
fitting, we intentionally request an overly large font size from
FreeType and downscale the outline afterwards.

Currently this large font size is fixed at 256.
This commit changes it to 64 times the actual wanted font size,
which is what is used by VSFilter. The advantages are:
  * Compatibility with VSFilter.
  * Support for font hinting, even if at 64 times the size.
    Knowing this coefficient, scripts can compensate
    for it by correspondingly decreasing \fs values.

This improves upon commits 7af7801 and c207000.

The drawback is that jerking is reintroduced when an mplayer
window with libass EOSD is resized. Jerking could be avoided
by scaling \fscx and \fscy instead of \fs. Pro: this would make
the exact look of the font completely resolution-independent.
Con: this would play badly with font hinting.
In any case, this commit makes no attempt to do this.

ensure_font_size, unused since 7af7801, is removed in favor
of clipping the font size just before passing it to FreeType,
as discussed in Google Code issue #46.
The mysterious height*2 check is dropped.
Scale \fscx/\fscy instead of \fs from storage to display resolution

This prevents jerking on media player window resize.
Make fix_outline always produce the correct final color

Whenever a glyph has a border, the original glyph's own ASS_Image
is applied on top of the border's ASS_Image. Let's mathematically
devise such alpha values for the border image that the resulting
colors exactly match (modulo rounding) the colors produced by a
hypothetical ASS_Image that contains both the glyph and the border.

Let a_i be the opacity of a single pixel within an ASS_Image,
where i is either g for glyph or o for outline (border). Further,
let A_i be the opacity and c_i the color of the entire ASS_Image.

Think of a_i as the _area_ covered by the glyph/border,
measured in pixels. We have 0 <= a_g <= a_o <= 1.
We also have 0 <= A_g, A_o <= 1.

We need a background color. Let's denote it as c_b. The background
color includes any effects from applying the shadow of the glyph.

The final color we want to achieve is:
  * on the area covered by the original glyph,
                                       A_g c_g + (1 - A_g) c_b.
  * on the area covered by the border, A_o c_o + (1 - A_o) c_b.
  * on the remaining area,             c_b.
Averaging the color over the pixel's area gives:
           a_g  (A_g c_g + (1 - A_g) c_b) +
    (a_o - a_g) (A_o c_o + (1 - A_o) c_b) +
      (1 - a_o)  c_b

The color we actually get after blending the border with the
background and then blending the original glyph with the result is:
        (A_g a_g) c_g +
    (1 - A_g a_g) ((A_o a_o) c_o + (1 - A_o a_o) c_b)

We want to replace a_o in the actual color's expression with a
value that makes it match the expected color. Let's call this value
a_o'. Equating both expressions and solving for a_o' gives:
       A_o (c_o - c_b) = 0 and a_o' does not matter
    or A_g a_g = 1 and a_o' does not matter
    or a_o' = (a_o - a_g) / (1 - A_g a_g)

In the A_o (c_o - c_b) = 0 case, we can always pick an a_o' that
satisfies one of the other two conditions. Effectively we can
ignore the first case altogether.

A_g a_g can only equal 1 if A_g = a_g = 1. Since a_g <= a_o <= 1,
a_o must also be 1. As it happens, libass already handles this case
separately: as a precaution, it checks that a_g < a_o and sets a_o'
to zero if this condition fails to hold. This works fine, so let's
retain this behavior.

This commit makes libass use the solution formula from the third
case to calculate a_o'. To enable this, the opacity of the original
glyph is passed to fix_outline and outline_to_bitmap3. Generated
bitmaps depend on it, so glyphs with different primary color alpha
are now distinguished by the bitmap cache. The calculation itself
is performed exactly and rounded correctly (half towards +infinity)
using only integer arithmetic.
Omit fully transparent glyphs from non-opaque-box shadows

If there is an outline around the transparent glyph,
the shadow is supposed to be a copy of this outline.

This completes the fix made in commit f9283004,
which covered the case where there is no outline.

Fixes Google Code issue #70.
Make fix_outline more correct in presence of blur

Blurred alphas are not coverage values. The area that is not
covered by the original glyph is a mix of the border and the
background, governed by the blurred border opacities. To get
an exact result, we need to integrate the blurred opacities
on fragments of pixels that exclude the original glyph (or,
equivalently, on fragments that are covered by it, as these
fragments are complementary). Unfortunately, we are unable
to do that.

Give up on exact values and treat each border pixel
as a uniform average that directly scales with area.
In fact, blur itself already does this.

Note that we can now get non-zero opacities even when the
glyph's coverage is larger than the border's uncorrected
opacity.

Writing and solving equations like before, we obtain:
       A_o (c_o - c_b) = 0 and a_o' does not matter
    or A_g a_g = 1 and a_o' does not matter
    or a_o' = (a_o - a_g a_o) / (1 - A_g a_g)
Handle the first case like the third,
and handle the second case by setting a_o' = 0.

The observable difference for non-blurred bitmaps
was not large in my tests, but the code is simple,
so the exact non-blurred calculations are retained.