freetype-commit
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[freetype2] master 971f10b: Formatting.


From: Werner LEMBERG
Subject: [freetype2] master 971f10b: Formatting.
Date: Fri, 8 Jul 2016 04:59:41 +0000 (UTC)

branch: master
commit 971f10b63a6685b7c40737cb5629e0a853ae3b17
Author: Werner Lemberg <address@hidden>
Commit: Werner Lemberg <address@hidden>

    Formatting.
---
 ChangeLog            |   32 ++++++++++++++++----------------
 src/smooth/ftgrays.c |    2 +-
 2 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index e5bbe83..199ed91 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -2,25 +2,25 @@
 
        [smooth] Sub-banding protocol revision.
 
-       Rasterization sub-banding is utilized at large sizes while using
-       rather small fixed memory pool. Indeed it is possible to make an
+       Rasterization sub-banding is utilized at large sizes while using a
+       rather small fixed memory pool.  Indeed it is possible to make an
        educated guess how much memory is necessary at a given size for a
-       given glyph. It turns out that, for large majority of European glyphs,
-       you should store about 8 times more boundary pixels than their height.
-       Or, vice versa, if your memory pool can hold 800 pixels the band
-       height should be 100 and you should sub-band anything larger than
-       that. Should you still run out of memory, FreeType bisects the band
-       but you have wasted some time. This is what has been implemented in
-       FreeType since the beginning.
-
-       It was overlooked, however, that the top band could grow to twice the
-       default band size leading to unnecessary memory overflows there. This
-       commit fixes that. Now the bands are distributed more evenly and
-       cannot exceed the default size.
+       given glyph.  It turns out that, for a large majority of European
+       glyphs, you should store about 8 times more boundary pixels than
+       their height.  Or, vice versa, if your memory pool can hold 800
+       pixels the band height should be 100 and you should sub-band
+       anything larger than that.  Should you still run out of memory,
+       FreeType bisects the band but you have wasted some time.  This is
+       what has been implemented in FreeType since the beginning.
+
+       It was overlooked, however, that the top band could grow to twice
+       the default band size leading to unnecessary memory overflows there.
+       This commit fixes that.  Now the bands are distributed more evenly
+       and cannot exceed the default size.
 
        Now the magic number 8 is really suitable for rather simple European
-       scripts. For complex Chinese logograms the magic number should be 13
-       but that is subject for another day.
+       scripts.  For complex Chinese logograms the magic number should be
+       13 but that is subject for another day.
 
        * src/smooth/ftgrays.c (gray_convert_glyph): Revise sub-banding
        protocol.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 12df14d..0bf3ac6 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -1911,7 +1911,7 @@ typedef ptrdiff_t  FT_PtrDist;
     min   = ras.min_ey;
     max_y = ras.max_ey;
 
-    for (; min < max_y; min = max )
+    for ( ; min < max_y; min = max )
     {
       max = min + band_size;
       if ( max > max_y )



reply via email to

[Prev in Thread] Current Thread [Next in Thread]