Release plans for DINish 4

[driehuis]

Sometimes I think that, in retrospect, drawing DINish from scratch would have been less work than starting out with D-DIN. Oh, the folly of youth! I would have had to learn all lessons the hard way and have given up before finishing one weight and width of DINish.

Over time I have been cleaning up inconsistencies between the font families, to the point that we can now interpolate cleanly between DINish-Regular and -Bold on the weight axis, and between DINishCondensed and DINish on the width axis. DINishExpanded is still to be done... The good news is, it results in a palatable 300 weight, and a usable 800 weight, for both widths. With 500 and 600 also looking the part this would vastly improve the usability of DINish, both on the web and in print.

Unfortunately, this exercise has also exposed the weak underbelly of the historical base. Kerning between the family members is inconsistent. The Bold is on the heavy side. Sometimes it even looks as if the Bold was drawn using different tools than the Regular! Anchors are missing and worse, inconsistent. On top of that, there's the occasional mistake, including a bunch I made early on. Removing details that you won't see even if you print the individual letters at A4 size won't hurt... until you realize that, when used as a coherent family, the letter shapes of interpolated glyphs lose their character. Some verticals become slightly bent at intermediate widths as a result, and "slightly bent" is not a phrase you want to apply to a font inspired by a Deutsche Industrie Norm. I could not find a cleanup tool that produced acceptable results, so manual touch-ups were the way to go...

Coming from a software development background, I see DINish as both a code base and a cantankerous child. For both, simplification and tough love seem to be appropriate measures. Inconsistent kerning will be solved by promoting the DINish-Regular kerning to all family members. When needed, the others will get their side bearings trimmed to match. There's no way to salvage the existing kerning. The Italic will go as a separately maintained entity. The BoldItalic already was generated from the Bold, and regular Italic will be generated too. The Regular and the Bold will meet up in shape, shedding some lovely detail, like dollar and dollar cent losing the through-vertical in the Regular, instead using just top and bottom stubs, like the Bold already had. Maybe, just maybe, I'll introduce some OpenType magic to reintroduce it later, but for now Thoreau's "simplify, simplify" will win out.

The build process will also see major updates.

Things that won't change include:

• DINishCondensed, DINish(Mittelschrift) and DINishExpanded will still be maintained separately. There is no way you'll capture the Mittelschrift by mere interpolation without throwing a lot of detail overboard. The three widths each have a distinct feel and will keep that.
• The 400 weight will always be maintained. A 100 hairline will be derived eventually from an interpolation, but will require a ton of touch-ups, and it is unlikely a mere interpolation between hairline and bold will look as appealing as the current 400.

I'm not sure about the Bold. It may well turn out to be that a touched up Black will eventually replace the current 700 as the master, or just supplement it. Time will tell. I'm not looking forward to maintaining four weights of each width...

Having touched almost all the glyphs, and with so many changes under the hood, I will release a 3.9xx preview series of DINish so people can test the new font before it lands officially. In particular, it will include a variable font. I do not personally have a need for variable fonts, so it has not received a ton of TLC. It lacks both Expanded and Italic for the time being. That said, please share your feedback here!

So, here's the road map. I won't make any promises about what will happen when (or even at all). I work on DINish to let off steam, so progress will always be unpredictable.

• Instances of DINishCondensed and DINish with all weights between Light and Heavy (no Hairline, ExtraLight or Black initially).
• A Variable Font with the same range.
• DINishExpanded to be given the same treatment.
• A Hairline and a Black could be added eventually.
• Variable Font improvements.
• Greek may happen at some stage.
• Anchors may get some TLC.

At showtime for the release of Light, Medium, SemiBold and Heavy, the version will be bumped to 4.001 to reflect the massive changes under the hood. The rest of the road map will not require any structural changes, and will minimise rendering differences with 4.001.

[kenmcd]

I will release a 3.9xx preview series of DINish so people can test the new font before it lands officially. In particular, it will include a variable font. I do not personally have a need for variable fonts, so it has not received a ton of TLC. It lacks both Expanded and Italic for the time being. That said, please share your feedback here!

Interesting.
About three weeks ago (2024-07-28) I downloaded the new sources and made a variable font from them.
Just tested with the six Roman fonts with the three widths.
Combined the six UFOs into one VF font.
Thought maybe I would contribute the compatible UFOs.
Too keep the shapes I was adding nodes to make them match, not simplifying.
Only got to the M and realized I was making a lot of changes.
And that I should really talk with you before doing a lot more work.

The matching tools in FontLab are pretty sophisticated and may be helpful here.
"Simplify" seems to change the shapes too much during the interpolation.
So I found myself matching segments to add the needed missing nodes.
Went fairly quickly.
Perhaps I can help with the 3.9xx WIP after you post those, and sources.
I do not know what tools you are using, but perhaps FL can help do some things more easily.

I do not know if you have taken a look at Bahnschrift, but it definitely has a lot of additional nodes to maintain the shapes better during the interpolation.
Gotham is similar with some strategically placed nodes.
Both may have some ideas useful for DINish.

[driehuis]

Oh, wow!

The WIP source code is on the normalise branch in Github, you can download it from there.

I've got a license for FontLab, but I'm not a Windows user myself so I'm not fully up-to-speed with it (accessing it through Remote Desktop on a VM isn't optimal either). I've got the same experience with its Simplify tool as you have, and looked around in vain for better options. Would you happen to know of a tutorial or description of some sorts for matching glyphs with FontLab? I went back to TruFont as my main driver because it's lightweight and easy to use even on the laptop, but I'm not gung ho about any tooling.

I'm still working on the branch because of the huge amount of changes. Making all contours start at the bottom left node alone caused the diff to be larger than the font itself. I'm keeping the in-between revisions while work on it continues, so I can revisit individual changes, but I plan on collapsing a lot of that history when it gets merged into the main branch.

For Stefan's work on Cyrillic I just imported the individual .glif's and normalized them with the tooling in the repo. I can easily do that for your work.

My regular work flow is to edit the glyphs with TruFont, and use psfnormalize and some custom software to normalise them. For the v3.0xx version all of that code is in the repo. I'm actually reviewing the diffs of all changes to .glif, even though that is no longer with the pinpoint accuracy I started out with due to the volume of changes. Still, I regularly catch issues just browsing the diff.

The code changes for the tooling are too ugly to show to the world just yet. I plan on using Docker for the build process to make it more accessible.

Could make your WIP available somehow, so I can have a look-see? I'm curious to see how your approach differs from mine.

I did all the glyphs for Condensed and Mittelschrift, so unfortunately we followed the worst possible mismatched approach. Having done these two, doing the Expanded should not be not hard because I (maybe optimistically) believe that the hard work is done and the rest is more of the same, with relatively little brainpower required.

I'm trying to avoid looking at closed-source fonts, not just because of concerns over legal issues, but also because I often find that when I look at how font X deals with an issue FontBakery identified, the commercial font also fails the test. I tried out Bahnschrift in Word to see how it dealt with the soft dotted ij issue, and found it didn't... My favorite sources of inspiration are IBM Plex and Inria, FWIW.

[driehuis]

It actually wasn't hard to do Expanded, with the recent work on matching Regular and Condensed still in muscle memory.

I just dropped a preview build that includes all three widths, including the variable font. Still no hairline or black, but the 300-800 weight range makes DINish way more usable for Real Work.

One regression got fixed: in intermediate weights, the lowercase "i" would see the dot and the stem of the "i" merge because of inconsistencies in the order of the contours. There must be more of this mayhem lurking, so do test and report issues here!

[kenmcd]

Ahh... I spent a few hours on it yesterday.
Also was adding the expanded and matching.
So I will stop that and take a look at the new version.

One regression got fixed: in intermediate weights, the lowercase "i" would see the dot and the stem of the "i" merge because of inconsistencies in the order of the contours. There must be more of this mayhem lurking, so do test and report issues here!

Yes. I also found a few element order issues.
A couple of the number 8 figures.
And a Cyrillic character that looks like a small B.
On my phone at the moment, but I can get the exact info tomorrow.

[driehuis]

Hmmm, I touched all of these for the 3.901 preview, but I can't recall if that was for outline ordering issues.

I should probably find (or write...) a tool that checks if outlines and components are ordered regularly.

[driehuis]

My cunning plan was foiled: I wasn't aware that in a VF, there is no way to apply separate in-between masters. You can moderate the rate-of-change, but it is identical for all glyphs. This means that if I add Hairline and Black, all of the glyphs at the 400 weight will have an exact mathematical relationship with both Hairline and Black and there is no way to tune this. That sort of sucks. I'd have to see just how bad the issue is in practice.

One of the things that I ran in to is that fractions (anything that uses dnom and numr) will have extremely small counters in Black. My plan for resolving that was to just reuse the glyphs for dnom and numr from Heavy in Black. That would be a tradeoff for Black, but one that I can defend. But once Hairline and Black become the models for the VF, that means that in Regular and Bold the counters of dnom and numr would open up, and I was pretty happy with the balance they had as static fonts. Maybe my concern is overblown; experimentation will tell. But maybe I'll stick with the 300-800 weight range for the VF and for the other weights release a set of statics, with the manual tuning of 100, 200 and 900 that I currently think would be best. Time will tell. I now understand better why some of my favorite font families have limited weight range, even if they also have a VF.

I've had a fight with the designspace and more VF stuff I wasn't aware of, but I've got a VF with Slant, Width and Weight axes ready to roll, with the OpenType magic for the single story "a" in the Italic, almost ready to roll. Every time I'm trying to spin a pre-release I seem to notice a regression...

I gave up on an Italic axis for now. The Slant feature does the right thing for Italic, so there's no typographical richness lost, and the rules for Italic VF's feel quant. Anyway, tags before v3.908 will not see the light of day due to snags.

The woff2 for the VF weighs in at under 100kB, yay!