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

(repost to the list because I forgot to correct the addressee) > This `fix' is purely accidental, unfortunately. There is no guarantee that you get similar well-looking results with other fonts. I noticed already, Open Sans Bold likes to snap 1 pixel too high. You might convert metric

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

Emboldening changes the outline but not the metrics or blue zones. It is up on you to deal with it. Here is an idea to brush it aside gracefully: embolden and scale back. Yes, emboldenig changes the bounding box predictably, so that you can restore it by scaling back. This will eat away some of

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

On Mon, Sep 21, 2015 at 8:19 AM, Nikolaus Waxweiler wrote: >> Or maybe >> you extend the blue zone data structures with resolution-dependent >> versions that you can adjust for emboldening. > > > Hm. You mean taking the emboldening strength in font units and adjusting > the

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

After a bit of testing, I think I know where the glitches come from. They are usually digits (0, 2, 8), overshoots (C) or other parts (lower belly of R, see the last two comparison shots) being snapped to 1 pixel above where they should be. Emboldening probably lands the top of the stems

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

> After a bit of testing, I think I know where the glitches come from. > They are usually digits (0, 2, 8), overshoots (C) or other parts > (lower belly of R, see the last two comparison shots) being snapped > to 1 pixel above where they should be. Emboldening probably lands > the top of the

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

I was going to write a long mail and moan about how complicated FreeType is and how my stem darkening just wasn't pleasing to look at. Then I fiddled around some to prove a point and suddenly LOOK AT THIS: http://postimg.org/image/el0egghrl/full (no emboldening)

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

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. Ah, okay ;) 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

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 unhinted anyway) How did you see that?

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

On Tue, Sep 8, 2015 at 1:22 PM, Dave Arnold wrote: > 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? Yes, FreeType emboldener shifts the outline so that the bottom-left of the

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

> http://postimg.org/gallery/vgi21eka (all with gamma correction, ftview > left-to-right: no hinting, autohinter without emboldening, autohinter > with emboldening) > > I think this is it :) Very nice, thanks! Unfortunately, I currently don't have sufficient time to review the code; probably in

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

Very nice, thanks! Unfortunately, I currently don't have sufficient time to review the code; probably in the beginning of October. Sure, what matters is that it finds its' way to master and to the masses eventually :) I'll test out Dave's 300,250,250,0 parameters in the mean time and maybe

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

I just left the house and suddenly realized that the conversion from font to device pixel units could be wrong. Emboldening by at most 0.4 Pixels translates to at most 26 times 1/64th of a device pixel (ft_pos). I think I saw bigger numbers. Gah! Will check the code tomorrow and feel stupid in the

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

I'm a giant dunce. I forgot to convert character space to device space... No wonder FT_Outline_Embolden produced garbage, especially at small sizes. Emboldening looks good now with the default CFF parameters without any tweaking! http://postimg.org/gallery/vgi21eka (all with gamma correction,

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

Don't use .jpg for screen shots. The compression hinders analysis of the rendered pixels. I recommend lossless .png. That's what I uploaded, click the image ;) Are you missing a units-per-em normalization somewhere? I.e., 1000 CFF vs. 2048 TTF? Could that be causing too much darkening? Hm,

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

I had a quick look at various fonts and darkening seemed fine, but CJK glyphs (SourceHanSansCN-Regular.otf) appeared a bit thin compared to the CFF engine. Will investigate... some other time. I think I figured it out. Reverted commit c5b5e469b34ddc87fa379bfa0a5379835191ee23. Turns out my

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

Where's the problem? The auto-hinter provides different standard width values depending on the script. It tries up to three characters (cf. the last three arguments to the `SCRIPT' macro in file `afscript.h') in function `af_latin_metrics_init_widths' for finding a standard width. As soon as

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

I changed the strategy to get the standard_width of a face. Instead of relying on the hard-to-follow workings of the style analyzers, [...] Where's the problem? The auto-hinter provides different standard width values depending on the script. It tries up to three characters (cf. the last

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

But we are now constrained by compatibility. We actually aren't! Please explain. Werner ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

I'm awaiting your patches :-) Heh ;) Why `once per size'? The auto-hinter computes the standard widths in *font units*, this is, the values are unscaled! Ah, yes, thinko. I meant once as opposed to several times due to lazy evaluation. ___

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

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. If not, I will need to rethink my approach ;)

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

Thanks for the explanation. The source code needs comments like that :) I'm awaiting your patches :-) In my first prototype, I tried to get a face-wide stdVW and modified af_latin_metrics_init_widths to upload whatever is computed to AF_FaceGlobals. Then I found that when displaying all

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

On 15-08-27 11:06 PM, Werner LEMBERG wrote: But we are now constrained by compatibility. We actually aren't! ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

On 15-08-28 02:43 PM, Werner LEMBERG wrote: But we are now constrained by compatibility. We actually aren't! Please explain. The rendering of CFF fonts changed drastically from one FreeType version to another. The effect of FT_LOAD_IGNORE_GLOBAL_ADVANCE_WIDTH changed from one version to

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

Here's a piece of Python code for whoever wants to compare curves... On 15-08-27 04:44 PM, 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.

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

The auto-hinter computes the standard widths in *font units*, this is, the values are unscaled! Ah, yes, thinko. I meant once as opposed to several times due to lazy evaluation. You want a *global* stem width for all scripts within a font? I'm not sure whether this is a good idea.

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

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. Normal Type1 fonts work like that. CFF, on

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

On 15-08-28 03:10 PM, 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

I'm only aware of the (face-)global dict with a face-wide stdVW. I forgot to mention that the subfonts of HiraKakuPro *roughly* fit auto-hinter scripts; in other words, the idea of determining separate standard width values for different scripts is not far-fetched. Werner

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

Whatever, I don't mind. However, the four parameter pairs must stay. Freetype relies on gazillion of empirical constants in the code. Not a single one of those was has ever been promoted to a configuration file. All of the sudden these 4 pair have an incredible honor to be configurable.

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

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 mechanics. I simply cannot trust that it was optimized rationally by looking at the rendering results, because optimizing in 8-dimensional

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

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

The simplest is to check if you see any difference with this set of parameters: Thanks. Quick comparison shot: http://postimg.org/gallery/2x7v9bhde/f0fbee3e/. The difference here is subtle. It seems to make Source Sans Pro lighter (Adobe CFF engine) while not changing Linux Libertine

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

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 mechanics. I simply cannot trust that it was optimized

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

I pushed some changes to https://github.com/madig/freetype2/tree/stem-darkening-autohinter. I have that branch installed system-wide for proper dog-fooding ;) I changed the strategy to get the standard_width of a face. Instead of relying on the hard-to-follow workings of the style analyzers,

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

But we are now constrained by compatibility. Well, it was the simplest solution to stay with the original code then. By the way, the current default (Adobe and FreeType) for CFF can be expressed as 400,275,275 (y1,y2,y3). For comparison, the reduced darkening for TT (in Adobe's product) is

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 Thu, Aug 27, 2015 at 4:45 PM, Dave Arnold darn...@adobe.com wrote: I'd propose a single value from 0 to 1 (or maybe 0 to 100) that would linearly scale y1, y2 and y3 together, between zero and the default. I would make x1, x2, x3, x4 and y4 constant. But we are now constrained by

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

So let's stay with what we have, for the sake of a uniform interface to stem darkening. Or switch CFF to the new simplified one if they are close enough (my recollection of the CFF curve is that they are.) Whatever, I don't mind. However, the four parameter pairs must stay. Werner

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

On 15-08-26 06:59 PM, Werner LEMBERG wrote: So let's stay with what we have, for the sake of a uniform interface to stem darkening. Or switch CFF to the new simplified one if they are close enough (my recollection of the CFF curve is that they are.)

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

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; /* THIS IS IT! */ Why does it have to be more complex than this and be so kinky? Your simplified function may be good enough.

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; /* THIS IS

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

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; /* THIS IS IT! */ Why does it have to be more complex than this

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

So let's stay with what we have, for the sake of a uniform interface to stem darkening. Well, if we need different parameters for horizontally snapped outlines like Dave said? More experimentation is necessary I think... ___ Freetype-devel mailing

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

So let's stay with what we have, for the sake of a uniform interface to stem darkening. Well, if we need different parameters for horizontally snapped outlines like Dave said? More experimentation is necessary I think... I don't talk about the parameter *values* but the number of

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

Here's what I recall about the darkening curve. The shape of the curve was largely determined experimentally, but there are certain principles. It should be monotonic. It should have a minimum of around .4 or .5 pixels. It should go to zero at around 2 pixels. It is important that fonts with

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

I haven't yet looked closely at the new code, but I think that the original one in function `cf2_computeDarkening' (in file `cf2font.c') is quite straightforward – and it is well commented :-) I do not get why this function should be piecewise linear, rather than just linear. Why can't

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] Autohinter: stem darkening, first rough prototype

Would be easier if you push a tree to github. Done. https://github.com/madig/freetype2/tree/stem-darkening-autohinter ___ Freetype-devel mailing list Freetype-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/freetype-devel

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

I forgot to attach the patch. Duh. diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h index cf7b76f..68d59e7 100644 --- a/include/freetype/ftautoh.h +++ b/include/freetype/ftautoh.h @@ -439,6 +439,36 @@ FT_BEGIN_HEADER */ +

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?

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

Hi list, so I just finished a very rough prototype for stem darkening for the autohinter. This is not meant for inclusion into master but rather as a starting point for discussion. Apply patch against master. The code has numerous problems: 1. The function to compute how much darkening to

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

I just noticed that the darkening calculation might be off, making stuff excessively bold. Here's a new patch. Sorry :( diff --git a/include/freetype/ftautoh.h b/include/freetype/ftautoh.h index cf7b76f..68d59e7 100644 --- a/include/freetype/ftautoh.h +++ b/include/freetype/ftautoh.h @@ -439,6

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