Re: [ft-devel] [Fontforge-devel] Peter Wiegel's auto spacing idea

[Behdad Esfahbod]

http://charlesmchen.github.com/typefacet/topics/autokern/index.html


On 06/15/2012 03:20 PM, Nathan Willis wrote:
> My understanding is that the auto-kerning implemented by Zapf's Hz-program is
> now patent-free due to 2010 patent expiration.  Is anyone familiar with the
> approach used there?
> 
> URW supposedly published a book about it, but only in Germany (and doubtless
> in less-than-Twilight quantity).  I've looked for a copy before, without
> success....
> 
> Nate
> 
> On Fri, Jun 15, 2012 at 1:48 PM, <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On Thu, 14 Jun 2012, Vernon Adams wrote:
>     > This is very interesting, reminds me of David Kindersley's work on
>     > 'optical spacing'. I think that spacing for web and screen fonts could
>     > be dealt with like this fairly straightforward because of the role that
>     > the pixel grid plays in determining final rendered spacing. Would be
>     > interesting to test it. Also thinking this could be built into an app
>     > like robofont very easily - would just need to add a blur effect etc to
>     > the glyphs in spacing mode. could that be done in fontforge too? Using
>     > freetype or pango?
> 
>     There's code in my Tsukurimashou package that implements an auto-kerning
>     algorithm serving a similar purpose to these ideas but with a few more
>     features.  The general idea is that I first calculate a left and right
>     contour for each glyph; the contours follow the actual shape of the glyph
>     except that there's a limit on how shallow the contour angles can be.
>     Then to kern a pair, I compute a distance measure between the contours
>     equal to the average inverse cube of the distance between the left and
>     right glyphs' contours.  The glyphs are kerned to make that measure equal
>     to a constant.
> 
>     Using the actual shapes of the glyphs, even smoothed, is undesirable
>     because it can result in one glyph sliding too far under another, for
>     instance between apostrophe and period; those two can never be pushed
>     together far enough to make them touch because they don't share any
>     subset of the vertical extent.  My existing code still needs some tweaking
>     for this kind of situation, but the slope limit helps a lot.  A glyph like
>     "." is in effect kerned as if it looked like "/" and "\" on its two sides,
>     preventing it from sliding too far under any other glyph.
> 
>     Using "until the contours touch" is undesirable because it places too much
>     weight on the single point of closest approach, which may not be visually
>     significant.  This effect is visible in serif fonts with pairs like "AV",
>     where there may be serifs that should be brought much closer together than
>     the distance you would generally want for flat parts of glyphs;
>     auto-kerning algorithms in general tend to put such pairs too far apart
>     because of putting too much weight on the serifs.  You want to give some
>     weight to both the nearest-approach points, and other parts of the glyphs
>     that may be a little further apart; that requires something a little
>     softer than a pure touch/don't touch test.  Blurring may be intended to
>     serve a similar purpose, but my own code uses nonlinear weighting on
>     the hard outlines in order to produce a more controllable effect.  The
>     exponent of 3 seems to produce the most appealing results in my tests.
> 
>     As I mentioned, there are still some issues with glyphs that have very
>     little vertical extent, such as apostrophe.  I've also found that the
>     adjustable parameters in the algorithm need to be different for Latin,
>     Japanese, and Korean glyphs, in order to produce results that mix well
>     with each other.  The spacing readers expect between characters in those
>     writing systems is simply different.
> 
>     I don't have a link for just the documentation file describing this, but
>     both the code and the PDF user manual explaining how it works are in the
>     Tsukurimashou distribution package available here:
>      
>     
> http://en.sourceforge.jp/projects/tsukurimashou/downloads/54223/tsukurimashou-0.5.zip/
> 
>     --
>     Matthew Skala
>     address@hidden <mailto:address@hidden>                
>     People before principles.
>     http://ansuz.sooke.bc.ca/
> 
>     
> ------------------------------------------------------------------------------
>     Live Security Virtual Conference
>     Exclusive live event will cover all the ways today's security and
>     threat landscape has changed and how IT managers can respond. Discussions
>     will include endpoint security, mobile security and the latest in malware
>     threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>     _______________________________________________
>     Fontforge-devel mailing list
>     address@hidden
>     <mailto:address@hidden>
>     https://lists.sourceforge.net/lists/listinfo/fontforge-devel
> 
> 
> 
> 
> -- 
> nathan.p.willis
> address@hidden <mailto:address@hidden>
> aim/ym/gtalk:n8willis
> identi.ca/n8 <http://identi.ca/n8>
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> 
> 
> 
> _______________________________________________
> Fontforge-devel mailing list
> address@hidden
> https://lists.sourceforge.net/lists/listinfo/fontforge-devel