Unfortunately not only there but in the rasterizer, if memory serves.
They were not in any place where I could get rid of them easily by
disabling certain features.
Graham
Behdad Esfahbod wrote:
On 06/10/2010 05:17 AM, Graham Asher wrote:
Doing this showed that setjmp and longjmp are not
On 06/10/2010 05:17 AM, Graham Asher wrote:
> Doing this showed that setjmp and longjmp are not necessary for
> FreeType;
Indeed. They are only used for error-handling in the validator modules.
behdad
___
Freetype-devel mailing list
Freetype-devel@non
On 06/10/2010 05:17 AM, Graham Asher wrote:
> Doing this showed that setjmp and longjmp are not necessary for
> FreeType;
Indeed. They are only used for error-handling in the validator modules.
behdad
___
Freetype-devel mailing list
Freetype-devel@non
No, I don't think it's worth worrying about this right now. I worked on
this because I wanted to create a version of my CartoType library as a
portable .NET assembly, and in fact I managed to compile CartoType as
C++/CLI code, which is a tribute to its robustness; but to do that I had
to remove
> [...] I use a modified version of FreeType that can be compiled as
> pure .NET intermediate language code; and to do that I had to get
> rid of setjmp and longjmp; incidentally, with no performance penalty
> and little extra complexity.
Is this something we should consider in general? I mean,
You're welcome - I see that you had to get rid of a check on the return
value of gray_render_line, which I forgot about. That is there because I
use a modified version of FreeType that can be compiled as pure .NET
intermediate language code; and to do that I had to get rid of setjmp
and longjmp
> here's what I think is a better version of the start of the
> function. [...]
This is now in the git repository (with small fixes to make it
compile).
Thanks a lot! Please test.
Werner
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
>>This is something Ken can probably check: He has a large database
>>for Ghostscript to compare rendering results, and artifacts
>>introduced by the simplified shorthand calculation would easily show
>>up, I think.
>
> I'd like to be able to, but at the moment GS doesn't use FreeType
> for anti-a
Werner,
here's what I think is a better version of the start of the function.
I've combined a few declarations and initialisations; probably against
your house style, so please adjust as appropriate if you don't like it.
Important changes: (i) dx is now divided by ras.cubic_level; (ii) mid_x
Another question arises: why do we divide by ras.conic_level when we are
dealing with cubic splines? Surely it should be
dx= dx / ras.cubic_level;
or (better - we can use assignment operators in FreeType, I think ;-):
dx/= ras.cubic_level;
Graham
Werner LEMBERG wrote:
Calculate t
Werner,
I think your patch is slightly wrong because you use the same values for
mid_x and mid_y for both the comparison and for drawing; however, one
set if values needs to go through DownScale() and the other through
UpScale(); that's why I calculate separately in my hastily-prepared
patch.
At 10:04 08/06/2010 +0200, Werner LEMBERG wrote:
> I am sceptical about the need to calculate both da and db. Perhaps
> db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably check: He has a large database for
Ghostscript to compare rendering results
> Calculate the midpoint and compare it with start and end: [...]
For me, this looks good. Thanks for working on this.
> I am sceptical about the need to calculate both da and db. Perhaps
> db only will suffice. I hope that David or Werner can comment.
This is something Ken can probably chec
Correction (sorry, but this stuff gets confusing). Section 6 should
read:
6. A POSSIBLE BETTER FIX
Calculate the midpoint and compare it with start and end:
{
int mid_x = (DOWNSCALE( ras.x ) + to->x + 3 * (control1->x + control2->x)) / 8;
int mid_y = (DOWNSCALE( ras.y ) + to->y + 3 * (cont
14 matches
Mail list logo