Do we need kerning against the space character?

[Tim Ahrens]

So far, Kern On does not do any kerning against the space character. I know that some people do that, however. So, the question is:

Do you want KO to support/generate kerning against the space?

If so, what is the reasoning behind it? What is the (visual/geometrical) reason for it? What are the principles that guide you if you do it manually?

Looking forward to your answers!

[Jeremy]

I do look at this, but am aware of combinations such as 'W W' or 'f W'.
Sometimes I have swapped out the space with a space.wide, or space.narrow etc.

I tend to review as a basic in consideration of standards and the whole type. Any kerns are small though.

/H/H/H/space/H/H/H/space/O/O/O/space/O/O/O/H/H/O/O/H/H/period/space/H/H/H/period/space/O/O/O/period/space/H/H/period/space/A/H/period/space/J/H/period/space/M/H/period/space/S/H/period/space/T/H/period/space/U/H/period/space/V/H/period/space/W/H/period/space/X/H/period/space/Y/H/period/space/Z/H/H/H/O/O/H/H/comma/space/H/H/H/comma/space/O/O/O/comma/space/H/H/comma/space/A/H/comma/space/J/H/comma/space/M/H/comma/space/S/H/comma/space/T/H/comma/space/U/H/comma/space/V/H/comma/space/W/H/comma/space/X/H/comma/space/Y/H/comma/space/Z/H/n/n/n/space/n/n/n/space/o/o/o/space/o/o/o/n/n/o/o/n/n/period/space/n/n/n/period/space/o/o/o/period/space/n/n/period/space/a/n/period/space/f/n/period/space/j/n/period/space/s/n/period/space/t/n/period/space/u/n/period/space/v/n/period/space/w/n/period/space/x/n/period/space/y/n/period/space/z/n/n/n/o/o/n/n/comma/space/n/n/n/comma/space/o/o/o/comma/space/n/n/comma/space/a/n/comma/space/f/n/comma/space/j/n/comma/space/s/n/comma/space/t/n/comma/space/u/n/comma/space/v/n/comma/space/w/n/comma/space/x/n/comma/space/y/n/comma/space/z/n

If you add it to Kern On I would possibly have it as an option unless a string of 3 can be considered – i.e. the glyph before the space – '. W' is a larger hole than 'f W' or 'W W'

[Tim Ahrens]

Thanks for sharing this!

So, it seems that here, the main reasoning for any kerning against space is triplets? I had this feeling, too, that we don’t need kerning against the space character out of purely pair-based reasons.

Your trick to simply use a contextual space.wide or space.narrow is really good! I had never thought about that. Much easier to implement than triplets, it can easily be controlled in an MM environment, and probably also requires much less data to go into the font.

[Eben Sorkin]

I like to have kerns to space for text faces because it allows me to get a more even grey in a paragraph than I could otherwise get. I aim to make the space itself appear more constant in brightness. In a really large optical size display face I might also want to because all the spacing becomes more sensitive. Space wide and space narrow seem like a great way to get some of this impact without the kerning data overhead. But I really would want to option to automate this with examples if possible.

[Tim Ahrens]

Thanks for your contribution, Eben!
Do you use positive or negative kerning against the space, and for which characters?

[Eben Sorkin]

The letters where the word space tends to look brighter/bigger than a default those with big open white spaces. H H no and vs T T yes. The Latin glyphs that I sometimes like to kern with space in caps are : A T V W Y X both sides; Right side L C F P K G; Left side J. The suitability of the gyph to kerning with a word space is very dependant on the design. In lower case the values are smaller because the white space is less but I do also sometimes do right side: c f k t; both sides v w x y. Numbers can also benefit from this treatment. Again depending a lot of the design but these might include: 2 3 4 5 7. Symbols like The UK pound sterling are sometimes quite bright on the right side. The various dashes can feel a bit loose set next to a space. I like to make sure that the nonbreaking space and other spaces that are are part of the word space kerning group numberspace, emspace and enspace for example.

[Tim Ahrens]

It seems we need to distinguish different cases of kerning that involves the space character:

1. Pairs with space that need negative kerning, as the sidebearings of the glyph are always chosen with neigbouring glyphs in mind, which means the “close zone” has to be over-represented. For example, thinking of a typical sans, the sidebearings of the V are not chosen so that the average distance (i.e. at half the cap height) is the same as the H, but looser, as the close zone at the top is not fully compensated by the loose zone at the bottom. Against the space, however, perception works more in terms of average distance or white area, so we need this correction by positive kerning. Examples: [ V] and [F ].
2. Pairs with space that need positive kerning. Possibly after the f, which is is a unique case in that it is usually spaced specifically to work against LC without ascenders and it is “too tight” from an abstract, i.e. average distance or white area point of view. Example: [f ].
3. Triplets (with space in the middle) that need to be tightened, as the same principles as normal kerning seem to apply across the space (but maybe weaker?). Examples: [L T] and [. W].
4. Triplets (with space in the middle) that need to be widened as they would be too tight otherwise. Examples: [W W] and [f W].

[Tim Ahrens]

3. Should be the easiest to implement: Just take all kerning pairs, “insert” a space in the middle, possibly apply a taming factor < 1, and export as triplets. Maybe I will try this as an experiment. From a typographic (semantic?) point of view, this may not be as crucial as normal kerning, as the space is meant to separate things from each other, but the increased visual consistency might be beneficial.

[bech]

I just want to add my name to the list, and echo what Eben said.
I spent some time today trying to figure out how this is done in KO before finding this :)
Is the work-around now to hit »Kern On« and then do this manually before exporting?
Thanks!

[Tim Ahrens]

Which type of kerning against the space do you want to add to the font (see my list above)? I would advise to add the kerning as independent pairs within Kern On, which allows you to re-run KO if you spot pairs that need a different value.

[bech]

I tried doing that, but it gave me problems so I thought that wasn't the way forward.
There were discrepancies between the main letter (A) and the other in the same group (ÁĂǍÂÄÀĀĄÅǺÃÆ), like missing kerning on one side, and open locks, closed locks.

In the attached example /A/ has the kerning but one of the locks are left open. This results in /Aacute/ on the right not getting the kerning.

Or am I missing something? Thank you!

Edit: I forgot to answer your question. Usually it's 1 and 3, that I think needs to be sorted in some typefaces.

[Tim Ahrens]

Independent pairs are always glyph-glyph pairs. Kern On will not transfer them to other pairs. You would need to set all necessary glyph-glyph pairs as independent pairs (I know that’s not convenient, just a work-around for now).

[bech]

OK gotcha, but is it odd then that Aacute got the -4 kerning on the right from KO?
I will try your workaround for now.

[bech]

Tim, I tried your workaround and made independent pairs for the usual suspects (L, T, F etc.) and /space/ (and the same on the right of /space/ too, of course), but is there a reason why I now get kerning on other letters too? The pairs should be ‘independent’, right? And /space/ is set to ‘No kerning’.
Attached screenshots of E-space before and after applying KO.

BTW, I even got a -114 kerning on /space/ and “straight-sided” letters (H, N etc.) before, but putting an independent pair on space-H solved that. Should an independent pair fix that though? Sorry, I’m a bit confused.

[Tim Ahrens]

Thanks for pointing this out.

After seeing this, I realize the handling of independent pairs that include “No kerning” glyphs – when the class kerning is generated – should be refined.

Right now, the reasoning is: Ensure all independent pairs are preserved exactly as they are set, while all pairs that are “not in the system”, i.e. don’t have any of the model/auto/ind segments activated, are ignored and may get any random value. This is ignoring the user’s statement of “No kerning” and that‘s not good.

I’ll fix that, and hopefully add some support for kerning against the space as well.

[bech]

Glad to help. I agree that this part doesn't really make sense right now. But overall, KO seems awesome so far! Your products are the best thing since.. Glyphs.

[SCarewe]

Hello, I have a client that specifically is requesting kerning against the space (and I would generally agree that kerning against the space is a good idea, for cases like /o T/)
Adding independents for all space-glyph and glyph-space pairs is possible, but somewhat defeats the purpose of Kern On (especially as, in this case, I am working with a 24-master font where no master can be interpolated). An option in Kern On to transfer kerning from pairs like oT to o T (with, as you proposed, a taming value) would be phenomenally useful. Does this seem viable? Thank you very much, as always!

[Tim Ahrens]

Seems that would be #3 from my list above?

I should definitely tackle that but adding support for kerning triplets isn’t trivial. Kern On needs to write feature code, which is not too difficult, but it has to do so for each instance/export individually, as “manual” kerning code is not interpolated by Glyphs. So, KO needs to interpolate the triplet kerning values for each export. Still, no big deal. But what if the user adds or modifies exports? Plus, it has to take these triplets into account when handling the given kerning data size. Oh, and, of course while we are generating instance-specific kerning anyway there is the potential to generate more correct kerning for the intermediate exports (the ideal value for [To] in Regular is not necessarily the interpolation of [To] in Light and [To] in Bold). Phew, lots of work ahead!

[SCarewe]

Yes, I realise all those steps are a rather daunting thing to tackle with Kern On... If, somehow on the horizon, it was possible, that would be wonderful, of course.

My current "solution" was to write a quick script that copied the kerning values for /u against [T, V, W Y] (and their derivatives) generated by Kern On to /space against those glyphs. It also adds them as individual pairs in Kern On, but in the end, it doesn't really matter, I just run it quickly after running Kern On.

Thanks a lot, as always, looking forward to the development on this.

[Eben Sorkin]

I am excited about the possibility of getting the wordspace! I would be happy initially to be without triplets especially if that is something that might delay progress for pairs with the word space.

[jeremy@tribby.com]

Just wanted to chime in with a +1 to this being a desirable feature

Pairs like /space/T are where I find myself wanting it the most

[Eben Sorkin]

I wonder if, as a stop-gap measure, it would be possible to assign the value of another glyph to the word space. I was thinking about the period, for example. This isn't really ideal because letters that extend low, such as 'A' would not benefit. So 'A A' wouldn't get kerned.

I wonder if Kern-on kerns to the underscore. Maybe that would be more suitable stand in if it did?

If the model kern-on uses is modular enough I wonder if you could take the base of T ( open on the bottom ) the top of A ( Open on top). The problem might be a lack of suitable open middles. And also not all A shapes are triangular!

Tim, what's your current thinking about this?

[stephennixon]

Just echoing this as a desired feature. I know that not all good type designers do this, out of caution in not wanting spaces to close up by too much in string like "BOW WOW" or "HAT TAT" or "BOW TAT," etc. However, it is desirable to use kerning to give wordspaces a more even appearance, as phrases like "BOW HAT" often appear too distant compared to "BAH HAT," etc.

So, I think that basically aligns to your strategy #3 above. But yes, just to say it clearly: the end goal, I think, is to make all wordspaces appear equal in size/distance.

[skyrailhighline]

I do negative kerning against the space for *pair* groups such as:

/period/space
/quote/space
/guillemet*/space
/hyphen/space
/question/space

Including any related glyphs and reverse for the symmetrical glyphs. Sometimes I also do it for superior numerals. I also do it for any letters that have open spaces such as L J V W A Y T f etc

[SCarewe]

Hello again, once more I am needing to kern the space. My current solution is to simply set space – [C, T, U, V, Y] as an independent pair and then run Kern On. Problem is: Every time I re-run Kern On, I need to remove the kerning exception and turn it into class kerning, so that ĆČÇ... are also kerned accordingly. The Independent Pairs logic probably needs a bit more of a general overhaul in order to make this work properly from a UI point of view, but some way of keeping all this kerning as class kerning would be great.

At least the option of setting and independent pair as independent for all class members. Does that sound feasible?

[Jeremy Tribby]

Would it be helpful to have specific examples of this as OpenType feature code (and/or Glyphs specific format for VF), so that a suitable UI could be worked out from there?

[Tim Ahrens]

Would it be helpful to have specific examples of this as OpenType feature code (and/or Glyphs specific format for VF), so that a suitable UI could be worked out from there?

Yes, that would be great!

[Jeremy Tribby]

great - I will send you an email in the next few days!

[Eben Sorkin]

Just posting to say I am still hopeful that this will happen.

[Eben Sorkin]

Tim: any news?

[Tim Ahrens]

Sorry, no news. It is definitely on my list of future improvements, though!

[Eben Sorkin]

I think that the ideal solution may be in a calt feature rather than Kern-On

Technically idea is to adopt the model used for example altering a glyph in context to correct case on the fly, and altering a wordspace for a shift in the script being used; and adapting it to this workspace problem we have discussed.

CALT feature:

lookup capSharpS {
sub @Uppercase @Uppercase germandbls' by Germandbls;
sub germandbls' @Uppercase by Germandbls;
} capSharpS;

lookup ethiopicSpace {
sub @Ethiopic space' by space_eth;
sub space' @Ethiopic by space_eth;
} ethiopicSpace;

lookup Latinwordspace {
sub @openL space' @openR by space_sm2;
sub @openL space' by space_sm1;
sub space' @openR by space_sm1;
sub @openL nbspace' @openR by nbspace_sm2;
sub @openL space' by nbspace_sm1;
sub space' @openR by nbspace_sm1;
} Latinwordspace;

Class (@) features:

openL
c f r t v w y A C F P T V W Y seven question guillemetleft guillemetright guilsinglleft guilsinglright hyphen endash emdash

openR
v w y A T V W Y seven question guillemetleft guillemetright guilsinglleft guilsinglright hyphen endash emdash

This proposed implementation I am showing incomple to keep it very simple to understand. It is excessively simple in two ways: 1) It doesn't account for all the 'A' based letters ( or other diacritic-using letters ) or even all the open shaped glyphs. 2) It also only breaks the word space into just two versions! You might find that optically you want more than two widths. Perhaps one for large gaps in capitals and another for lower case whose gaps are smaller. Maybe your design has a big range of gaps to address and the T and A can't share a class and new word space.

Of course, the more complex the classes are the more complex the combination of classes will be on the number of word spaces you want.

I'm curious about what you all will think about this.

[Eben Sorkin]

Maybe obvious but... the non-breaking space needs to follow the pattern of the word space which is why the code repeats for 'nbspace'.