Python script to harmonise stems?

John Hudson's picture

It seems to me that this is something that is likely to already to exist, so before I ask someone to write it for me, I thought I would enquire if anyone already has it...

I'm working on a font that contains a large number of glyphs with very slightly different stem weights, e.g. straight vertical stems whose widths vary from 259 to 264 units. I want to harmonise these stems so that they are all the same width, so what I'm looking for is a script that will take an input stem width and convert it to an output stem width. Obviously, the script should distinguish vertical and horizontal stems. This is similar to some of the functionality of KLTF Glyph Tweaker, except I'm looking for something that will find the glyphs which need to be adjusted as well as performing the adjustment.

dberlow's picture

Looking for a perfect auto hinter with a built in auto instructor that responds intelligently to control value table cut in values and outputs a scaled outline? No problem.

Chris Dean's picture

Is there a budget associated with this job?

Chris Dean's picture

I have a colleague in the lab who may be able to solve this problem.

John Hudson's picture

Acutally, no, I wasn't looking for a perfect autohinter etc., David, although I can see how what I'm looking for would form part of such a thing. I just want to be able to regularise some variant stem widths that are a unit or two off being standard without having to go look for them and do it manually.

Thanks, Chris. I want to check first to see if anyone has already made such a thing. If not, I'll likely hire Karsten to produce one: he does most of my Python scripting, and I reckon he has already solved most of the problem in his Glyph Tweaker tool.

dberlow's picture

JH> I just want to...

I know. You just want mista computo to know where all the glyphs are, then where all the stems are in those glyphs, calculate the differences, decide on the norm, and then know which way to move what points to make them all the norm, for any font in the known universe, without you ever lifting a witto finga.:)

John Hudson's picture

Adobe's PS autohinter already does a decent job of identifying stems and recording their width, quite good enough for this purpose. So let's say that the PS autohinter has been run, and the hints are present in the FL glyphs. All I want to be able to do is say take any stem that is e.g. 262 units wide and make it 261 units wide by shifting some points. Okay, so a decision needs to be made about whether to shift them up or down, left or right. I reckon the safest bet will be to shift them from the centre of the glyph outwards, i.e. increasing the size of counters while preserving sidebearings and vertical alignnment zones.

twardoch's picture

Are there serifs? Are the stems perfectly straight segments, or is here any curvy stuff involved?

I have use for such a tool myself, so I might write it.

John Hudson's picture

For my immediate needs -- now met, I think --, the stems at issue are mostly straight and mostly vertical (primary stems in some North Indian scripts). No serifs.

I can imagine how much more complicated it would get if one needed to deal with serifs or other terminal appendages, and things like S curvatures.

Which led me today to another thought...

On the Web and some other publishing platforms, we now have a fairly cleanly defined distinction between content and display, between tagged text and information about how to display that text. [Yes, a lot of people still muddy the distinction in practice, but the point is that it is possible to do it cleanly if one is willing to think systematically and take advantage of the distinction.]

So today I started thinking about a parametric approach to making glyphs -- and could be extended to hinting glyphs, come to think of it -- that would mirror the XML/CSS approach to text creation. The 'content' of such a system would be sub-glyph elements -- stems, bowls, serifs, counters, etc. -- which could be tagged according to type and function, e.g. 'main-vertical', 'diagonal-hairline' etc.; like XML tagging of text, it would be extensible, so the exact set of tags needed would correspond to the nature of the design intent, i.e. what the designer would express in terms of the content tags would be the meaningful distinctions to be differentially handled in the display. The 'display' is the parametric rules applied to the content, e.g. the stuff that says how thick and how long a 'main-vertical' stem should be, where it starts and terminates, how it interacts with adjoining bowls and their own display parameters, etc. Then the actual glyph creation would be performed by the equivalent of a CSS parser, a program that knows how to interpret and apply the display parameters to the tagged content. If all parts of the system are open source, then the parser can be updated to understand new parametric rules.

Does this all make sense?

k.l.'s picture

It does. This seems where more recent developments in CJK formats/tools are heading. They go a step farther, leaving the conception of outline plus hinting behind (it is really time to forget about soft fabric plus shoulder pads underneath) and turn to a conception of shape-defining framework plus muscles (think of a more recent Illustrator drawing tool). Not even such new conception, btw. In the latter case, both framework and muscles could be classified/named for the sake of changing of parameters globally. And indeed it were nice if this were not just a production but an end format so that no conversion is necessary. The sfnt structure of OpenType makes it easy to plug whatever alternative table(s) for outline description into a font.

dberlow's picture

>And indeed it were nice if this were not just a production but an end format so that no conversion is necessary.

Yes indeed! With the skeleton, muscles, compass and brains of TT, and a label, which is already done, no need to convert anything or make your own interpreter, besides freetype. The biggest barrier to all this working simply, efficiently and losslessly is that the geniuses at FL will not make the 1/2 hour change to the tool so TT outlines can be edited on an equal basis with T1. Unfathomable ba-lindness to the future and going on 5 years old ;)

k.l.'s picture

Sure. For you and me, here and now, better TT-outline editing too. In FLS 5.0.5 please. :)

eliason's picture

Adobe's PS autohinter already does a decent job of identifying stems and recording their width, quite good enough for this purpose... All I want to be able to do is say take any stem that is e.g. 262 units wide and make it 261 units wide by shifting some points.

I've always presumed that's what ticking "Allow changes to glyph outline" in the Adobe autohinter settings would do (though I've never been brave enough to tick it). What does it do?

blank's picture

IIRC allowing the autohinter to change the outlines allows it to make little changes along horizontal curves for the sake of flex hinting. In my experience all it ever did was turn curve points into matching non-curve points.

Theunis de Jong's picture

"Allow changes to glyph outline" changes the text in dialogs to derogatory comments.

Auto-hint: "Here's a hint. Don't give up your daytime job."
Simplify: "What do you expect me to do, make it a single point?"
Zoom: "Can't you just sit closer to your screen?"
Skew: "Yet another nitwit perpetuating the myth 'slant' is the same as hand drawing an italicized font."
Save: "Too lazy to re-do your work next time 'round, eh?"
Print: "Go ahead, destroy the environment and kill another tree."
Quit: "Good riddance."

Option inserted at the request of David Berlow :-)

[Edit] Oh I was only joking!

Té Rowan's picture

Load: "Do you want fries with that?" (That's the 200 message on my private web server, btw.)

Santiago Orozco's picture

Or use an intern.

blank's picture

I’m not sure there are many type design interns on John’s island.

John Hudson's picture

And I have no desire to be anyone's boss.

Syndicate content Syndicate content