This patch is a trivial move of band check out of the loop in the
cubic flattener.
The arcs resulting from any split are always smaller than the original.
If the original is inside the band, the children are inside by definition,
so there is no need to loop this rather long check.
I am working on
Same thing for conic. Children arcs are small than the parent. If the
parent fits in the band, children do too.
A tiny off by one correction is a bonus.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 40de269..0e26d7b 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@
This is a final version of the patch that optimizes both conic and
cubic flatteners. Polished and tested.
Please consider.
diff --git a/src/smooth/ftgrays.c b/src/smooth/ftgrays.c
index 40de269..2b90571 100644
--- a/src/smooth/ftgrays.c
+++ b/src/smooth/ftgrays.c
@@ -872,6 +872,7 @@ typedef
On Tue, Sep 13, 2011 at 1:49 PM, Werner LEMBERG w...@gnu.org wrote:
This means that FreeType is fine and DejaVuSans's hinting at 4ppm is
buggy. :-) Due to the `gasp' table, this is a non-issue anyway.
It cannot be both non-issue and buggy font.
No blame for ftview and its handling of gasp?
I think you can pack the bin better if you start from the largest
size. There is tons of empty space at the bottom that could easily be
filled with small glyphs. Or go bottom-up for more natural fill. In
other words, I bet you can pack more glyphs into 512x512.
I am not sure I understood how you
On 30/10/2011 08:25, Vivek Rathod wrote:
according to Hain's paper
dmax = (s/L) * dnorm ; here s is not normalized. dmax is the tolerance for
flatness and dnorm is the normalized flatness of the curve.
so s_limit = (dmax / dnorm) * L ; by putting dnorm = 0.75 we get the
permissible height
On Mon, Oct 31, 2011 at 3:22 AM, Vivek Rathod vivekmrat...@gmail.com wrote:
s is calculated as
s = FT_ABS( dy * dx1 - dx * dy1 ); which means s is the perpendicular
distance of the control point from chord multiplied by L
which means currently s_limit is being compared with perpendicular
On Mon, Oct 31, 2011 at 7:43 AM, Vivek Rathod vivekmrat...@gmail.com wrote:
The formula for deviation ( from Hein's paper).
d = dnorm * s ; here s is normalized --- (1)
so the formula when s is not normalized becomes d = dnorm * (s / L) ;
-(2)
and I think the
pixel-by-pixel shape.
Therefore, we *always* tolerate a constant fraction of ONE_PIXEL no matter
how long the arch is.
Alexei
On Mon, Oct 31, 2011 at 7:51 AM, Alexei Podtelezhnikov
apodt...@gmail.com wrote:
On Mon, Oct 31, 2011 at 7:43 AM, Vivek Rathod vivekmrat...@gmail.com wrote
The problem that your description starts with long cumbersome condition.
Start description with what the flag actually does:
FT_ADVANCE_FLAG_FAST_ONLY:
. Enable quick retrieval of advance in the special cases of
- unhinted (FT_LOAD_NO_HINTING),
- lightly hinted (FT_RENDER_MODE_LIGHT),
On Fri, Jan 13, 2012 at 2:13 PM, Werner LEMBERG w...@gnu.org wrote:
3. Grant of Patent License.
Do freetype authors hold or have they filed for a patent? Don't you
need it first before granting any patent license? This is one strange
and curious discussion thread without a patent at
On Wed, Feb 8, 2012 at 11:36 PM, Werner LEMBERG w...@gnu.org wrote:
I believe there is discrepancy between what's written in ftgrays.c
and its actual functioning. It is said it computes the _exact_
coverage of the outline on each pixel cell. But the following
program shows this is not true.
Werner,
It seems to me that the autofit module reverses the direction of
outlines originating from Type 1 fonts
without resetting FT_OUTLINE_REVERSE_FILL bit back to 0.
Alexei
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
Hi all,
Attached is a small program that demonstrates how freetype loses
outline flags during auto-hinting.
This is a demonstration:
$ ./outflags /usr/share/fonts/liberation/LiberationSerif-Regular.ttf 0x2
Liberation Serif Regular loaded...
Loading Flags: 0x2
Outline Flags: 0x100
$ ./outflags
On Thu, Feb 16, 2012 at 2:07 AM, Werner LEMBERG w...@gnu.org wrote:
This is a bug. Reason is that the autohinter doesn't preserve this
flag while copying around the outlines (in function af_loader_load_g).
There are two possibilities to fix this. One of them is to extend
FT_GlyphLoader_Add
On Thu, Feb 16, 2012 at 2:07 AM, Werner LEMBERG w...@gnu.org wrote:
This is a bug. Reason is that the autohinter doesn't preserve this
flag while copying around the outlines (in function af_loader_load_g).
This safe patch fixes it for me.
diff --git a/src/autofit/afloader.c
To be honest, I am perplexed by this amalgamation exercise.
All of this apparently needed because some obscure in-house
tool does not know how to resolve the name conflicts.
Teach the damn tool how to resolve the name conflicts
by adding prefixes or suffixes!
Why do you butcher perfectly legal
You again manage to present this as a legitimate goal :)
It is your tool that breaks the code :) You are not fooling me here.
Again, I'll say that this is just such a bizarre objective that
you HAVE TO justify this and tell which platform on Earth
needs it. Remember it has to be a platform which
On Mon, Feb 20, 2012 at 5:45 PM, Werner LEMBERG w...@gnu.org wrote:
Again, I'll say that this is just such a bizarre objective that you
HAVE TO justify this and tell which platform on Earth needs it.
??? It's not related to a specific platform at all. It's a matter of
an easy way to
How about a shared header file if those modules share a structure?
Don't you see that this patch set is just a pile of pure stinking crap???
On Tue, Feb 21, 2012 at 9:56 AM, Vinnie thev...@yahoo.com wrote:
Werner:
2012-02-20 Vinnie Falco vinnie.fa...@gmail.com
ftgrays.c, ftraster.c:
On Tue, Feb 21, 2012 at 10:44 AM, Vinnie thev...@yahoo.com wrote:
Date: Tue, 21 Feb 2012 08:02:43 -0500
From: Alexei Podtelezhnikov apodt...@gmail.com
You planing this for Stone Age people who do not know how to use
make. I rest my case.
Actually, that is true.
My target audience
On Tue, Feb 21, 2012 at 11:03 AM, Chris Morgan chmor...@gmail.com wrote:
Hey. This kind of response isn't cool man.
If Vinnie's patches disambiguate and otherwise clarify the code then
they are good changes, even if it enables him to do things that we
find odd.
There is nothing ambiguous in
On Tue, Feb 21, 2012 at 11:54 AM, Vinnie thev...@yahoo.com wrote:
From: Alexei Podtelezhnikov apodt...@gmail.com
Sent: Tuesday, February 21, 2012 8:28 AM
It is hard to believe that there are people who'll dive into font rendering
without first learning how to use multiple files
On Fri, Feb 24, 2012 at 4:05 AM, pravin@gmail.com
pravin@gmail.com wrote:
Lohit Devanagari does not have Bold variant and presently using auto bold
algorithm. It does not work correctly in gnome see
http://pravins.fedorapeople.org/Screenshot.png
Can someone given me pointer that
On Fri, Feb 24, 2012 at 9:54 PM, suzuki toshiya
mpsuz...@hiroshima-u.ac.jp wrote:
I think there are 2 issues in auto-embolden Lohit Devanagari;
a) disconnection of horizontal strokes (which should be connected with
previous/next glyph)4.8
It looks like advance value is incorrectly adjusted
On Mon, Feb 27, 2012 at 2:12 AM, pravin@gmail.com
pravin@gmail.com wrote:
On 27 February 2012 07:58, Alexei Podtelezhnikov apodt...@gmail.com wrote:
mpsuz...@hiroshima-u.ac.jp wrote:
I think there are 2 issues in auto-embolden Lohit Devanagari;
a) disconnection of horizontal strokes
On Mon, Feb 27, 2012 at 10:41 AM, pravin@gmail.com
pravin@gmail.com wrote:
On 27 February 2012 19:36, Alexei Podtelezhnikov apodt...@gmail.com wrote:
On Mon, Feb 27, 2012 at 2:12 AM, pravin@gmail.com
pravin@gmail.com wrote:
On 27 February 2012 07:58, Alexei Podtelezhnikov
On Mon, Feb 27, 2012 at 12:17 PM, Antoine Leca
antoine-freet...@leca-marti.org wrote:
Alexei Podtelezhnikov wrote:
In this particular font the glyph width is larger than it advance,
which is unusual.
... but it is typical of Devanagari fonts, and in general of several
hanging scripts, where
ftstring is supposed to be an exemplar string renderer for other
libraries because it handles lsb_delta and rsb_delta. This is short of
kerning but at least it is better than ftview. Unfortunately,
auto-emboldened fonts are not a part of ftstring's functionality. So
other libraries could not copy
On Wed, Mar 14, 2012 at 7:26 AM, Huw Davies h...@codeweavers.com wrote:
The attached patch fixes a problem with fonts that include a trailing
'\0' in name table entries. Currently the font name would have a
question mark appended to it.
Why would the name contain \0?
Is this because
In memory of Paul Alexi
The attached patch is a rework of outline emboldening.
1) It introduces uneven emboldening in x- and y-direction. I
understand that the straight change in API is not going to fly but I
really do not want to introduce a separate
A testable version of the patch is attached. At the end I decided to
introduce a new interface FT_Outline_EmboldenXY. Comments?
faster-embolden.patch
Description: Binary data
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
On Sat, Mar 31, 2012 at 12:50 AM, Werner LEMBERG w...@gnu.org wrote:
A testable version of the patch is attached. At the end I decided to
introduce a new interface FT_Outline_EmboldenXY. Comments?
From a quick glance, this looks like a good solution, thanks! I will
have to test and check
On Tue, Apr 3, 2012 at 9:05 AM, Peter Hurley pe...@hurleysoftware.com wrote:
Werner LEMBERG wrote:
We had report of regression in GTK markups rendering in Ubuntu
precise, (i.e ulabel/u would render underlined), [...]
AFAIK, the problem is in gtk. For years, FreeType had this metrics
In memory of Paul Alexi
As a way of ping, I going to throw in a much simpler
FT_Outline_Get_Orientation patch. So the whole collection of three
patches now looks like the attached. Comments, suggestions?
Alexei
faster-embolden.patch
Description: Binary
On Tue, Apr 10, 2012 at 2:00 AM, Werner LEMBERG w...@gnu.org wrote:
As a way of ping, I going to throw in a much simpler
FT_Outline_Get_Orientation patch. So the whole collection of three
patches now looks like the attached. Comments, suggestions?
Thanks a lot for your work! Everything
On Tue, Apr 10, 2012 at 11:54 AM, Behdad Esfahbod beh...@behdad.org wrote:
I like the area-based algorithm. I had to implement outline orientation code
recently and I wish I had remembered that algorithm!
What I found in testing my implementation was that fonts don't have consistent
contour
On Tue, Apr 10, 2012 at 3:02 PM, Behdad Esfahbod beh...@behdad.org wrote:
Humm. The docs say:
/* FT_OUTLINE_EVEN_ODD_FILL :: */
/* By default, outlines are filled using the non-zero winding rule. */
/* If set to 1, the outline will be
Werner et al.,
In the current incarnation, FT_Outline_Get_Orientation cannot possibly
return FT_ORIENTATION_NONE, in spite of what the documentation
suggests. The return values are simply conditioned as !=
FT_ORIENTATION_NONE.
FT_ORIENTATION_NONE is supposed to mean CANNOT BE DETERMINED, which
On Wed, Apr 18, 2012 at 2:18 PM, Werner LEMBERG w...@gnu.org wrote:
FT_ORIENTATION_NONE is supposed to mean CANNOT BE DETERMINED, which
is easier said than done. Any contour has a well defined orientation
as a sign of the area it covers: plus or minus. It is only the
degenerate contours or the
On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote:
When we talk about an outline as a collection of contours, things get
out of control very quickly, because to do a good job you have to
inspect the whole layout
On Tue, Apr 24, 2012 at 4:25 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 04/20/2012 11:59 AM, Alexei Podtelezhnikov wrote:
On Thu, Apr 19, 2012 at 2:12 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 04/18/2012 01:36 PM, Alexei Podtelezhnikov wrote:
When we talk about an outline
On Mon, May 28, 2012 at 5:12 PM, Werner LEMBERG w...@gnu.org wrote:
As a way of ping, I going to throw in a much simpler
FT_Outline_Get_Orientation patch. So the whole collection of three
patches now looks like the attached. Comments, suggestions?
I've applied all three patches. Sorry for
On Wed, May 30, 2012 at 3:34 AM, Werner LEMBERG w...@gnu.org wrote:
Well, I've read that that Apple is going to sell
iBooks with `retina displays' soon, with really impressive DPI values,
and I suspect that other companies will provide similar things, which
is good!
Let me steer this
This is clearly a bug in BW rasterizer. Can you help to git bisect it?
You know two versions with and without a bug.
On Thu, May 31, 2012 at 10:38 AM, jola hans-jochen@lhsystems.com wrote:
To make use of new API (kerning etc.) I upgraded from FT 2.1.10 to FT 2.4.8
and then 2.4.9. When
On Mon, Jun 4, 2012 at 4:38 AM, jola hans-jochen@lhsystems.com wrote:
the bug was obviously introduced with the transition from 2.3.12 (working)
to 2.4.0 (showing the bug). HTH.
The only potential change in question is this:
On Tue, Jun 5, 2012 at 7:20 AM, jola hans-jochen@lhsystems.com wrote:
Alexei Podtelezhnikov-2 wrote:
The only potential change in question is this:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7baeeafcec7fd2267191937e14c1f753424beb89
It was supposed to fix bug
On Wed, Jun 6, 2012 at 7:25 AM, Werner LEMBERG w...@gnu.org wrote:
The only potential change in question is this:
http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=7baeeafcec7fd2267191937e14c1f753424beb89
Your guess was not wrong! This morning I repeated the tests, I had
On Wed, Jun 6, 2012 at 10:18 AM, Werner LEMBERG w...@gnu.org wrote:
[...] let's bring FT_GlyphSlot_Embolden in agreement with what
ftview does. This removes too much width that used to be added to
the emboldened glyphs.
Thanks. Do you have time to provide some documentation also?
Sure.
On Wed, Jun 13, 2012 at 9:22 AM, Werner LEMBERG w...@gnu.org wrote:
It's probably a good idea to fix Rx also. What about this:
old:
Rx = ( ras.precision * Dx ) % Dy;
new:
Rx = ( ( ras.precision % Dy ) * ( Dx % Dy ) ) % Dy;
Let's not rush with this and just say that your fix
On Fri, Jun 15, 2012 at 5:31 PM, Infinality infinal...@infinality.net wrote:
Sorry to resurrect an old thread here, but I think I have a solution that
preserves the addition of Y-weight at larger font sizes, while still keeping
the blur to a minimum:
In FT_Outline_Embolden (which is now
think that rounding the emboldening strength is sufficient, you
must assume that the original outline is already well hinted, which is
just wrong. There is no way you can shortcut the hinting like that.
On 06/16/2012 10:07 PM, Alexei Podtelezhnikov wrote:
On Fri, Jun 15, 2012 at 5:31 PM
On Mon, Jun 18, 2012 at 4:38 AM, Werner LEMBERG w...@gnu.org wrote:
The patch is now in the repository. Thanks a lot!
I am not sure why Round_To_Grid and its family are modified but not
used. I am actually more concerned with the way they are modified.
Things like this look dangerous:
- val =
I really dislike how you disabled hinting in the x-direction. You
essentially replaced '64' in the rounding functions with '64 / 64',
aka '1'. This is brutal and takes a performance toll on this part of
the code even when your subpixel hinting is not used. I strongly
suggest that you just
On Mon, Jun 18, 2012 at 9:52 AM, Infinality infinal...@infinality.net wrote:
On 06/18/2012 08:40 AM, Werner LEMBERG wrote:
I really dislike how you disabled hinting in the x-direction. [...]
Thanks for your reviews, and please continue. I'm sure Erik will
collect them all :-)
Note that I
In memory of Paul Alexi
Hi all,
The attached patch changes the way 'ftview' fills the window with
glyphs so that the right margin is less blank and a larger number of
glyphs shown. It uses the actual width of the current grBitmap,
instead of super
The attached patch changes the way 'ftview' fills the window with
glyphs so that the right margin is less blank and a larger number of
glyphs shown. It uses the actual width of the current grBitmap,
instead of super conservative max_advance, when fitting the glyphs
in the available space.
On Wed, Jun 27, 2012 at 8:33 AM, Werner LEMBERG w...@gnu.org wrote:
I've picked FT_Err_Raster_Overflow to indicate the boundary. Is
that appropriate?
No, it isn't IMHO: FT_Err_Raster_Overflow is a fatal error, indicating
a serious problem which the rasterizer can't manage. I think a simple
On Wed, Jun 27, 2012 at 1:22 PM, Werner LEMBERG w...@gnu.org wrote:
[...] the drawing functions ultimately inherit the error codes from
FT_Glyph_To_Bitmap currently. Therefore it has to be something
different from those defined in fterrdef.h to distinguish. It would
be good if freetype
On Tue, Jul 3, 2012 at 2:58 PM, Werner LEMBERG w...@gnu.org wrote:
widths which are different less than or equal to 1% of the em size
are unified; this is certainly not noticeable visually.
1/64 is better heuristic than 1%. Why not avoid costly division with
divide by 64 instead.
I doubt
On Tue, Jul 3, 2012 at 6:08 PM, Werner LEMBERG w...@gnu.org wrote:
The attached patch returns the error code 0xFF when the margin is
crossed and leaves 3 pixels blank at the right margin.
I've just tested it, and it fails for fonts which can't be emboldened
(for example, BDF). Besides that,
Hi All,
I'd like to introduce adjustable stroking radius to ftview
functionalities. This is a patch. Please comment.
diff --git a/src/ftview.c b/src/ftview.c
index 0b7bcbd..59dd8cc 100644
--- a/src/ftview.c
+++ b/src/ftview.c
@@ -77,6 +77,7 @@
double gamma;
double
On Sat, Aug 18, 2012 at 3:22 AM, Werner LEMBERG w...@gnu.org wrote:
I'd like to introduce adjustable stroking radius to ftview
functionalities. This is a patch. Please comment.
Thanks; this looks simple and straightforward. Please install.
BTW, what about using integer numbers for slant
Is this because we ran out of FT_LOAD_XXX space? We used to control
Freetype with flags, now it is this API.
Potentially this is more flexible Freetype3 material.
Any plans for Freetype3? It's been 12 years. Is it time yet for a
spring cleaning?
___
On Wed, Aug 29, 2012 at 11:45 AM, Werner LEMBERG w...@gnu.org wrote:
Any plans for Freetype3? It's been 12 years. Is it time yet for a
spring cleaning?
Since I'm very bad at API design, I won't start such a project, but
you are very welcome to discuss potential improvements, and it's very
Please don't forget that FreeType's job is to render glyphs, nothing
else.
My opinion is that since FreeType opens the font file, it might as
well process everything that is in it.
I'm with the majority. Layout and rendering are different kreatures.
Auto-kerning is, however, a totally
On Sat, Oct 27, 2012 at 7:38 AM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-horizontal.pdf
http://webloria.loria.fr/~rougier/tmp/glyph-metrics-vertical.pdf
It'd look lovely in color, but do not over do it. E.g., draw the glyph
in black,
On Tue, Oct 30, 2012 at 6:56 AM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:
My question relates to a more direct way to compute the signed distance and
to know if anyone has already coded it by any chance ? Said differently, is
there a quick way to compute the shortest signed distance
On Wed, Oct 31, 2012 at 12:03 PM, Behdad Esfahbod beh...@behdad.org wrote:
On 12-10-31 07:25 AM, Alexei Podtelezhnikov wrote:
On Tue, Oct 30, 2012 at 6:56 AM, Nicolas Rougier
nicolas.roug...@inria.fr wrote:
My question relates to a more direct way to compute the signed distance and
to know
Werner et al.,
What is the Freetype policy and/or goals with regard to integer overflows?
How practical are the large sizes that push outline dimensions beyond 16
bits, or pixel size of 1024? In a few places I see 64-bit arithmetic
utilized to control the overflow by means of FT_Int64. This
On Tue, Nov 27, 2012 at 12:51 PM, Sean McBride s...@rogue-research.com wrote:
On Mon, 26 Nov 2012 11:43:35 -0800, Brian Stell said:
Freetype is a critical part of the Linux world. It's become fairly common
for bodies of code to have a test suite. (I'm not proposing full testing
right right now
Werner,
As it stands right now, ttinterp.c uses multiple forms of
multiplication-division calls: macro TT_MULDIV, direct FT_MulDiv, and
custom TT_MulFix14. This is confusing and unjustified IMHO, so I wanted to
consolidate and harmonize those calls. The attached patch mostly does the
following
Werner,
Before you look at my patch can you check that those are not bugs on
the following lines?
ttinterp.c:2706: After checking if F_dot_P is smaller than a
threshold, it is assigned a maximum possible value rather than a
threshold value. Is it possible that there is one zero too many on
line
About the patch, whenever we use F_dot_P in the bytecode interpreter
in comparisons or divisions we have to scale up the other side by
0x1L. I propose that instead we scale F_dot_P down by 0x1L
when we assign it. This improves readability and avoids huge
numbers and confusions with
Eric,
In your integrated code you use FT_UInt for the rule scaling factor,
with 1000 being a unit. This contradicts the general FreeType practice
of using FT_Fixed to represent fractional numbers. I would strongly
suggest switching to FT_Fixed, with 0x1 representing a unit. Then
all
Werner,
I just noticed that Freetype documentation frequently refers to fixed
float format or type. This is an oxymoron, of course. What Freetype
uses is fixed-point representation of real numbers using integer
types, as opposed to floating point representation using float or
double types. I
Here is some old references on the subject of strange ascender,
descender and height:
http://lists.gnu.org/archive/html/freetype-devel/2009-06/msg00026.html
http://lists.gnu.org/archive/html/freetype-devel/2011-07/msg9.html
http://savannah.nongnu.org/bugs/?34156
Window also forces height =
On Thu, Jan 10, 2013 at 1:38 PM, Behdad Esfahbod beh...@behdad.org wrote:
Hi,
There's a bug against Webkit:
https://bugs.webkit.org/show_bug.cgi?id=102374
that I think points to a problem in FreeType. Simply put: for fonts that have
ascent+descent=line-height, this property may not hold
Hi all,
I have just made two commits [081aba390a64,0e0fdc5dc89e] that remove
some very old vector normalization hack from the TrueType bytecode
interpreter and slightly potentially improve the accuracy of the
normalization. It appears that this error compensation hack was
introduced to deal with
On Wed, Jan 23, 2013 at 11:10 AM, David Turner da...@freetype.org wrote:
Unless I'm missing something (which is entirely possible, and I've not
looked at the patch details yet).
If that so, maybe add some code to deal with this, e.g.:
if (height_26.6 == ascender_26.6 - descender_26.6) {
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com wrote:
What is the largest possible height change between the old and new
implementation? Can it exceed one pixel?
It should not exceed 1 pixel unless the height specified in the font
differs from (acsender - descender) by
On Thu, Jan 24, 2013 at 2:23 AM, Wojciech Mamrak wmam...@gmail.com wrote:
2013/1/23 Alexei Podtelezhnikov apodt...@gmail.com:
On Wed, Jan 23, 2013 at 10:50 AM, Wojciech Mamrak wmam...@gmail.com wrote:
What is the largest possible height change between the old and new
implementation? Can
On Thu, Jan 24, 2013 at 10:16 AM, Werner LEMBERG w...@gnu.org wrote:
I think that David's idea to make the change conditional can work
except we should use a softer condition: [...]
This is all moot. It was my error mixing up the glyph height with
the `height' value in FT_Face which
Hi all,
The attached patch simplifies 'pcf_get_encodings'. By switching from a
single loop to a double loop, it simplifies a crazy expression for the
enc field. It also utilizes FT_RENEW_ARRAY instead of copying the
content over from a temporary array. So, I'd like to commit it, but
PCF fonts
On Tue, Jan 29, 2013 at 8:25 AM, Alexei Podtelezhnikov
apodt...@gmail.com wrote:
The attached patch simplifies 'pcf_get_encodings'. By switching from a
single loop to a double loop, it simplifies a crazy expression for the
enc field. It also utilizes FT_RENEW_ARRAY instead of copying
Thanks to Werner, benchmarking FT_Outline_Get_BBox is now easy using
ftbench. I've added a rotation by 30 degrees to really challenge it.
These are results.
With the old code:
$ bin/ftbench -s 24 -b ej /usr/share/fonts/default/Type1/n019003l.pfb
Get_CBox : 0.257 us/op
Get_BBox
On Sat, Feb 16, 2013 at 2:58 AM, Werner LEMBERG w...@gnu.org wrote:
Thanks to Werner, benchmarking FT_Outline_Get_BBox is now easy using
ftbench. I've added a rotation by 30 degrees to really challenge it.
Please commit this to ftbench.
Pushed out.
These are results.
Looks good, thanks!
You may try to change precision from .2f to print more digits
after the point (probably just completely remove the limit).
Yes, it helps. The new code is more accurate too. I've added the third
outline for which I know the exact answer. It should be precisely [0
100 128 175].
OLD CODE:
On Sun, Feb 24, 2013 at 1:08 AM, Werner LEMBERG w...@gnu.org wrote:
Attached are more thorough tests. Each line contains bboxes for the
the current and proposed algorithms as well as their difference.
The bboxes are for two popular fonts at size 24 with rotation of 30
degrees as dumped
Why would you compare with theoretical results when your rasterizer
uses discrete and less accurate bisections? Shouldn't you compare
with the rendering results? One way or the other 3/64 of a pixel is
really small difference.
Well, your results differ from the original ones. I don't
The new code is a bit worse but faster. The problem is in the
rounding. I can potentially scale up the outlines temporarily to
deal with this problem.
I really wonder whether it makes sense to speed up the exact bbox
computation if this causes a loss of precision.
The original
Make sure that you capitalize the T in FreeType in the text of the paper
and I think you should just reference the website http://www.freetype.org .
On Mon, Mar 4, 2013 at 4:56 AM, Nicolas Rougier nicolas.roug...@inria.frwrote:
Hi,
I would like to cite the Freetype project in a paper but
On Tue, Mar 26, 2013 at 2:06 PM, Vernon Adams v...@newtypography.co.ukwrote:
Please note it is only Chrome on OSX that shows this messed up rendering,
other browsers on OSX render the glyphs fine.
Why do you think this is FreeType problem then? You really need to
reproduce the problem with
On Thu, Apr 4, 2013 at 12:14 AM, Werner LEMBERG w...@gnu.org wrote:
I fear that support for the various vertical metrics components is
severely broken in FreeType. In particular, values are computed
differently for different font formats. To fix this for all font
formats ...
First we need
See also this thread.
http://lists.nongnu.org/archive/html/freetype-devel/2013-02/msg00031.html
Easy but not worth fixing.
On Tue, Jul 16, 2013 at 9:35 AM, Werner LEMBERG w...@gnu.org wrote:
At two places in FT_Outline_Decompose there is a division by 2 that
loses one bit of precision.
On Sat, Jul 20, 2013 at 4:04 AM, Werner LEMBERG w...@gnu.org wrote:
... around an extremum ...
I see that the glyph height is fixed now. Good job.
___
Freetype-devel mailing list
Freetype-devel@nongnu.org
On Wed, Feb 27, 2013 at 12:40 PM, Werner LEMBERG w...@gnu.org wrote:
The original motivation was to kill the last use of FT_SqrtFixed.
Ah, ok.
Then I read old emails that made perplexing assertion that bisection
is too slow to converge while never questioning iterations in the
sqrt
Hi Werner et al.,
On Fri, Aug 9, 2013 at 3:49 PM, Werner LEMBERG w...@gnu.org wrote:
So I wonder what's the expectations for the BBox calculations? Do
we really need accuracy better than 2 bits?
I don't think so. However, I consider it problematic that your
code reduces the allowed bbox
Werner,
I would resist any excessively special treatment for Cyrillic. Whoever
makes the glyphs that should be shared with Latin look different is
misguided. Please do not go overboard with this. There are some rather
common unique cyrillic fonts. Check out the PSCyr collection
FWIW, instead of power gamma correction, the rational expressions can
often work well:
gamma 1.7: x*x/(0.4x+0.6)
gamma 1.4: x*x/(0.7x+0.3)
in case something quick is needed in FreeType or outside.
On Fri, Nov 1, 2013 at 2:25 AM, Antti Lankila alank...@bel.fi wrote:
Dave Arnold
1 - 100 of 948 matches
Mail list logo
