[ft-devel] move band check outside of the loop.

2011-08-12 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] move band check outside of the loop.

2011-08-14 Thread Alexei Podtelezhnikov
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 @@

Re: [ft-devel] move band check outside of the loop.

2011-08-16 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] broken hinted DejaVuSans et 4

2011-09-13 Thread Alexei Podtelezhnikov
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?

Re: [ft-devel] [ANN] Freetype/OpenGL (with good rendering quality)

2011-09-21 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] regarding freetype 2 cubic curve flattening

2011-10-30 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] regarding freetype 2 cubic curve flattening

2011-10-31 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] regarding freetype 2 cubic curve flattening

2011-10-31 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] regarding freetype 2 cubic curve flattening

2011-10-31 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FT_Get_Advance() docs

2011-11-30 Thread Alexei Podtelezhnikov
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),

Re: [ft-devel] FreeType License and patents

2012-01-18 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] ftgrays - exact pixel coverage?

2012-02-09 Thread Alexei Podtelezhnikov
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.

[ft-devel] direction of autofit-ed outlines

2012-02-13 Thread Alexei Podtelezhnikov
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

[ft-devel] losing outline flags while auto-hinting

2012-02-15 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] losing outline flags while auto-hinting

2012-02-16 Thread Alexei Podtelezhnikov
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

[ft-devel] [PATCH] Re: losing outline flags while auto-hinting

2012-02-16 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-20 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-20 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-20 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-21 Thread Alexei Podtelezhnikov
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:

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-21 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-21 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FreeType patches to support amalgamation

2012-02-21 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] where might be a problem

2012-02-24 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-26 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-27 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-27 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-27 Thread 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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-28 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Auto Embolding of Lohit Devanagari

2012-02-29 Thread Alexei Podtelezhnikov
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) On line 357 in ftview.c, I think it is incorrect to

Re: [ft-devel] Patch to allow '\0' in sfnt name table entries

2012-03-14 Thread Alexei Podtelezhnikov
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

[ft-devel] [patch] remove synonymous macro isdigok

2012-03-21 Thread Alexei Podtelezhnikov
Two macros 'sbitset' and 'isdigok' in bdflib.c has recently become synonymous. Quoting from the code: Line 428: #define sbitset( m, cc ) \ ( m[(FT_Byte)(cc) 3] ( 1 ( (cc) 7 ) ) ) Line 845: #define isdigok( m, d ) (m[(unsigned char)(d) 3] ( 1 ( (d) 7 ) ) ) The attached patch

[ft-devel] [patch] emboldening rework v1

2012-03-29 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-03-30 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-01 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Issues due to commit Fix metrics on size request for scalable fonts.

2012-04-03 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-09 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-10 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-10 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-12 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-18 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-19 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-20 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-04-24 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-05-29 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] display broken

2012-05-30 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

2012-06-01 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

2012-06-05 Thread Alexei Podtelezhnikov
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:

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

2012-06-05 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

2012-06-06 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] emboldening rework v1

2012-06-06 Thread Alexei Podtelezhnikov
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.

Re: [ft-devel] Artefacts when rendering with FreeType 2.4.9

2012-06-13 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FT_Outline_Embolden() is Blurry

2012-06-16 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] FT_Outline_Embolden() is Blurry

2012-06-17 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] New Infinality Release

2012-06-18 Thread Alexei Podtelezhnikov
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 =

Re: [ft-devel] New Infinality Release

2012-06-18 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] New Infinality Release

2012-06-18 Thread Alexei Podtelezhnikov
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

[ft-devel] [patch] fuller right margin in ftview

2012-06-22 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] fuller right margin in ftview

2012-06-27 Thread Alexei Podtelezhnikov
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.

Re: [ft-devel] [patch] fuller right margin in ftview

2012-06-27 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] fuller right margin in ftview

2012-07-01 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

2012-07-03 Thread Alexei Podtelezhnikov
On Tue, Jul 3, 2012 at 6:09 AM, 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.

Re: [ft-devel] [ttfautohint] stem width handling is now selectable

2012-07-03 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] fuller right margin in ftview

2012-07-03 Thread Alexei Podtelezhnikov
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,

[ft-devel] adjustable stroker radius

2012-08-17 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] adjustable stroker radius

2012-08-18 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] controlling FreeType modules

2012-08-29 Thread Alexei Podtelezhnikov
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? ___

Re: [ft-devel] controlling FreeType modules

2012-08-30 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Getting the kerning pairs in under O(n*n)

2012-10-03 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Glyph metrics figures on the website

2012-10-27 Thread Alexei Podtelezhnikov
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,

Re: [ft-devel] Signed distance fields: distance from any point to the glyph contours

2012-10-31 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Signed distance fields: distance from any point to the glyph contours

2012-10-31 Thread Alexei Podtelezhnikov
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

[ft-devel] Freetype limits or integer overflows

2012-11-16 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Unit test environment for FreeType

2012-11-27 Thread Alexei Podtelezhnikov
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

[ft-devel] [patch] clean up MulDiv in bytecode interpreter

2012-12-04 Thread Alexei Podtelezhnikov
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

[ft-devel] scale F_dot_P down

2012-12-06 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] scale F_dot_P down

2012-12-07 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] New Infinality Release

2012-12-19 Thread Alexei Podtelezhnikov
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

[ft-devel] fixed float

2013-01-10 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Rounding of ascent, descent, and line height

2013-01-10 Thread Alexei Podtelezhnikov
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 =

Re: [ft-devel] Rounding of ascent, descent, and line height

2013-01-10 Thread Alexei Podtelezhnikov
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

[ft-devel] simply normalize

2013-01-12 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Alexei Podtelezhnikov
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) {

Re: [ft-devel] [ft] heads-up: TrueType height computation has been fixed

2013-01-23 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [ft] heads-up: TrueType height computation has been fixed

2013-01-24 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [ft] heads-up: TrueType height computation has been fixed

2013-01-24 Thread Alexei Podtelezhnikov
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

[ft-devel] [patch] streamline pcf_get_encodings

2013-01-29 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] [patch] streamline pcf_get_encodings

2013-02-01 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-15 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-16 Thread Alexei Podtelezhnikov
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!

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-17 Thread Alexei Podtelezhnikov
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:

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-24 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-25 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-02-27 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Proper way of citing freetype

2013-03-04 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] ttfautohint - render issue with composites on OSX CHrome

2013-03-26 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] vertBearingY of CFF glyphs is always unscaled

2013-04-05 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] loss of precision in FT_Outline_Decompose

2013-07-17 Thread Alexei Podtelezhnikov
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.

Re: [ft-devel] major autohinter change

2013-07-21 Thread Alexei Podtelezhnikov
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

Re: [ft-devel] Fast bisecting BBox_Cubic_Check

2013-08-09 Thread Alexei Podtelezhnikov
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

  1   2   3   4   5   6   7   8   9   >