Re: [ft-devel] gamma correction and FreeType

On Thu, Nov 7, 2013 at 1:29 PM, another gol another...@gmail.com wrote: It could be that all of my monitors have a 1.4 gamma, but really, I never saw it looking wrong on any monitor, there must be a reason Windows defaults to 1.4. I strongly suspect that the 2.2 standard gamma is either a

Re: [ft-devel] gamma correction and FreeType

Antti, you're sooo off topic Please make an effort to come up with a subject line next time and start a new thread. Alexei On Wed, Nov 13, 2013 at 1:52 AM, Antti Lankila alank...@bel.fi wrote: Dave Arnold darn...@adobe.com kirjoitti 11.11.2013 kello 23.35: Nothing stupid that I can see :-)

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

On Fri, Mar 14, 2014 at 11:18 AM, Sean McBride s...@rogue-research.comwrote: Attached are 3 more patches, this time to fix compiler warnings (not static analyzer warnings). None of them are serious. The biggest fixes most -Wmissing-variable-declarations warnings, where some functions that

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

On Tue, Mar 18, 2014 at 2:37 AM, Werner LEMBERG w...@gnu.org wrote: The patch 0004 is false positive. The variable 'hit' is set to zero when entering the loop so 'p_last' and 'p_first' are assigned almost immediately. Thanks for the analysis. However, initializing doesn't hurt, and

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

On Tue, Mar 18, 2014 at 2:37 AM, Werner LEMBERG w...@gnu.org wrote: The patch 0004 is false positive. The variable 'hit' is set to zero when entering the loop so 'p_last' and 'p_first' are assigned almost immediately. Thanks for the analysis. However, initializing doesn't hurt, and

Re: [ft-devel] Lots of over-/undershoot in HFJ Mercury SSm A at 17.6px

Perhaps, this is http://savannah.nongnu.org/bugs/?38662 ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] fttrigon: Use standard floating-point functions for performance?

Hi Rodger, Your tests show that Freetype stroker relies on On Sat, May 24, 2014 at 12:49 AM, Rodger Combs rodger.co...@gmail.comwrote: While profiling libass in OSX's Instruments.app, I've found that Freetype's stroker tends to come up as a very time-consuming routine, and that most of the

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

On Wed, Mar 19, 2014 at 2:36 AM, Werner LEMBERG w...@gnu.org wrote: Arg... I am not sure if the patch is even correct. Aren't we resetting the variable in each loop cycle? This wasn't the case in the original code where the values reused, was it? Oops! You are right. Thanks for

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

On Tue, Jun 17, 2014 at 10:29 AM, Sean McBride s...@rogue-research.com wrote: On Mon, 16 Jun 2014 20:46:44 -0400, Alexei Podtelezhnikov said: Arg... I am not sure if the patch is even correct. Aren't we resetting the variable in each loop cycle? This wasn't the case

Re: [ft-devel] WIP PATCH: clang static analyzer and warning fixes

Indeed, the loop body is exited and reentered in each iteration so the scope is lost each time. It is only thanks to the reuse of stack that the code worked. The last fix by Werner is correct. I would initialize to -1 though for consistency or not initialize at all. On Thu, Jun 19, 2014 at 12:40

[ft-devel] FT_MulDiv optimization

Hi all, The following will roughly double the space of optimal calculations. Comments? Alexei diff --git a/src/base/ftcalc.c b/src/base/ftcalc.c index 6e65583..baeb810 100644 --- a/src/base/ftcalc.c +++ b/src/base/ftcalc.c @@ -363,15 +363,15 @@ /*

Re: [ft-devel] FT_MulDiv optimization

On Fri, Jul 4, 2014 at 12:54 AM, Werner LEMBERG w...@gnu.org wrote: The following will roughly double the space of optimal calculations. Comments? Well, at the same time it reduces the available range for `c' by more than 50%. I was greedy with the space for a and b. With a + b 2*46340

Re: [ft-devel] FT_MulDiv optimization

On Fri, Jul 4, 2014 at 6:12 AM, Werner LEMBERG w...@gnu.org wrote: Well, at the same time it reduces the available range for `c' by more than 50%. I was greedy with the space for a and b. With a + b 2*46340 instead, c can use the same old limit. We can expand c a lot further by

Re: [ft-devel] FT_MulDiv optimization

On Fri, Jul 4, 2014 at 3:30 PM, Behdad Esfahbod beh...@behdad.org wrote: On 14-07-04 03:09 PM, Alexei Podtelezhnikov wrote: You force me to think, man. To avoid any overflow it is sufficient to satisfy this inequality a + b 2 * sqrt(X - c/2) where X is 2^31 - 1. Using Taylor

Re: [ft-devel] FT_MulDiv optimization

a + b 92681 - (c 16) + ((c+ 235935) 18) How about the simpler: a + b = 92681 - (c 16) I like this! Pushed. ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

Re: [ft-devel] FT_MulDiv optimization

On Sat, Jul 5, 2014 at 2:05 AM, Werner LEMBERG w...@gnu.org wrote: a + b 92681 - (c 16) + ((c+ 235935) 18) How about the simpler: a + b = 92681 - (c 16) I like this! Pushed. Thanks a lot! However, please expand the comment, since the involved mathematics is not trivial. For

Re: [ft-devel] assembler or builtin?

On Mon, Jul 7, 2014 at 4:24 PM, Behdad Esfahbod beh...@behdad.org wrote: On 14-07-07 03:01 PM, Alexei Podtelezhnikov wrote: Many architectures have special instructions for the most significant bit: BSR on x86, CLZ on ARM. Some compilers have builtin functions for that too: __builtin_clz

Re: [ft-devel] Undefined behavior

On Fri, Aug 8, 2014 at 4:56 PM, Behdad Esfahbod beh...@behdad.org wrote: * src/base/ftcalc.c (FT_MSB): Utilize gcc builtins. introduced undefined behavior, since __builtin_clz and __builtin_ctz have undefined behavior if passed in value is zero. This can actually happen with degenerate

Re: [ft-devel] Undefined behavior

* src/pfr/pfrobjs.c, do you think count can be 0 here? FT_UIntpower = 1 FT_MSB( count ); I doubt very highly that undefined behavior can mean a number between 0 and 31. So we'll get power = 0 if count = 0, which is fine too. Every case is safe, or so it seems to me.

Re: [ft-devel] Undefined behavior

On Fri, Aug 8, 2014 at 4:56 PM, Behdad Esfahbod beh...@behdad.org wrote: commit 177982e933ed6f2ab96163e14f4267f8abe89efd Seriously though, my commit does not change much, both FT_MSB and ft_highpow2 used to return nonsense on zero input even before this commit. I think I am going to apply some

Re: [ft-devel] Undefined behavior

On Mon, Aug 11, 2014 at 11:55 AM, Behdad Esfahbod beh...@behdad.org wrote: On 14-08-11 10:15 AM, Alexei Podtelezhnikov wrote: On Fri, Aug 8, 2014 at 4:56 PM, Behdad Esfahbod beh...@behdad.org wrote: commit 177982e933ed6f2ab96163e14f4267f8abe89efd Seriously though, my commit does not change

Re: [ft-devel] Undefined behavior

Ok. I still do not think that we should fix the macro, because there is no good value to return. Returning zero for zero is bad too. One should not call MSB or the builtins with zero argument, just like one should not divide by zero. So I'll try to apply fix the callers. It's sometimes more

Re: [ft-devel] FT_MulDiv optimization

Werner, FT_MulFix optimized like this on line 543: if ( ua = 2048 ub = 1048576L ) ua = ( ua * ub + 0x8000UL ) 16; Of course, when we anchor 2048 and use unsigned multiplication, it should safely have been if ( ua = 2048 ub = 2097135L ) but that's not my point. I do not know

[ft-devel] Fwd: FT_LONG64 truncation at 32

Under FT_LONG64 FT_DivFix truncates the result at 32 bits, see ftcalc.c:271. Interestingly, FT_MulFix and FT_MulDiv do not do that, although it also is possible for them to exceed 32 bits in the result. Which behavior would be correct? IMHO a function specified as FT_Long should not truncate at

Re: [ft-devel] FT_MulDiv optimization

On Sat, Aug 16, 2014 at 2:08 PM, Behdad Esfahbod beh...@behdad.org wrote: Scratch this part. the existing limit is more than enough for all practical purposes. It's pixel-size divided by upem in 16.16. So you need a font size 1 pixels before you surpass a 1048576 scale. Graham, Behdad.

Re: [ft-devel] FT_MulDiv optimization

On Sat, Aug 16, 2014 at 2:06 PM, Behdad Esfahbod beh...@behdad.org wrote: I think main usage pattern for this function is to scale values from font space to Fixed device space. Font-space values are typically 2048 because of TrueType commonly uses upem=2048 and Type1 uses 1000, so 2048

[ft-devel] __STDC__ disables 64-bit long

Under linux on x86_64, the long type is 8 bits. Why do we disable FT_LONG64? /* A 64-bit data type will create compilation problems if you compile*/ /* in strict ANSI mode. To avoid them, we disable its use if __STDC__ */ /* is defined. You can however ignore this rule by defining

Re: [ft-devel] __STDC__ disables 64-bit long

On Wed, Aug 20, 2014 at 10:20 AM, Werner LEMBERG w...@gnu.org wrote: Under linux on x86_64, the long type is 8 bits. Why do we disable FT_LONG64? /* A 64-bit data type will create compilation problems if you compile*/ /* in strict ANSI mode. To avoid them, we disable its use if

[ft-devel] ttinterp.c optimization

I want to move CURRENT_Ppem outside of the point loops. It seems to work fine. Anything wrong with that? diff --git a/src/truetype/ttinterp.c b/src/truetype/ttinterp.c index 9491533..082114a 100644 --- a/src/truetype/ttinterp.c +++ b/src/truetype/ttinterp.c @@ -7490,7 +7490,7 @@ FT_ULong

Re: [ft-devel] ttinterp.c optimization

On Sun, Aug 24, 2014 at 10:24 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: I want to move CURRENT_Ppem outside of the point loops. It seems to work fine. Anything wrong with that? This is OK, since the ppem (measured along the projection vector) doesn't change within a single call

Re: [ft-devel] ttinterp.c optimization

On Wed, Aug 27, 2014 at 12:42 AM, Werner LEMBERG w...@gnu.org wrote: Furthermore, it turns out that MPS instruction is *very* *very* common. Why do we call CURRENT_Ppem here? The comment suggest that the decision was arbitrary and, perhaps, wasteful. I see a huge number of trivial

[ft-devel] Significant optimization of ft_div64by32

In memory of Paul Alexi I have just committed significant optimization of ft_div64by32, one of the more expensive calculations that we sometimes do on 32-bit platforms. The trick was to do as much as we can with 32-bit division before embarking on

Re: [ft-devel] [PATCH] Improve FT_MulFix

Some time ago James Cloos proposed... I tested a wide array of gcc cross compilers as well as clang/llvm. In each case the machine code this version produces is as good as the hand-tuned assembly and uses the trick that adding 0x7FFF when the product is negative causes the same

Re: [ft-devel] [PATCH] Improve FT_MulFix

On Fri, Oct 3, 2014 at 3:27 PM, Alexei Podtelezhnikov apodt...@gmail.com wrote: ... this patch: http://cgit.freedesktop.org/~cloos/freetype2/commit/?id=94dc0c20554f3a3d709711f2c43ac65ab7c68afe Never mind. Right-shifting negative numbers is implementation defined (ANSI or C11), so

[ft-devel] two delta_shift questions

Werner, For a while I was staring at ttinterp.c: B = B * 64 / ( 1L CUR.GS.delta_shift ); delta_shift is FT_Short, so it can be negative, which is undefined behavior. Shouldn't we change the type to FT_UShort? The second question is how often do you see delta_shift larger than 6? I am

Re: [ft-devel] two delta_shift questions

On Mon, Oct 13, 2014 at 11:27 AM, Alexei Podtelezhnikov apodt...@gmail.com wrote: The second question is how often do you see delta_shift larger than 6? I am basically thinking about this optimization: B = B * ( 1L ( 6 - CUR.GS.delta_shift ) ); I think I found the answer: The legal

Re: [ft-devel] two delta_shift questions

On Tue, Oct 14, 2014 at 1:09 AM, Werner LEMBERG w...@gnu.org wrote: The legal range for delta shift is zero through six. Negative values are illegal. Yep, since the smallest unit is 1/(2^6) = 1/64th px. What should freetype do with larger values? Should we set delta_shift, but do nothing in

Re: [ft-devel] Cleaning up ttinterp

On Mon, Oct 13, 2014 at 7:04 PM, Behdad Esfahbod beh...@behdad.org wrote: The first two commits remove about 1600 lines combined. The file contained bytecode description in plain English and consumed stack specs. I will miss it. +1 if you preserve English descriptions and stack specs.

Re: [ft-devel] Cleaning up ttinterp

On Mon, Oct 13, 2014 at 7:04 PM, Behdad Esfahbod beh...@behdad.org wrote: I was checking it out today and noticed that there are two main loops: default big switch, and non-default function-dispatch array. Both are likely implemented through jump tables with similar performance. Whether the

[ft-devel] SROUND vs S45ROUND

Hi all, According to https://developer.apple.com/fonts/TrueType-Reference-Manual/RM05/Chap5.html#S45ROUND The grid period tables of the 45-degree S45ROUND is actually sqr(2) *larger* than that of SROUND. You might get different impression from reading more cryptic Microsoft files. So shouldn't

[ft-devel] More rounding issues

Werner, Admittedly, I enjoy reading those Apple docs too much. So I found other problems: Here https://developer.apple.com/fonts/TrueType-Reference-Manual/RM02/Chap2.html#rounding_operations the phase is added back *before* checking if rounding changed the sign. MS is in agreement here. Freetype

Re: [ft-devel] More rounding issues

So I found other problems: In addition Round_To_Double_Grid does half-grid instead. val = ~31 should be val = ~127 I'll start patching tonight. ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] More rounding issues

In addition Round_To_Double_Grid does half-grid instead. val = ~31 should be val = ~127 Brrr, sorry, I'm wrong, freetype is right here. ___ Freetype-devel mailing list Freetype-devel@nongnu.org

Re: [ft-devel] SROUND vs S45ROUND

#define DO_S45ROUND \ -SET_SuperRound( 0x2D41, args[0] ); \ +SET_SuperRound( 0x5A82, args[0] ); \ CUR.GS.round_state = TT_Round_Super_45; \ CUR.func_round = (TT_Round_Func)Round_Super_45; Good question. I

Re: [ft-devel] Build errors with MSVC

On Wed, Oct 22, 2014 at 6:06 AM, John Emmas john...@tiscali.co.uk wrote: Hi guys, I updated freetype from git master (this morning) and I'm getting these errors when compiling cff.c (technically, when compiling cffobjs.c):- Freetype did not used to put such tweaking knobs in the options file.

Re: [ft-devel] Build errors with MSVC

Anyways, since VC 2010 is a frequently used compiler, we have to find a workaround. Behdad, any ideas? I do not have the compiler but I would try braces around {the constants}. Then you can use it to initialize a temp array to transfer in the appropriate place at last. FT_Int params[] =

Re: [ft-devel] Build errors with MSVC

gcc warning: In file included from /home/apodtele/freetype2/src/cff/cff.c:27:0: /home/apodtele/freetype2/src/cff/cffobjs.c: In function 'cff_driver_init': /home/apodtele/freetype2/src/cff/cffobjs.c:1091:22: warning: typedef 'static_assert_darkening_parameters' locally defined but not used

[ft-devel] advance question

Am I right that advance is always rounded to pixels no matter if the glyph is hinted or not? I wonder if this should be reflected in lsb_delta and rsb_delta, perhaps just the latter. What do you think? Alexei ___ Freetype-devel mailing list

[ft-devel] change FT_Outline_Funcs API

Werner, What will it take to change FT_Outline_Funcs API? I am talking about shift and delta. Freetype does not use them and sets them zero. Google search outside seems to show the same. This API is so inflexible that it is useless. On the other hand, subpixel rendering scales outlines 3 times

Re: [ft-devel] Discrepancy in FT_MulFix macros and int sizes

On Tue, Nov 18, 2014 at 9:05 PM, Behdad Esfahbod beh...@behdad.org wrote: It was reported to me by my colleague Doug Felt (CC'ed) that FT_MulFix takes FT_Long parameters as defined in freetype.h, but several inline implementations of it in ftcalc.h take FT_Int32 arguments. I cannot imagine

Re: [ft-devel] Discrepancy in FT_MulFix macros and int sizes

On Wed, Nov 19, 2014 at 12:32 AM, Werner LEMBERG w...@gnu.org wrote: I was also wondering if FT_Long should be defined synonymous to FT_Int32, etc. typedef FT_Long FT_Int32 Hmm. FT_Int32 is *exactly* 32bit, while FT_Long is simply a typedef to `long' and thus *at least* 32bit, depending

Re: [ft-devel] PaxHeaders directories when using BSD tar

These PaxHeaders.xxx directories were created when using the standard BSD tar program. When I downloaded and used GNU tar the build worked fine. Can freetype be packaged using a more portable tar method? Quoting from http://packages.ubuntu.com/de/lucid/bsdtar GNU tar support. Libarchive

Re: [ft-devel] Cleaning up ttinterp

Will have a look whether I can follow your patch, doing the reduction by myself. Humm. Did you get to take a look at this by any chance? It's on my TODO list If all relevant compilers implement the switch as a jump table, indeed there is no need to have an internal surrogate

Re: [ft-devel] [PATCHSET] Multithread-safe FreeType

Over the past couple of days I developed a tool for testing FreeType in multi-threaded environments: Your patches are now in FreeType's git repository. Thanks a lot! IMHO, this is a big deal that needs to be released as 2.6.0. ___ Freetype-devel

Re: [ft-devel] Release numbering

We don't release unstable versions. Thanks Alexey - so will there (eventually) be a branch in git which corresponds to Release v2.5.x? Or does the branch called STABLE automatically reflect whatever happens to be Historically the most recent is the best. We don't have resources to

Re: [ft-devel] INT_MIN and FT_Render_Glyph

Why is it supposed to work? I do not follow. #define INT_MIN 0x8000 This might be an unsigned integer constant according to standards. When used, it may result in implicit type conversion to unsigned for the rest of calculations and comparisons: the hell breaks loose. This is a reason

Re: [ft-devel] sign in conversion INT_MIN and FT_Render_Glyph (Re: Freetype-devel Digest, Vol 121, Issue 4)

On Fri, Feb 13, 2015 at 1:45 PM, Hin-Tak Leung ht...@users.sourceforge.net wrote: This might catch some interesting and hidden bugs. BTW, mingw header defines it in include/limits.h as: #define INT_MIN (-2147483647 - 1) Freetype does not redefine *standard* INT_MIN. If someone decided to

Re: [ft-devel] GX support now working

On Thu, Jun 4, 2015 at 4:39 PM, Behdad Esfahbod beh...@behdad.org wrote: On 15-06-04 12:19 PM, Behdad Esfahbod wrote: On 15-06-04 12:15 PM, Alexei Podtelezhnikov wrote: On Wed, Jun 3, 2015 at 4:28 PM, Behdad Esfahbod beh...@behdad.org wrote: TrueType fonts have a 'non-zero winding' fill rule

Re: [ft-devel] GX support now working

On Wed, Jun 3, 2015 at 4:28 PM, Behdad Esfahbod beh...@behdad.org wrote: TrueType fonts have a 'non-zero winding' fill rule, whereas Postscript has 'even-odd'. That's what causes the artifacts. FT_OUTLINE_EVEN_ODD_FILL is never set by freeetype. So actually FreeType always uses non-zero

[ft-devel] BDF extensions

Hi All, It looks like FreeType supports BDF files with MS style bits_per_pixel but not FontForge extension. See this: http://fontforge.github.io/BDFgrey.html Should we add it? Alexei ___ Freetype-devel mailing list Freetype-devel@nongnu.org

[ft-devel] integer suffix abuse

Hi All, I think we abuse the suffix L in integer constants. I understand the desire to make sure that very common 0x1L is 32-bit to represent a unit in 16.16 fixed-point representation. On modern 64-bit systems that actually becomes an unnecessary 64-bit constant. Perhaps the suffix was used

Re: [ft-devel] integer suffix abuse

On Wed, Jun 24, 2015 at 1:12 PM, Tom Bishop, Wenlin Institute wen...@wenlin.com wrote: I would have guessed that with a 64-bit compiler the resulting executable code would be the same with or without L. (The definitions of types like FT_Fixed and FT_Long would make more difference.)

Re: [ft-devel] Apple offset scaling

There is this page: http://fontforge.github.io/assets/old/Composites/index.html Nice, thanks! After seeing this page now I can faintly remember that I've seen it a looong time ago also :-) I think George Williams wrote it. However his empirical equations on this page and in the FreeType

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

if ( slot-format == FT_GLYPH_FORMAT_OUTLINE ) FT_Outline_EmboldenXY(..., ...-darken_x, 0); This function still needs a bit of work around the corners, both literally and figuratively speaking. Emboldening is not affine transformation. It can introduce artifacts. The function has some crude

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

No, unless FT_Outline_Embolden() does that, then yes ;) `FT_Outline_Embolden' *does* change the advance width! You have to save the metrics before the call, then restoring the original values. Don't you mean experimental FT_Glyph_Embolden? ___

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

1. The function to compute how much darkening to apply is a crude copy-pasta of the real thing in cff/cf2font.c Is this the one with four parameters? I do not understand why it has to be so complex. I am not a big fan unless someone can explain it?

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

Alexei A Podtelezhnikov, PhD On Aug 24, 2015, at 6:11 AM, Behdad Esfahbod behdad.esfah...@gmail.com wrote: On 15-08-23 11:29 PM, Werner LEMBERG wrote: `FT_Outline_Embolden' *does* change the advance width! You have to save the metrics before the call, then restoring the original

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

1. The function to compute how much darkening to apply is a crude copy-pasta of the real thing in cff/cf2font.c Is this the one with four parameters? I do not understand why it has to be so complex. I am not a big fan unless someone can explain it? I haven't yet looked closely at the new

Re: [ft-devel] Taming CFF_CONFIG_OPTION_DARKENING_PARAMETER_Y* for a gamma of ~2.2/sRGB?

FT_Outline_EmboldenXY only changes the outline and its bounding box. The dimensions of the letter is changed very predictably by xstrength and ystrength. The outline is shifted by half of the strengths so that the bottom-left of the bounding box stays in place. Makes sense? Yes, this I

Re: [ft-devel] Improved Arabic auto-hinting

This effect: https://www.flickr.com/photos/behdad/34769511/ still happens in my limited testing. This looks like a text layout problem, which was traditionally outside of FreeType's responsibilities. The extra ink is a result of bitmap addition, which would be swept under the rug by strong

Re: [ft-devel] FT_Vector_NormLen: faster vector normalization

On Tue, Jun 30, 2015 at 3:47 AM, Werner LEMBERG w...@gnu.org wrote: Uh, oh, this code is very fragile and not easy to understand... I tried to remove some compiler warnings (from `clang -Wsign-conversion', see below for the original compiler messages and my bad attempt to fix them), and even

[ft-devel] FT_Vector_NormLen: faster vector normalization

Hi All, I have just committed a fast vector normalization procedure based on Newton's iterations without square roots and divisions. It speeds up emboldening by 40% and TrueType loading by 15% in my benchmarks with times and arial at 16ppem. There are a few places in the code that are

Re: [ft-devel] FT_Vector_NormLen: faster vector normalization

On Tue, Jul 28, 2015 at 1:26 AM, Werner LEMBERG w...@gnu.org wrote: I still get one warning: ftcalc.c:870:17: warning: implicit conversion changes signedness: 'int' to 'FT_UInt32' (aka 'unsigned int') [-Wsign-conversion] l = 0x1 + (FT_Int32)( u * x + v * y ) / 0x1; ~

Re: [ft-devel] Apple offset scaling

On Tue, Jul 7, 2015 at 11:20 AM, Werner LEMBERG w...@gnu.org wrote: It is well known that offsets in composite or compound glyphs were treated differently by AAPL and MSFT. The former scales them the latter does not [...] Do you have fonts to test? No, unfortunately. What about Apple GX

[ft-devel] FontMatrix contradiction

Hi All, Type 1 fonts use FontMatrix to define scaling from character space to user space. FreeType actually deduces units_per_EM from the yy component of the matrix. This is the primary purpose of FontMatrix. Of course, it can also be used to specify narrowing, expending, slanting, rotation, or

Re: [ft-devel] Apple offset scaling

On Sun, Aug 2, 2015 at 6:03 AM, Christian Demmer ch...@gcjd.org wrote: On Sun, 02 Aug 2015 09:50:21 +0200 (CEST), Werner LEMBERG wrote: I will also send you what I have. I just searched my old stuff and I found Apple's QuickDraw GX v1.1.3 from 1995 containing a folder with Testing Fonts:

Re: [ft-devel] FT_Vector_NormLen: faster vector normalization

I can imagine that introducing some auxiliary variables help clean up *and clarify* the issue. Compilers today are smart enough to optimize them away, causing no loss in speed. My last commit should remove all conversion warnings. ___

Re: [ft-devel] State of autohinter stem darkening

On Thu, Oct 22, 2015 at 10:34 PM, Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > On Thu, Oct 22, 2015 at 7:44 PM, Nikolaus Waxweiler <madig...@gmail.com> > wrote: >>> My monitor is sRGB. Yours is likely too. We are looking at the corrected >>> glyphs. &

Re: [ft-devel] State of autohinter stem darkening

Dave Arnold wrote: > I completely agree with Nikolaus. To state it a different way, correct > anti-aliasing requires that the compositing (alpha blending) is done in a > linear color space. So I quoted your image http://lists.nongnu.org/archive/html/freetype-devel/2013-10/msg00069.html The bottom

Re: [ft-devel] State of autohinter stem darkening

On Thu, Oct 22, 2015 at 3:55 PM, Nikolaus Waxweiler wrote: >> There is a cool image attached to this bug report: >> https://bugreports.qt.io/browse/QTBUG-41590 >> >> Gamma correction makes black text lighter and white text heavier, >> i.e., has opposite effects, i.e., you

Re: [ft-devel] State of autohinter stem darkening

On Thu, Oct 22, 2015 at 12:00 PM, Nikolaus Waxweiler wrote: > And gamma correction leads to better results with light text on dark > background as far as I can see: https://bel.fi/alankila/lcd/ There is a cool image attached to this bug report:

Re: [ft-devel] State of autohinter stem darkening

On Thu, Oct 22, 2015 at 4:43 PM, Dave Arnold <darn...@adobe.com> wrote: > > > On 10/22/2015 12:21 PM, Alexei Podtelezhnikov wrote: >> >> On Thu, Oct 22, 2015 at 12:00 PM, Nikolaus Waxweiler <madig...@gmail.com> >> wrote: >>> >>> And gamma c

Re: [ft-devel] State of autohinter stem darkening

On Sat, Oct 17, 2015 at 4:46 PM, Nikolaus Waxweiler wrote: > > https://github.com/madig/freetype2/tree/stem-darkening-autohinter > Great work! A couple of suggestions though: - I think stem darkening should be tested without gamma applied for many reasons. Your monitor might

Re: [ft-devel] gamma correction demo images

On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > What would be best default value though? David Turner argued > that it is gamma = 1.4 > (http://lists.nongnu.org/archive/html/freetype-devel/2004-06/msg00022.html). > David Arnold also thinks

Re: [ft-devel] gamma correction demo images

On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov <apodt...@gmail.com> wrote: > On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler <madig...@gmail.com> > wrote: >> The world needs more linear alpha blending and gamma correction. Spread the >> gospel! > &

Re: [ft-devel] gamma correction demo images

On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler wrote: > The world needs more linear alpha blending and gamma correction. Spread the > gospel! We can start with changing the default gamma value in ftsting (defaults to 2.0) and ftview (defaults to 1.0). They have always

[ft-devel] gamma correction demo images

http://lists.nongnu.org/archive/html/freetype-devel/2013-10/pngJZYanEzf8F.png That image by Dave Arnold is an outstanding demonstration why gamma correction is necessary on sRGB monitors. I could not help but show this on a different scale, see attached. My recent favorite test is this: ftview

Re: [ft-devel] State of autohinter stem darkening

On Thu, Oct 22, 2015 at 7:44 PM, Nikolaus Waxweiler wrote: >> My monitor is sRGB. Yours is likely too. We are looking at the corrected >> glyphs. > > > No we aren't, precisely because of our sRGB monitors. The bitmaps FreeType > produces wouldn't need to be corrected if our

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On Tue, Nov 10, 2015 at 7:43 AM, Jan Alexander Steffens wrote: > On Tue, Nov 10, 2015 at 1:32 PM, Markus Trippelsdorf > wrote: >> The big problem is that enabling linear blending is a compile time >> option for Qt 5. There is no way to control it

Re: [ft-devel] Turning off stem darkening by default until all drivers support it?

On Mon, Nov 9, 2015 at 4:12 PM, Nikolaus Waxweiler wrote: > So Alexei noted that he found stem darkening too strong. And it got me > thinking again. As long as cairo/Qt5/Skia and others don't ship with LAB+GC... Yes, I am afraid stem darkening is premature until gamma

Re: [ft-devel] gamma correction demo images

> Any progress, Alexei? :) Next release of freetype-demo tools will have starting gamma value of 1.8. http://git.savannah.gnu.org/cgit/freetype/freetype2-demos.git/commit/?id=b48a54c1499debc39e73c1b024064ecb6d24d29e ___ Freetype-devel mailing list

Re: [ft-devel] gamma correction demo images

On Wed, Nov 4, 2015 at 6:24 AM, Nikolaus Waxweiler wrote: > Any progress, Alexei? :) I am sitting here in total disbelief and utterly embarrassed by the lack of gamma correction setting for text rendering in any major Linux desktop environment. How could this happen? Pango

Re: [ft-devel] [ft-announce] Announcing FreeType version 2.6.1

On Wed, Oct 7, 2015 at 4:33 PM, Behdad Esfahbod wrote: > Can you please make more quick-and-small releases for important fixes? It does not matter considering that Fedora 22 runs 2.5.5, which is progressive in comparison to Android 5.1.1 runs 2.5.3 Ubuntu Vivid runs

Re: [ft-devel] [ft] [ft-announce] Announcing FreeType version 2.6.1

On Thu, Oct 8, 2015 at 2:39 AM, Jan Engelhardt wrote: >>Why distributions are more conservative about FreeType than kernel is beyond >>me. > > If you have too old a kernel, some of your hardware may not > activate/behave properly. If you have too old a freetype, the worst that >

Re: [ft-devel] More fuzzing for freetype2?

On Wed, Oct 7, 2015 at 2:57 PM, Kostya Serebryany wrote: >> Yep. If you like, I can give you write access so that you can quickly >> adjust the fuzzer function if necessary. > > Do you have a pre-commit code review process for this kind of changes? > We are just a responsible

Re: [ft-devel] gray_render_scanline: very hot when fuzzing

On Tue, Oct 6, 2015 at 11:43 PM, Kostya Serebryany <k...@google.com> wrote: > On Tue, Oct 6, 2015 at 7:59 PM, Alexei Podtelezhnikov <apodt...@gmail.com> >> Anyhow, there is not much left to do or fuzz after >> rendering, so do not render > > If you

Re: [ft-devel] gray_render_scanline: very hot when fuzzing

On Tue, Oct 6, 2015 at 9:42 PM, Kostya Serebryany wrote: > 51.76% repro_orig repro_orig [.] gray_render_scanline That's been FreeType workhorse since 2.0. You gotta draw those glyphs on a bitmap. It is funny you should mention how expensive divisions there,

Re: [ft-devel] Apple offset scaling

It is well known that offsets in composite or compound glyphs were treated differently by AAPL and MSFT. The former scales them the latter does not [...] Do you have fonts to test? No, unfortunately. You do not have classic Geneva, Chicago, Monaco, and New York, do you? We've got to find

[ft-devel] Apple offset scaling

Hi Toshiya and Werner, It is well known that offsets in composite or compound glyphs were treated differently by AAPL and MSFT. The former scales them the latter does not This page describes offset scaling

Re: [ft-devel] Autohinter: stem darkening, first rough prototype

On Thu, Aug 27, 2015 at 9:02 AM, Werner LEMBERG w...@gnu.org wrote: All of the sudden these 4 pair have an incredible honor to be configurable. Why? What is so special about them? Apparently, nobody can even explain what they mean. ??? They are well documented! The look of the function

<    1   2   3   4   5   6   7   8   9   10   >