Re: [ft-devel] New FreeType release within a week

I think this may be a result of an implementation choice for combining T1 and CFF. There is no limit to the number of hints that can occur in a Type1 charstring. Each time there is a hint substitution, previously used hints are discarded. On the other hand, CFF requires that all hints be

Re: [ft-devel] merged CFF and Type1 hinting code now in master

Hi Werner & Nikolaus, I should back off and leave this a theoretical argument. The synthetic hint example I gave doesn't really fit as well as I was thinking (and may not be as useful for your purpose). Synthetic hints are based on the concept of Ideographic Character Face (ICF). The code

Re: [ft-devel] merged CFF and Type1 hinting code now in master

On 11/20/2017 4:37 AM, Nikolaus Waxweiler wrote: I consider a font broken if it has a blue zone table but no hints – shall we really take care of that?  We don't do any harm; it's just that the font stays unhinted. Hm, well, yeah, it's okay I guess. Might be solved by teaching the Adobe

Re: [ft-devel] [GSoC] CID font support, and others

It should be pretty common when stem darkening is in effect. But it is not used otherwise. -Dave On 8/20/2017 10:31 PM, Werner LEMBERG wrote: It is interesting that `cf2_glyphpath_computeIntersection' never seems to get called... I think `normal' CFFs don't do that... Dave, do you have an

Re: [ft-devel] [GSoC] CID font support, and others

Hi Werner, You are correct that CoolType does not have the improvement that the initial hintmap was designed for. It also does not have some of the heuristics that improve rendering of complex CJK glyphs. On the other hand, CoolType has more code devoted to rendering bilevel bitmaps. (In the

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

Adobe has produced several Open Source CFF fonts that should be useful for testing. Consider: Western sans, serif and monospaced CFF: * https://github.com/adobe-fonts/source-sans-pro * https://github.com/adobe-fonts/source-serif-pro * https://github.com/adobe-fonts/source-code-pro Pan CJK

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

First, a clarification on terminology. I've seen "vertical stem" used to mean either a horizontal stroke that is moved vertically by hinting or a vertical stroke that is moved horizontally by hinting. Nikolaus is using the former here. I am biased to use the latter, because it matches the

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

Hi Ewald, I agree with your conclusion about number formats. Except for the 32000 (not 32768) issue, Type 1 and CFF should be the same. I'm sorry that I don't know enough about Type 1 fonts to answer your other questions. I had never heard of the "postscript stack" before you asked, and I

Re: [ft-devel] [GSoC] Extending the CF2 interpreter

Hi Ewald, I'm not familiar with the FreeType Type 1 code, but Adobe has a combined CFF+Type 1 interpreter where the "PostScript stack" is implemented by a simple array of 3 Fixed elements. I see a comment about a change to "skip the unique id check", if that helps. The large number operator

Re: [ft-devel] CFF: No hinting without vertical/horizontal hints?

complex glyphs into multiple hint zones, using the hintmask operator. -Dave On 6/2/2017 3:14 PM, Nikolaus Waxweiler wrote: Hey list, hey Dave Arnold, I noticed that the CFF fonts served on e.g. https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmedium.com%2F%40raphlinus%2Finside

Re: [ft-devel] CFF divide operator

I'd recommend a fixed point divide, for cross platform compatibility. On 2/4/2016 7:16 PM, Derek B. Noonburg wrote: Here's a patch that fixes it -- at least for the fonts I'm looking at. I'm doing a floating point divide and then converting to fixed point. There may be a better way to handle

Re: [ft-devel] gamma correction demo images

Yes, the only difference in blending is that subpixel mode does it 3 times per pixel. The filter is color-balanced, but not normalized. Values above 0x100 will have to be clamped and this non-linearity causes distortion and adds to color fringing. Stem darkening is the better way to increase

Re: [ft-devel] Writing about the new stem darkening autohinter

Hi Nikolaus, This is a good description and is accurate. Two minor comments: You might consider a brief mention of cases that are not black-on-white. I don't understand the lines at the bottom, where I see "I don't want this" and "---". Is something missing here? Thanks. -Dave On 11/6/2015

Re: [ft-devel] gamma correction demo images

On 11/4/2015 7:27 AM, Alexei Podtelezhnikov wrote: 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

Re: [ft-devel] gamma correction demo images

On 10/28/2015 5:57 AM, Behdad Esfahbod wrote: On 15-10-27 08:25 PM, Alexei Podtelezhnikov wrote: On Mon, Oct 26, 2015 at 10:26 AM, Alexei Podtelezhnikov wrote: On Sun, Oct 25, 2015 at 2:35 PM, Nikolaus Waxweiler wrote: The world needs more linear

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

On 10/22/2015 11:56 PM, Nikolaus Waxweiler wrote: Perhaps, this is the explanation I was looking for. You are basically saying that sRGB imposed by the monitor is not a good idea for high contrast text rendering and has to be undone. I can buy that. So when you talk about gamma of about 2 you

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

On 10/22/2015 12:21 PM, Alexei Podtelezhnikov wrote: 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

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

On 10/22/2015 12:48 PM, Alexei Podtelezhnikov wrote: 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

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

On 10/22/2015 12:55 PM, Nikolaus Waxweiler wrote: Mac OS X is probably doing it that way (Dave? ;)). I haven't checked lately, but a couple of years ago, Apple (MacOS and iOS) was doing something strange. There were indeed using linear blending for subpixel/LCD rendering. Here, there is an

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

On 10/22/2015 9:00 AM, Nikolaus Waxweiler wrote: - I think stem darkening should be tested without gamma applied for many reasons. Your monitor might have additional gamma correction settings, which might be different from mine. Gamma correction works against you when you render light text on

[ft-devel] aux.c on windows

I have run into an obstacle trying to build freetype2-demos on Windows. Incredible as it seems, it is not possible to create a file with the name "aux". See https://msdn.microsoft.com/en-us/library/aa365247.aspx. This means I cannot git fetch the demos, let alone build them. Unless someone

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

Hi Nikolaus, I used a zoom-in tool to examine the pixels in your before and after screen shots. The left sides of the stems were unchanged while the right sides were darker. Alexei has explained how this is the result of using the existing emboldener. I don't think it is a problem. It only

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

Hi Nikolaus, This looks good! Question: I see the extra weight is applied only to the right hand side of the vstems. Is this because of the way the emboldening function works? Have you noticed any issues with the sub-pixel translation that this causes? (I don't think so, and they are

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

Two quick thoughts: Don't use .jpg for screen shots. The compression hinders analysis of the rendered pixels. I recommend lossless .png. Are you missing a units-per-em normalization somewhere? I.e., 1000 CFF vs. 2048 TTF? Could that be causing too much darkening? -Dave On 9/1/2015 1:26 PM,

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

On 8/28/2015 7:10 AM, Nikolaus Waxweiler wrote: You want a *global* stem width for all scripts within a font? I'm not sure whether this is a good idea. Uh, I thought that's how it works for Postscript and OpenType/CFF fonts? I'm only aware of the (face-)global dict with a face-wide stdVW.

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

On 8/27/2015 8:44 AM, Alexei Podtelezhnikov wrote: On Thu, Aug 27, 2015 at 10:46 AM, Nikolaus Waxweiler madig...@gmail.com wrote: The look of the function is documented and it blows my mind. I want to know what they smoked. You simply cannot find such beasts in nature short of quantum

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

On 8/26/2015 6:02 AM, Alexei Podtelezhnikov wrote: On Tue, Aug 25, 2015 at 6:50 PM, Dave Arnold darn...@adobe.com wrote: It should be monotonic. It should have a minimum of around .4 or .5 pixels. It should go to zero at around 2 pixels. darkening = stem 2 ? 0.5 - stem / 4 : 0

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

Hi Dave, On 8/25/2015 8:53 PM, Dave Crossland wrote: As you noted, stdHW and stdVW are normally obtained from a CFF font dictionary. For TT, we (at Adobe) estimate stem width values based on the OS/2 weight class. We use three values, light (50/1000), regular (75/1000) and bold (110/1000).

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

I'm happy to see all of this activity on stem darkening in the past week. It looks like excellent progress. I'm sorry it was a period when I was on vacation and away from email. Hopefully, most questions have been answered, but please let me know if there are outstanding issues that I can help

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

than just linear. Why can't we just use something like this? darkenAmount = 0.5 pixels - ( scaledStem / 4 ) Dave Arnold explained this to me some years ago. However, I no longer can remember why Adobe introduced this feature. Dave, can you please tell us the reason (again)? Werner

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

because font rendering is a dear topic to me. What immediately stands out is that rendered fonts are much thicker than what the autohinter puts out. This creates a somewhat strong contrast between local .otfs and web fonts when browsing the net. Now, Dave Arnold said in an old mail to list

Re: [ft-devel] GX support now working

From: Behdad Esfahbod behdad.esfah...@gmail.com Sent: Thursday, June 25, 2015 11:17 PM To: Werner LEMBERG; Dave Arnold Cc: freetype-devel@nongnu.org Subject: Re: [ft-devel] GX support now working On 15-06-25 10:55 PM, Werner LEMBERG wrote: The threshold is 400 ppem. Below

Re: [ft-devel] GX support now working

Hi Werner, On 6/8/2015 2:20 AM, Werner LEMBERG wrote: Adobe rasterizers typically use even-odd at small sizes and non-zero at larger sizes. Interesting. What's the rationale for that? And which ppem values are `small sizes'? I would also like to know whether this is a general thing,

Re: [ft-devel] Build errors with MSVC

Might it be this bug: https://connect.microsoft.com/VisualStudio/feedback/details/718976/msvc-pr? I see this warning on line 1095: warning C4003: not enough actual parameters for macro 'SET_DARKENING_PARAMETERS_0' -Dave On 10/22/2014 5:50 AM, Werner LEMBERG wrote: I then changed lines 1094

Re: [ft-devel] Possible typo in cf2hints.c

Indeed, you are correct. This is a typo. Good catch! Thanks. -Dave On 7/17/2014 3:26 AM, maks wrote: cf2_glyphpath_computeOffset() /* third quadrant, -x -y */ if ( -dx -2 * dy ) { /* -x */ *x = 0; *y = 2 * glyphpath-yOffset; } else if ( -dy -2 * dx ) { /* -y */ *x =

Re: [ft-devel] CFF hinting (was gamma correction and FreeType)

results were frequently better than the original TT. Unfortunately, the Adobe autohinter is not open source and is better suited to offline usage (i.e., convert at authoring time, not at client viewing time). Thanks. -Dave On 11/12/2013 10:52 PM, Antti Lankila wrote: Dave Arnold darn

Re: [ft-devel] gamma correction and FreeType

or contrast to cause such bleed? -Dave On 11/8/2013 4:39 PM, Søren Sandmann wrote: Dave Arnold darn...@adobe.com writes: I agree in theory that gamma correction should make the weight of black text and white text appear the same. It's not clear to me that this is the case. Consider the following

Re: [ft-devel] gamma correction and FreeType

Nothing stupid that I can see :-) . FreeType 2.5 made the new Adobe CFF rasterizer the default hinting engine for CFF. You can, at run time, select the autohint engine as an alternative. -Dave On 11/9/2013 2:20 AM, Antti Lankila wrote: Dave Arnold darn...@adobe.com kirjoitti 8.11.2013 kello

Re: [ft-devel] gamma correction and FreeType

This does look encouraging. Thanks. On 11/6/2013 11:41 PM, octoploid wrote: 01.11.2013, 06:31, Werner LEMBERG w...@gnu.org: thanks a lot for your good demonstration images! I believe column 3 is what we want to achieve. Yes, indeed! It looks like we need to extend the Xorg Render

Re: [ft-devel] gamma correction and FreeType

Alexei, My main point is that linear blending should be used for antialiased text. After that, the precise gamma value is of secondary importance. -Dave On 11/7/2013 10:58 AM, another gol wrote: why is that? If the correction turns a logarithmic gradient into a visibly linear one, how does

Re: [ft-devel] gamma correction and FreeType

Hi Antti, On 11/7/2013 12:43 PM, Antti Lankila wrote: Yes, I personally believe that ”optimal translation and scaling”, despite being an irritating parameter space search, would likely be the limit of the technique. More complicated strategies such as splitting the glyph box and

Re: [ft-devel] gamma correction and FreeType

, where white text appears too heavy at 2.2. I'd really like to understand that. -Dave On 11/7/2013 12:20 PM, Antti Lankila wrote: Dave Arnold darn...@adobe.com kirjoitti 7.11.2013 kello 20.02: The first is something I call effective gamma. We first encountered this back in the era of CRT

Re: [ft-devel] gamma correction and FreeType

Hi Søren, My intuition is that it should always be an light/photon flux integration problem, in linear space. That is, #1 is always correct. If #2 were correct, then the color would change as you walked toward or away from a display of the test pattern. Have you ever seen this effect in the

Re: [ft-devel] gamma correction and FreeType

between sharpness color fringing. On Thu, Nov 7, 2013 at 7:02 PM, Dave Arnold darn...@adobe.com mailto:darn...@adobe.com wrote: You are correct that gamma 2.2 is a better approximation to sRGB. I agree with using that gamma for large area regions. But there are two reasons why I prefer gamma

Re: [ft-devel] gamma correction and FreeType

Hi Antii, Thank you for the interesting page. The text looks good, but I think we differ a bit in our hinting philosophy :-) . I completely understand why many people have an aversion to the way hints can distort a typeface design. I've seen examples where you might be fooled into thinking

Re: [ft-devel] gamma correction and FreeType

Hi Werner, Yes, Beat Stamm has supplied a great deal of interesting detail. I don't think it is practical to change the system color space; too many things depend on the assumption of sRGB. You might consider changing the color space of a single application (e.g., to a linear space) but you'd

Re: [ft-devel] Problems compiling freetype into dll

That seems to fix it. Thanks. On 7/10/2013 3:21 PM, Werner LEMBERG wrote: A few Error 127 messages still occurred until I removed \mingw\msys\1.0\bin from the path, as you suggested. What about leaving the path as-is, but saying mingw32-make SHELL=CMD.exe ... instead? Werner

Re: [ft-devel] Problems compiling freetype into dll

Hi Werner, You have provided another hint. I was using make which is in \mingw\msys\1.0\bin. But you mentioned mingw32-make. This program is in \mingw\bin. I did not realize that mingw came with two versions of make! mingw32-make works much better. A few Error 127 messages still occurred

Re: [ft-devel] Problems compiling freetype into dll

I have also seen the Command not found and Error 127 messages when trying to run make with mingw. Since the ver and type commands are built-in, I assumed something in the make script was running a shell other than cmd. On 7/7/2013 7:19 PM, Werner LEMBERG wrote: C:\ft2501\freetype-2.5.0.1make

Re: [ft-devel] new CFF engine

And maybe made configurable from fontconfig like what the Cleartype tuner on Windows 7/8 does. Yes, maybe. However, stem darkening is a font driver property and not to be changed font-wise. Werner Within the new CFF hinter, stem darkening automatically accounts for font weight. At a

Re: [ft-devel] Adobe CFF hinter for type 1 fonts

On 5/4/2013 10:54 PM, Werner LEMBERG wrote: As far as I understand, both Type 1 fonts and CFF use the same or similar rendering. Would it be possible to use the new Adobe engine for type 1 fonts? The are currently quite a few bugs open about the rendering quality of type 1 fonts and I've