Wee sugg: Add Fontlab to the requirements list.

It is probably not a good idea to change the sidebearings as you do.

Té: Fontlab isn't required.
frode: There's an argument (--do-not-modify-side-bearings ) that allows you to preserve current side bearings. If it is present, Autokern only modifies the kerning table.

Awesome news, will try it

Feels to me like the weighting for distance of outline to advance width is linear in your algorithms. Is that correct? Seems like the more sophisticated approaches use non-linear weighting....

PabloImpallari : Great! It's early days and the manual isn't very complete or well written. Please feel free to get in touch if you have questions of want help. charlesmchen@gmail.com.
Thomas Phinney: It's not linear. The algorithm uses linear calculations only for the upper and lower bounds of glyph spacing. ie. the user set a hard lower bound for how close two glyphs can be, and this is enforced linearly. The actual spacing algorithm is rather complicated. I intend to document it once I've settled upon some of the details...

By the way: I've also been working (on & off) in a "spacing" macro, but is not yet released.
http://typedrawers.com/discussion/52/spacing-macro
You can read some of the logic in that post.

I am mistaken, then, that that some of the dependencies are specific to Fontlab or its rellies? Good to know I'm fallible. I was getting worried.

Trying to install it, found that my current python is v2.6
I'm not sure how to upgrade it, and a little afraid that my other macros may break if I upgrade python.
Anyway, when trying to install it under v2.6, on step 4 got this error: "No module named yaml". And have no clue on how to install the yaml module.

Excellent :) a new tool for the free font toolkit. Not looked at it yet, but being python based could it be made to tie in with robofont and metrics machine?
_v

This is really great!

Pablo, I got the same problem as you. Here on Ubuntu I solved it by installing the package python-yaml which also loads libyaml-0-2

Now I’m stuck with the following error:

python Autokern.py -h
Traceback (most recent call last):
File "Autokern.py", line 78, in
locale.setlocale(locale.LC_ALL, 'en_US')
File "/usr/lib/python2.7/locale.py", line 539, in setlocale
return _setlocale(category, locale)
locale.Error: unsupported locale setting


PabloImpallari: I'll check it out.
Té Rowan: Let me know if you have any problems using it. I'm pretty sure FontLab isn't a dependency since... I don't have FontLab. =)
PabloImpallari: As georg pointed out, the yaml module doesn't come with Python 2.6. I'm going to modify the installation guide today to work for Python 2.6.
vernon adams: It should be usable from robofont. I was wondering whether or not to make a robofont plugin. I actually think it might be easier to work with outside robofont using the Autokern's HTML logs than using robofont's Kerning view.
georg: I'm going to try to make Autokern Python 2.6 compatible today.

I am very happy to see this!

I believe that BatchCommander - https://bitbucket.org/rlafuente/batchcommander/ - could be a simple way of providing a GUI to enable a designer to tweak input parameters and explore the ranges of results that are possible.

FontForge accepts add-ons written in Python, but I have no knowledge of the details or how easily this tool could be adapted.

»georg: I'm going to try to make Autokern Python 2.6 compatible today.

Thank you, but my problem shouldn’t be related to Python 2.6 as I do have Python 2.7 installed.

Charles,
An observation :)
This is a very interesting piece of work, and i'm thinking could your methods and libs not also be applied to 'spacing' a font too? aka finding the best values for left & right sidebearings before looking for values for kerning pairs?

-v

georg: I believe I've resolved your locale issue.
vernon adams: by default autokern does both auto-spacing and auto-kerning. If you just want the auto-kerning, use the --do-not-modify-side-bearings argument.

To be clear, Autokern is very early in its development process. The results are not very good yet, and I'm still in the process of trying new approaches. I think the results have improved quite a bit in the last few days alone.

Right now, I'm looking for two things:
a) critiques (as detailed as possible) of the current output from a type designer's point of view. See the samples:
http://charlesmchen.github.com/typefacet/topics/autokern/league_gothic/s...
http://charlesmchen.github.com/typefacet/topics/autokern/linden_hill/sam...

b) anyone who'd like to discuss kerning theory and automation.

Cheers!

The straight-sided sans examples look like better results (as one would predict).
Most of the problems arise in too close kerns where you get overlapping (/L4/ and /r?/ in the sans are good examples). The tightness around the exclamation point in the serif is also way overdone.

Seems to work now. It now only issues a warning:
Could not set locale: unsupported locale setting
but it continues nevertheless.

@Charles: I'm eager to try it out, but so far I was unable to install it. Will keep trying and report back.

Ok. So who has this up and running? :) did it run out of the box? if not how did you get it running? OS? python version? etc etc ?
Unsucessful so far on Fedora 17, OSX 10.6 & 10.7
Would very much like to get this running.

now up and running on OSX 10.7 :) using the git source of Typefacet from github.

Some pointers for those needing help. I followed the following (nabbed from http://mirror.umd.edu/roswiki/electric(2f)Installation(2f)OSX(2f)Homebrew.html) to get the proper dependencies, e.g. libyaml & pyyaml installed.

1. Change the permissions of your Python, Ruby, and Perl library directories to prevent the need for sudo when running pip. This is recommended by the Homebrew developers.

sudo chown -R $USER /Library/Ruby /Library/Perl /Library/Python

2. Add the following line to your ~/.bashrc file (make a .bashrc file if you dont have one)
export PYTHONPATH="/usr/local/lib/python2.7/site-packages:/usr/local/lib/python:$PYTHONPATH"

3. Install cmake for build systems and libyaml for reading configuration files:

brew install cmake libyaml --universal

4. Install pip, which is a package manager for Python, using easy_install:

sudo easy_install pip

5.Install PyYaml, the python interface to libyaml:

sudo pip install pyyaml

6. now all is well when running
env PYTHONPATH=dependencies/robofab:dependencies/pystache:dependencies/svgwrite:python/src-main python python/src-main/autokern/Autokern.py -h"
in the Typefacet directory.

now off to play ;)

@vernon adams I'm surprised any of that was necessary. I'm going to try a clean install now on a 10.7 box and will update the installation guide (http://charlesmchen.github.com/typefacet/topics/autokern/typefacet-autok...) if necessary.
Anyhow, please let me know if you need any help.

@eliason Thank you. One thing I've tried (but failed) to avoid in the examples was confusing Autokern's algorithm with its configuration. Autokern behavior is very dependent on its configuration (ie. its arguments, collectively). I believe many of the problems you've identified can be fixed by altering the configuration rather than modify Autokern itself. I'll try to update the examples accordingly when I can.

Charles,

Digging into terminal commands (or Python for that matter) is a very steep wall to climb for many, if not most, type designers. I suggest you give it a simple interface to see if it gains traction. As other have noted: Spacing (incl. kerning) and drawing cannot be separated in professional type design. Keep that in mind.

@vernon adams: You were right, the PyYaml dependency was missing. I've updated the project and the installation guide to reflect that. One should be able to run on OS X 10.6 or 10.7 now without ever using pip, homebrew or sudo'ing anything. Thanks.

I finally get it running, but when trying to use it I get this error:

Pablo-Impallaris-iMac:typefacet pabloimpallari$ env PYTHONPATH=dependencies/RoboFab/lib:dependencies/pystache:dependencies/svgwrite:dependencies/PyYaml/lib:dependencies/FontTools/Lib:python/src-main python python/src-main/autokern/Autokern.py \
> --ufo-src-path /Users/pabloimpallari/Desktop/font.ufo \
> --ufo-dst-path /Users/pabloimpallari/Desktop/font-kerned.ufo \
> --min-distance-ems 0.04 \
> --max-distance-ems 0.04 \
> --max-x-extrema-overlap-ems 0.1 \
> --intrusion-tolerance-ems 0.1 \
> --precision-ems 0.005 \
> --log-path logs \
> --kern-samples-only

Processing configuration...
Renaming old logs folder to: logs.2
ignoring 35 / 459 glyphs
kerning 143 / 179,776 pairs

Processing kerning pairs...

P vs. J 8218 / 210681 (3.90%) 21 seconds remaining
f vs. o 34358 / 210681 (16.31%) 20 seconds remaining
W vs. M 70445 / 210681 (33.44%) 14 seconds remaining
exclam vs. r 127333 / 210681 (60.44%) 7 seconds remaining

Updating kerning...
Writing samples...
Error: 'NoneType' object has no attribute 'minX'
Traceback (most recent call last):
File "python/src-main/autokern/Autokern.py", line 3193, in
autokern.process()
File "python/src-main/autokern/Autokern.py", line 3161, in process
self.writeSamples()
File "python/src-main/autokern/Autokern.py", line 3011, in writeSamples
sampleTextMap, kerningValues = self.renderTextWithFont(sampleText, self.srcUfoFont, self.srcCache, 'Original', 0x7f7f7faf)
File "python/src-main/autokern/Autokern.py", line 2976, in renderTextWithFont
converted = self.convertTextToContours(text, ufoFont, cache, lastKerningValues=lastKerningValues)
File "python/src-main/autokern/Autokern.py", line 2900, in convertTextToContours
xExtremaOverlap = minmax.minX - lastMinmax.maxX
AttributeError: 'NoneType' object has no attribute 'minX'

(tofollow)

Now have this running under GNU/Linux (fedora + ubuntu). To get this running i installed latest 'Robo_Fab560M_plusDependencies' from robofab.org, then typefacet is running without hitch.

My experience so far, is that typefacet can create the appearance of adequate-good spacing, but it is relying too much on kerning pairs to achieve that :D (not good practice). However, by running the scripts selectively with the --only-modify-side-bearings arg on e.g. just lowercase, uppercase and both, i think i can see useful potential for the tool. It seems to do a pretty good job of getting the widths right, even when the side bearings are off :) so potentially very usefull for pre- manual spacing. Also potentially good tool for primary stages of font development to space glyphs in order to aid the optical widths etc of new glyphs and the emerging face. Certainly better than other auto spacing tools imho. Pretty sure this will get better. Maybe needs to be forked into separate 'spacing tool' and 'kerning tool'??

@frode frank: I think you're right, a UI would make this tool far more accessible. I'll think this over.
@PabloImpallari: Thank you for your persistence. I think I resolved this issue yesterday. Please try again.
@vernon adams: Thanks for the thoughtful comments. Autokern can now be run in three modes: auto-space only, auto-kern only or both. All three modes can be limited in scope (ie. kern only these glyph categories, glyphs or pairs). So I'm not sure if there's a need to divide it into separate tools. But I think you're right that it's worth thinking over how these separate uses can or should be handled differently.

Charles - yes, i agree actual separate 'apps' are not necessary. For those interested, i've been testing on trying to get the amount of kerning pairs generated, way down, to anywhere between 200 - 1500 pairs, and still produce good spacing and kerning throughout a font. With that scenario i can see much better if the tool is able to produce good, funcional, and practical results. Takes a lot of tweaking ;) but i think i can see it does work, though i'm getting some results (a few kerned pairs) that are not what i would probably do manually, and i think i would manually tweak these later. So with simple sans-serifs (serif faces would likely respond differently) i'm getting best results with parameters like
--intrusion-tolerance-ems 0.0
--min-distance-ems 0.094
--max-distance-ems 0.095
--kerning-threshold-ems 0.0135
--max-x-extrema-overlap-ems 0.0
--precision-ems 0.0030

Also helps to use something like
--glyph-categories-to-ignore P* S* C* N*
to ignore numerals, punctuation, symbols, etc and then target these separately.

-vernon

I've long thought that a necessary function of any autokern tool should be the ability to set up non-kerning control pairs. So, for instance, if one assumes that the sidebearings of H are correctly set, then there should never be kerning between HH, so that distance provides a control value for kerning. For each script, the user of the tool should be able to define the control glyphs between which no kerning should be applied and which provide the distance model for kerning in the font.

@John Hudson
I have been having some 'success' using the tool in this way; First i run Typefacet just targetting the side-bearings, tweaking the different parameters untill i get bearings that i 'know' are how side-side bearings should be, e.g. with a sans face, the left side of the 'H' 'B' 'D' 'E' 'F' etc are same(-ish), and all the bowls are same-ish, etc etc. Then i can run that .ufo through Typefacet, to kern only, and setting parameters to ignore certain pairs and/or glyphs. Like you say, by that point i know that e.g. the H-H etc should not be kerned, but i do know that e.g. the L-T will, or that an array of lowercase glyphs will need kerning to the right side of some uppercase glyphs. Of course this sort of routine would be sooo much easier when classes are introduced, and the user can exempt e.g. all glyphs in the 'H-left side' class, or kern only 'T' 'W' 'V' against a 'lowercase left sided bowl' class, i.e. 'c' 'd' 'e' 'o' 'q', or similar. A function that defined glyphs (or just left or right bearings of glyphs), or the space between certain pairs, as 'controls' would be very handy. Good point!

I don't think exempting pairs or classes is sufficient, because all that does is make the algorithm ignore them; what one really wants is for the fact that they are not-kerned to influence the kerning of the pairs that are kerned.

Autokern tools like this one and DTL KernMaster offer parametric controls of the algorithm, but in my experience these are only readily understandable and predictable to the person who created the algorithm: a user has to work by trial and error, not really understanding how varying different parameters affects outcomes. Type designers spacing type don't think in terms of parameters, but of iteratively refining spacing and kerning relative to standard distances established by key shapes. Ergo, it seems to me that a good autokern tool should try to find a way to make such distances a kind of front-end UI to the algorithm parameters.

I don't think exempting pairs or classes is sufficient, because all that does is make the algorithm ignore them; what one really wants is for the fact that they are not-kerned to influence the kerning of the pairs that are kerned.

Yes, i 've been thinking exactly that myself. I had actually wondered if Typefacet was doing something like that; including exempt glyphs in calculations, but then only changing the values of non-exempt glyphs. It would definitely be interesting to see Typefacet able to do something like it. So certain side bearings can be marked by the designer as 'fixed' but are also 'blessed' as the cornerstones from which other relative values are calculated.

I guess I'll just have to accept that installing this on a Linux box without XWindows is beyond my skillz.

What’s the point of this?
What does it add that classes don’t already accomplish?
The examples are certainly not a good testimonial for the product.

However, although I believe that (good quality) kerning is inherently a manual, intuitive operation performed deep within a zone where the designer communes with the spatiality of the typeface, I do think that there are ways in which automated kerning might be integrated into the concept and design process of certain kinds of typeface. For instance Softmachine, in which every glyph is equidistant from its neighbour, at the closest proximity. I did that manually, but it would seem to be the sort of thing that could be automated.

John: ‘[…] a user has to work by trial and error, not really understanding how varying different parameters affects outcomes.’

In KM 2012 the user can see the outcomes of the parameter-settings on the fly.

Nick: ‘[…] kerning is inherently a manual, intuitive operation performed deep within a zone where the designer communes with the spatiality of the typeface […]’

Ah, here we go again: another coarse attempt to mystify the profession of the type designer. Kerning is nothing more than making rhythmical corrections on variants of structures and patterns that were fixed sometime in history. Kerning becomes necessary when type is not completely coherent and consistent, like roman and italic type are by definition. The rhythmical corrections are for the rest purely relative to the (spacing of the) design; this is no hocus pocus or high level stuff, but simply explainable matter. That is why a lecturer can discuss the details of a student’s type design (including the kerning) after he agrees with the design’s basic principles.

And for all the religious people on this forum who (want to) believe that the early punch cutters and casters purely relied on their eyes (like they [want to] believe they do themselves, which they don’t because they are conditioned to look at type as they do), some recent findings of my research are published here.

FEB

Frank: In KM 2012 the user can see the outcomes of the parameter-settings on the fly.

That's exciting news.

Nick Shinn :

'What’s the point of this?'

I think you answered your own question :)

I do think that there are ways in which automated kerning might be integrated into the concept and design process of certain kinds of typeface.

The point of the tool is to provide a way to automate kerning so that it might be integrated into the design process of some typefaces.

The examples are certainly not a good testimonial for the product.

A classic "glass almost empty" statement. I believe the project is only a couple of weeks old. I'd say it's made a pretty interesting start, at least. Horses for courses, acorns & Oak trees etc.

So much technical discussion. I was going to stay out of this, but I find Nick's point spot on.

The examples are certainly not a good testimonial for the product.

At least, for text setting. Display has aficionados for all kinds of kerning...

…another coarse attempt to mystify the profession of the type designer.

You are the one doing the mystifying, hypothesizing a secret knowledge of the ancients.
I’m merely describing how I work, which I figured out by analyzing the different spacing schema that occur in type design and typesetting, rahter than relying on my conditioning.
I have identified at least different strategies for spacing:
- proximity
- stroke regularity
- center of gravity
In any given glyph combination (including more than two glyphs), these principles may contradict, and it’s the purpose of taste and judgement to resolve those conflicts. That’s what design is, and it can’t be reduced to magic formulæ. Even if one starts from a matrix-based premise, one still has to decide which unitary value to assign to the awkward letters such as binocular g and s.

It’s OK to work numerically, but it’s not the best way to exercise taste in matters of spacing.

Let’s keep the humanity in type design, striking a balance with automated tools (such as class kerning), but leaving plenty of room for manual skills and visual sensibility to breathe. The alphabet certainly helps, in the way that its letters resist regimentation, as evidenced by those which don’t comfortably pigeon-hole into kerning classes.

…A classic "glass almost empty" statement.…

I was being polite. Really, I don’t think there is anything at all in the glass, a deficit even, as the examples of modifications are worse than the originals.

The point of the tool is to provide a way to automate kerning so that it might be integrated into the design process of some typefaces.

Not so. It conceives of kerning as polishing that may be applied to any typeface after it has been designed.

I was being polite. Really, I don’t think there is anything at all in the glass, a deficit even, as the examples of modifications are worse than the originals.

Ha ha, well you clearly have standards of skyscraper proportions. So what was the spacing strategy with Softmachine? Now there's a glass overflowing to a flood. Was that 'proximity', 'stroke regularity', 'center of gravity', or a combi job? ;)

Ha ha, well you clearly have standards of skyscraper proportions.

What, you mean good kerning requires standards of "skyscraper proportions"?

Always nice to see examples with all the talk. Anchors for the discussion, otherwise it's just jargon. (Look it up. Esp. the etymology. I've always liked chickadees, you?)

I haven't seen any good examples yet.

Ha ha, well you clearly have standards of skyscraper proportions.

What, you mean good kerning requires standards of "skyscraper proportions"?

I was being sarcastic :) Good kerning obviously requires high standards, skill, and a lot of work. But the high standards some designers preach down to others are often far from the standards they deliver themselves ;p Also, i never see the point of individuals just lamely dissing tools or practices they have no interest in ever using. Experimentation, trying things out, making mistakes, crossing borders, are all valuable exercises (for those who do it, and more so for those who may eventually benefit from it). Conversely, trotting about on some high horse is rarely good exercise. Auto-tools can be very usefull and creative parts of a design process, so new tools and new methods of automation should allways be encouraged and criticised positively. -v

Nick: ‘[…] rather than relying on my conditioning.’

You will always rely on your conditioning, I reckon, because everything we do with type is relative to models which we learned to interpret. As David Kindersley stated in Optical letter spacing (London, 1976 | p.35): ‘It is a commonplace that we see only what we know […]’.

In the nineteenth century the palaeontologist Edward Drinker Cope reconstructed an Elasmosaurus and he erroneously placed the head on the tail (see illustration above). The tail turned out to be shorter than the neck and obviously for Cope this was an unexpected proportional relationship of the two body parts.
        The moral of Cope’s mistake is that the power of the human eye is purely relative to the anatomy of the things perceived. In Art and Illusion (Oxford, 1987 | p.255) Gombrich notes on this phenomenon: ‘The stimulus patterns on the retina are not alone in determining our picture of the visual world. Its messages are modified by what we know about the “real” shape of objects.’

Nick: ‘You are the one doing the mystifying, hypothesizing a secret knowledge of the ancients.’

My measurements of Renaissance type and matrices and actual casting provide so far ample proof for my hypotheses. If you don’t (want to) believe in this scientific method, then you can throw away the majority of books on art history, architecture, paleontology, archeology, et cetera, because most knowledge presented is the result of reconstructions. Also the technical descriptions on the working methods of the early Renaissance punch cutters as described so far, are merely based on nothing more than assumptions and projections of the scarce seventeenth- and eighteenth-century treatises, like Moxon’s and Fournier’s.

Charles: ‘I haven’t seen any good examples yet.’

Shortly I will purchase one of Nick’s fonts, probably Pratt Pro, and I will objectively test whether artifially spacing and kerning generated in a couple of nanoseconds can compete with his manual, intuitive operation, which is performed deep within a zone where the designer communes with the spatiality of the typeface. I will use Kernus/KernMaster for this, and also my own method based on ‘cadence-units’, which I briefly described here. Sometime coming week I will publish the results, if Nick agrees.

Vernon: ‘Auto-tools can be very usefull and creative parts of a design process […]’

I strongly believe that most of the type design process can be automatized/parametrized. If one can describe the matter, it can be programmed –that is, if enough resources are available.

FEB

…i never see the point of individuals just lamely dissing tools or practices they have no interest in ever using.

I wouldn’t say my opposition to auto kerning is lame.
I’ve argued against it many times on Typophile, especially against Adobe’s “optical kerning” in InDesign.
This is a forum and I’m critiquing in a reasoned manner, not merely dissing.
Perhaps the criticism will lead to a better product.
But the only way of telling is by seeing the results.
If someone is going to launch a new product half-cocked, with samples of what it does, rather than focusing on how it works and letting people try it, they must expect criticism based on the samples.

I recall when Apple started out, the typesetting trade dissed the new technology for its poor quality.
Fair enough, and the quality improved.

But not every new thang obsolesces the dinosuars.
Remember Multiple Masters?
The world was not ready for that much parametrics then.

I wouldn’t go so far as to say auto-kerning will never produce as good results as manual kerning.
And I don’t believe that auto-kerning is entirely non-manual, or vice versa.

But TypeFacet is presently wishful thinking.

Frank, thanks for the kind offer.
No need to purchase, I’ll send you the font.
What’s your email address?
Mine: nick “at” shinntype.com

I will objectively test whether artifially spacing and kerning generated in a couple of nanoseconds can compete with his manual, intuitive operation

I’ll go along with the experiment, but I must point out that there is no objective test of kerning.

Nick: ‘[…] I must point out that there is no objective test of kerning.’

It will not come as a surprise when I totally disagree with this statement. Kerning is a refinement of the spacing and the spacing comes forth from / is part of the design.

Every type design has an optimal spacing, which –if the design has been made properly– results in an even stem-interval combined with uniform spaces between and within the letterforms. If the type design was originally made for text purposes, the spacing can be made somewhat more compact for display purposes, but this will hamper the stem-interval a bit (when one looks at Renaissance type, then for instance in Garamont’s Parangon Romain the serifs seem to be longer than in the French Master’s Gros Canon Romain, so the serifs probably were used as wedges [and as indicators for the casters for the setting of the fixed mould-registers], and their lengths were relative to the ‘point size’).

Taking into account that kerning is relative to the design, I expect that the output by Kernus/KernMaster will not differ too much from your ‘manual’ kerning. Of course, there can be some discussion about how tight one kerns combinations like ‘Ty’, and perhaps also about the kerning of some punctuation marks, but I expect that overall the results of both approaches will be quite similar.

At the TypoTechnica 2007 conference in Frankfurt Miguel Sousa and I compared the kerning of Hypatia with the one that was generated on the fly by KernMaster. Miguel was impressed by the fact that the artificial kerning-values came quite close to the ones he generated. (This reminds me of the nice duo-presentation we gave at the ATypI conference in Brighton in 2008, in which we compared the FontLab Studio / AFDKO based workflow at Adobe with the FontMaster based workflow at DTL –but that is another story).

FEB

There is a lot more to spacing than even-stem intervals and uniform white space (which two concepts, it should be noted, often conflict with one other, requiring subjective design judgement to resolve the issue).

I would like to see a comparison of your auto-kerning for two of my “manually kerned” types—Scotch Modern and Richler—the spacing strategies in the design of these types (one 19th century, the other 21st) will, I think, prove resistant to automated improvement. I can send you the fonts, if you accept the challenge.

We've reached the logical positivist argument for kerning. Might be fun in theory, but 'tools' implies use.

I'm with Nick. The test would be interesting.

Nick: ‘There is a lot more to spacing than even-stem intervals and uniform white space [...]

Yes, you are right: I forgot to mention the influence of the inferior conjunction of the moon at a certain moment during the creation of type, the humidity in general and in the working space of the type designer in particular, and the undefinable relation between Voodoo and type design. But for the rest I was spot-on, I reckon.

Nick: ‘I would like to see a comparison of your auto-kerning for two of my “manually kerned” types—Scotch Modern and Richler […]’

Basically I would like to go further than kerning alone additional to your spacing, by also applying auto-spacing on another example. It is in my opinion more interesting to use a ‘translation’ and an ‘expansion’ typeface from your œuvre. The two typefaces you mention are basically from the latter category. Shall we say that we both select one?

Charles: ‘We've reached the logical positivist argument for kerning. Might be fun in theory, but 'tools' implies use.’

I have not the faintest idea what you mean here, but I assume that the nature of this message is positive.

Charles (after an edit): ‘I'm with Nick. The test would be interesting.’

The test was my idea, wasn’t it?

FEB

I forgot to mention the influence of the inferior conjunction of the moon at a certain moment during the creation of type, the humidity in general and in the working space of the type designer in particular, and the undefinable relation between Voodoo and type design.

Also what I had for lunch, whatever meds I might be taking, and last month’s font sales.

The two typefaces you mention are basically from the latter category.

They do both have vertical stress, but their spacing strategies are quite different, which is why I thought they’d both be interesting to compare with automated kerning.

Scotch Modern
Richler
Goodchild

For a “translation” face, might I recommend my Jenson (Goodchild)?
There are other Jensons to compare it with (and even perhaps Goudy’s Italian Oldstyle), which might be revealing.
Bitstream’s DeVinne would be good to compare with Scotch Modern, on account of the former’s interesting deployment of negative sidebearings on /v etc.

DTL's KernMaster does seem extraordinarily good at calculating kerning values. Everyone should should have a look at it. Impressive.

ps . I would pay good money to see a live 'kern off' between Nick (on meds or not) and KernMaster.

Vernon: ‘I would pay good money to see a live 'kern off' between Nick (on meds or not) and KernMaster.’

Unless Nick is family of The Flash and shares some dna with this superhero, my bet is that KernMaster is faster.

FEB

Kern Tennis! ;-)

FEB:

I strongly believe that most of the type design process can be automatized/parametrized. If one can describe the matter, it can be programmed –that is, if enough resources are available.

Well, i've found Typefacet pretty handy this week, using it as a quick way to space the ufo files of a new face, 'on the fly', as i work on them in Robofont & Prepolator; tweak, shape, autospace, look .... tweak & shape more, autospace again... etc. Ok so it's probably a forgiving face for an autospacer, but i have been impressed by the spacing Typefacet gives (see below).

I can throw a whole ufo at Typefacet and it will return workable spacing across all glyphs (unlike the autospacers in fontog, fontlab or fontforge). Also, equally balanced glyphs (e.g. 'o', 'A', 'H', 'M', etc) get equally balanced side bearings, and unequally balanced glyphs get the 'correct' ratio of side bearing values. Other autospacers aren't allways that sensible. It's not the final spacing, and i will manually adjust some values, but it's doing a pretty good job, and the optical values of 'the usual' kerning pairs look ready for kerning later (auto and/or manual). I would say it's saving me lots of time and compensating for my usually not so great attention span for spacing ;)

Anybody here had a look at the work of the author of Crimson Text and his approach to find kerning values automatically?

http://aldusleaf.org/rhea.php

I had a look at it, but briefly, because I quit immediately I came across the philosophical proposition that the technocrats are wont to argue: …that’s all the brain is: a machine.

There are many arguments against this, but the one I will mention here is that, from an historiographical perspective, culture can be seen to evolve as a progressive dialectic between the tendencies of art and science, with whatever the one creates being questioned by the other.

Art says: OK, science, technology and capitalism, you’ve standardized and commodified That, but we decline to use your tools as you intended—so suck on This!
And Science says: Shape up, you wayward Mess of biology and culture; we are on the threshold of discovering your hidden mechanism and Making It Work.

And so it goes, so it goes, so it goes, and where it’s going no one knows.

Wasn't it D.E. Knuth that said: "Science is everything we understand well enough to put into a computer"?

I actually know Don Knuth. There is room in his life for a lot of things.

Instead, try Rudolph Carnap. Everything is, in principle, physics.

“Science is anything you can get away with”.

{To Follow}

I've have released my little spacing macro
http://www.impallari.com/projects/overview/spacing-macro

15' Screencast:
https://vimeo.com/45648496

Play around, and let me know how it can be improved.
And maybe some of this can be integrated into TypeFacet Autokern (for example, the way you tweak and play the macro each time to get quick visual feedback).

Pablo, good stuff.

Would it make sense to make the sans/serif variable something more sophisticated than just zero or one?

BTW the best feature is of course the baby sounds! Let me guess: 2 months?

hhp

Thanks hrant,

> Would it make sense to make the sans/serif variable
> something more sophisticated than just zero or one?
Like what? example?

> BTW the best feature is of course the baby sounds!
> Let me guess: 2 months?
Ja ja ja.. That's Sofía. 1 month and 4 days.

Wow, she's so mature! ;-)

I think at the very least you'll need an intermediate value for flare serifs, and maybe a higher-than-normal value for slab serifs. But I don't know how your code is written to use that variable.

hhp

For slabs you can use "serif" settings, and for flare serifs you can use "sans" settings, and play with the "global adjust" value.

I seem to have this installed (Python is the new DLL Hell), but I can't get it to recognize that tfs is part of its distro. Anybody else have this problem?