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 shifted in
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
On Thu, Jul 14, 2011 at 12:00 PM, Werner LEMBERG w...@gnu.org 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
On Sat, Jul 9, 2011 at 12:53 AM, Werner LEMBERG w...@gnu.org 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
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] 16
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
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];
+
+ 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.
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];
skip
+ {
+AF_CJKBlue blue;
+
skip
+ blue = axis-blues[AF_CJK_BLUE_TOP];
skip
+ blue =
On Mon, Apr 25, 2011 at 10:34 AM, mpsuz...@hiroshima-u.ac.jp 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 */
/*
On Wed, Apr 6, 2011 at 12:46 AM, Werner LEMBERG w...@gnu.org 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 James
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
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 that
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
I think I can get though to this guy...
2010/11/12 David Bevan david.be...@pb.com:
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
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,
Graham
- Original Message
From: Алексей Подтележников apodt...@gmail.com
To: freetype-devel
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.
attachment:
On Mon, Nov 1, 2010 at 2:44 PM, Werner LEMBERG w...@gnu.org 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
Алексей Подтележников apodt...@gmail.com:
On Sun, Oct 17, 2010 at 4:53 AM, Werner LEMBERG w...@gnu.org 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
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: Алексей Подтележников apodt...@gmail.com
To: freetype-devel freetype-devel@nongnu.org
On Mon, Oct 18, 2010 at 10:47 AM, Werner LEMBERG w...@gnu.org 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
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
2010/10/14 David Bevan david.be...@pb.com:
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
of 1/64 of a pixel.
Best regards,
Graham
- Original Message
From: Алексей Подтележников apodt...@gmail.com
To: freetype-devel freetype-devel@nongnu.org
Sent: Wednesday, 13 October, 2010 2:25:40
Subject: [ft-devel] FT_MAX_CURVE_DEVIATION vs ONE_PIXEL
Guys,
Currently smooth
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 graham.as...@btinternet.com:
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
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.
27 matches
Mail list logo
