> To look from the machine POV: There are logical and arithmetical shift
> instructions. The logical ones to the right thing for unsigned
> numbers, the arithmetical for signed ones. If shifting to the left,
> both are identical. If shifting right, the difference is whether the
> new bits shifte
On Thu, Jul 14, 2011 at 12:00 PM, Werner LEMBERG wrote:
>
> Here's the answer from Matthias.
>
>> 1) Fix2Int does shift before conversion. How does it solve the
>> undefined behavior with negative numbers?
>
> After the shift, the upper half is undefined.
This is wrong. Undefined means undefi
Werner,
Three questions regarding recent psaux commits:
1) Fix2Int does shift before conversion. How does it solve the
undefined behavior with negative numbers?
2) Why not (FT_Int)(FT_UInt)?
3) Is Fix2Int conversion shared with other parts of freetype?
Thanks,
Alexei
_
Werner,
What do you know about this one: CVE-2011-1908?
Is this the same issue or an older one?
Alexei
On Sun, Jul 10, 2011 at 1:09 AM, Werner LEMBERG wrote:
>
>> Moving error check down to default, where it belongs
>
> Applied, thanks.
>
>
> Werner
>
--
Alexei A. Podtelezhnikov, PhD
_
Moving error check down to default, where it belongs
diff --git a/src/psaux/t1decode.c b/src/psaux/t1decode.c
index a60ec38..f015e47 100644
--- a/src/psaux/t1decode.c
+++ b/src/psaux/t1decode.c
@@ -686,9 +686,6 @@
subr_no = (FT_Int)( top[1] >> 16 );
arg_cnt = (FT_Int)( top[0] >>
On Sat, Jul 9, 2011 at 12:53 AM, Werner LEMBERG wrote:
>
>> I would have this check under default: on line 1013 because other
>> cases have good checks already.
>
> But the `default' label continues, while `Unexpected_OtherSubr'
> aborts...
Again, good "cases" do not need this check because they
I would have this check under default: on line 1013 because other
cases have good checks already.
That default is rather strange : "wish me luck". Really?
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
https://lists.nongnu.org/mailman/listinf
In the following code, you should have reused 'blue_t' and 'blue_b'
+ blue_t = &axis->blues[AF_CJK_BLUE_TOP];
+ blue_b = &axis->blues[AF_CJK_BLUE_BOTTOM];
+ {
+AF_CJKBlue blue;
+
+ blue = &axis->blues[AF_CJK_BLUE_TOP];
+ blue = &axis->blues[AF_CJK_BLUE_
+ if ( delta_t > 0 && delta_b > 0&& /* rounded to floor. */
+ delta_sum >= 32 && delta_sum <= 64 &&
+ delta_t <= 32&& delta_b <= 32 )
Here, delta_sum <= 64 condition is superfluous, given that delta_sum =
delta_t + delta_b.
__
Why do you even create and calculate temporary shoot_delta?
You can explicitly increment/decrement blue->shoot.fit the same way
you do blue->ref.fit.
Like this:
+AF_CJKBlue blue;
+
+if ( delta_t >= delta_b )
+{
+ blue = &axis->blues[AF_CJK_BLUE_TOP];
+ bl
2011/4/25 suzuki toshiya :
> Thank you for advice, but the algorithm would be "OR", so, considering
> the proposal of Kan-Ru Chen, the unified conditional would be:
>
> if ( (face->family_name && tt_check_trickyness_family( face->family_name )) ||
> tt_check_trickyness_sfnt_ids( (TT_Face)face )
On Mon, Apr 25, 2011 at 10:34 AM, wrote:
> so I will apply your patch.
You wrapped two nested if-conditions into one with &&.
It could be wrapped with the preceding if-condition further.
/* Type42 fonts may lack `name' tables, we thus try to identify */
/* tricky fonts by checking th
On Wed, Apr 6, 2011 at 12:46 AM, Werner LEMBERG wrote:
>>> In most circumstances, I fully agree. However, the new code looks
>>> like voodoo to me
>>
>> If it was a Freetype-specific core piece to be cherished as a mural,
>> I'd side with Werner. But is it so special?
>
> If I've understood Jame
Werner,
A more complete fix should include this patch. It removes a spurious shortcut.
Because it is spurious, I overlooked ONE_PIXEL / 4 there.
It also switches to a more natural do-while and removes unnecessary "return;"
My planned harmonization with the cubic is postponed indefinitely or
by a
2011/3/6 Werner LEMBERG :
>
>> You may want to fiddle with line 900 in ftgrays.c
>>
>> while ( dx > ONE_PIXEL / 4 )
>>
>> make it
>>
>> while ( dx > ONE_PIXEL / 6 )
>
> Indeed, this makes the rendering almost equal to the previous result.
> I favor this solution as a quick fix �#| I consider th
Werner,
All arches seem to have lost weight. It is possible that the conic
Bezier flattener
is not splitting enough. You may want to fiddle with line 900 in ftgrays.c
while ( dx > ONE_PIXEL / 4 )
make it
while ( dx > ONE_PIXEL / 6 )
But again, this is not the solution I like. I still think tha
for it.
>
> Also, you don't help your case at all by remarks like "I think I can get
> though
> to this guy..." and "It's only you and me who understand these conditions."
> which are at best patronising and at worst impolite.
>
> Best regards,
I think I can get though to this guy...
2010/11/12 David Bevan :
> I've just had a brief chance to look at your proposal, and I now understand
> why it makes no difference to the output. The chances of your relaxed
> condition causing a split when the current (theoretically correct) condition
I am really annoyed by run-arounds and overzealous protection of code
by authors.
I was proposing a minor benign improvement. I am touching the water so to
speak. What's the big deal? Way to attract developers, freetypers! You go!
___
Freetype-devel mai
Shaded areas "Before" and "After" in the attached figures show
where control points have should be to permit flattening.
Is this a risky change? If anything, it is slightly more conservative,
yet the conditional is quite a bit simpler.
<>___
Freetype-deve
2010/11/9 GRAHAM ASHER :
> <<
> There is no gain or loss in speed and the quality is the same
>>>
>
> In that case the patch should not be applied. Any change but the very simplest
> has some risk. Risk should only be undergone if there is demonstrable benefit.
I was running this patch for
On Mon, Nov 1, 2010 at 2:44 PM, Werner LEMBERG wrote:
>
>> Ok. I'm resending the non-intrusive patch as an attachment. The
>> intrusive harmonization of the conic and cubic splines is to follow
>> in a separate thread.
>
> I'm going to apply your patch. However, you are changing ONE_PIXEL/8
> bac
Алексей Подтележников :
> On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG wrote:
>>> It turns out that since 2.4.3 the cubic deviations have been
>>> estimated *after* UPSCALE, whereas conic ones have been evaluated
>>> *before* UPSCALE. This was probably the original
On Mon, Oct 18, 2010 at 10:47 AM, Werner LEMBERG wrote:
> Is it? I can imagine that two completely different algorithms are
> best. Cubic and conic curves *are* different beasts...
.. but I managed to quite successfully use essentially the same algorithm
for both.
Regardless of our disagreemen
rom the actual curve; that can be adjusted using the existing
> algorithm, in any case. The aim of code improvement in this area is to improve
> speed while preserving quality.
>
> Graham
>
>
>
>
> - Original Message
> From: Алексей Подтележников
> To: freet
Werner,
This patch harmonizes the algorithms that are used for flattening
conic and cubic splines.
It changes the conic ones to follow the same (more correct) procedure
as cubic ones.
The result, I think, is a better code and a slight improvement in
quality. You may see about
3% slow-down, but th
On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG wrote:
>> It turns out that since 2.4.3 the cubic deviations have been
>> estimated *after* UPSCALE, whereas conic ones have been evaluated
>> *before* UPSCALE. This was probably the original sin that led to
>> the misuse of FT_MAX_CURVE_DEVIATION t
Werner, Graham
It turns out that since 2.4.3 the cubic deviations have been estimated
*after* UPSCALE, whereas conic ones have been evaluated *before*
UPSCALE. This was probably the original sin that led to the misuse of
FT_MAX_CURVE_DEVIATION that we've just fixed in "cubic".
Let's fix the origin
2010/10/14 David Bevan :
> Since there are two changes, (the value of FT_MAX_CURVE_DEVIATION and the
> algorithm),
> each must be tested independently.
David,
Focus please. This thread is about fixing deviations only by using ONE_PIXEL.
>>
>>
>> diff --git a/src/smooth/ftgrays.c b/src/smooth/f
is code works in units of 1/64 of a pixel.
>
> Best regards,
>
> Graham
>
>
>
> - Original Message
> From: Алексей Подтележников
> To: freetype-devel
> Sent: Wednesday, 13 October, 2010 2:25:40
> Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
>
Guys,
Currently smooth/ftgrays.c contains this:
/* The maximum distance of a curve from the chord, in 64ths of a pixel; */
/* used when flattening curves. */
#define FT_MAX_CURVE_DEVIATION 16
and this:
/* must be at least 6 bits! */
#define PIXEL_B
Graham, David,
The patch below does away with cute (as in octagon) but complex estimate
of Euclidean length in favour of straightforward Manhattan distance.
Who says that we have to religiously use Euclidean metrics? As a bonus,
the code runs faster The speed up of course comes from fewer splits
Graham,
2010/10/3 Graham Asher :
> there's a chance it might help at high resolutions where more than one band
> is needed.
True, I have nothing to show for it besides correctness.
The speed up is barely visible. Is 72 enough to cross bands?
BEFORE: ftbench -b c -s 72 /mnt/windows/WINDOWS/Fonts/
Hello,
While you guys are on the subject of better splines. I propose to fix
grey_render_conic too. I think that interpreting the control point as a
corner is a simplistic overestimation. A little algebra gives the
exact boundary position.
Nothing breaks at the firsts glance in my testing. Whethe
34 matches
Mail list logo
