Is this project open for development?

[StefanPeev]

Some days ago I saw the project Altinn DIN. I checked the styles of Altinn DIN font and find that the Regular and Bold versions was worked separately - without the idea for future interpolations between them or option to created variable font. I solved this problem and the result is like this:

https://github.com/playbeing/dinish/assets/12949369/d549a81f-75a1-4d0e-88d8-b4d066f7f34f

Probably the project Altinn DIN is frozen because I have no answer to make question. I'll be glad to participate in development of a project like Altinn DIN fonts, it is why I would like to ask you do you plan to add more scripts to your project and would you like some suggestions and help from my side.

[driehuis]

Dear Stefan,

The original source font, D-DIN, was not designed with variable fonts in mind. I've seen earlier attempts at turning it into one, or automatically generating hairline and black weights, and was not impressed by the results, so I did not pursue this option. The font in your video looks very good, so congratulations on that result, I'm very impressed!

DINish was set up from the outset as a true Open Source font, so yes, we're definitely open to contributions! Could you share a little more about the process, like the tools used, and perhaps show the generated font somewhere?

[StefanPeev]

Dear Bert,

Thank you for your prompt answer. I use FontLab 8, FontForge, Trufont, Inkscape (and very rarely Illustrator) in my work on the font's projects. The video above shows the transformation from Thin to Black version in Altinn DIN (it is a function by default in FontLab 8) but actually the masters in my project are only Regular and Bold. So if we want automatic interpolations they must be only between Regular and Bold Altinn DIN. Everything outside these 2 masters needs further corrections. You can see the OTF and UFO versions with my changes in Altinn DIN from the files in the ZIP archive. Please, have in mind that I cleared a lot of points which I think that they are of no value for the Bezier curves and thus I made the contours more simple. Please, keep in mind that UFO files are not normalized (I do not applied to them UFO normalizer command).

AltinnDIN.zip

[driehuis]

I see you are also started adding Cyrillic characters, excellent! That is high on my wishlist as well!

Have you looked into the differences between Altinn DIN and DINish? The glyph count in DINish is roughly double that in Altinn DIN. DINish now supports over 250 languages that use the Latin character set. A lot of glyph contours have been cleaned up as well (though a lot probably still needs to happen to make a variable font work). As much as possible, all glyphs are named using the Adobe names. In short, you may wish to rebase off of DINish. :-)

As it happens, I recently purchased a Fontlab 8 license as well, though not being a Windows user myself I haven't worked out yet how to best use it. I haven't even tried opening DINish in it yet!

As you noticed, there are many details in the book weight that do not scale down to the hairline weight nicely, but I think three master weights (hairline, book and bold) would be enough; the black weight doesn't look distorted in the video. Of course, the devil is in the details. Cleaning up the hairline doesn't appear to be overly hard so that looks like a doable endeavor.

Do also give the tooling around DINish a look. It's using a Makefile not just to build it, but also for typical developer tasks such as make revert_auto_changes to wipe out generated files, make psfnormalize to normalise the glif files, and make fontbakery to run the Google font quality tools.

I am concerned about the required simplifications though. There was some low hanging fruit in D-DIN, but I did not get acceptable results leaving cleanup to automation (haven't tried Fontlab yet). But as long a a human has looked at each individual glyph we should be able to work that one out.

[StefanPeev]

I forked the project, created new branch Cyrillic and added there masters as UFO, designspace and FontLab 8 VFC file. There is more work to be done, but you can see the direction.

[driehuis]

Excellent!

Have you thought about dealing with the Condensed and Expanded variations as well? In an ideal world, that would be another axis of a variable font. It is quite likely that the features.fea will need significant rework as well to get kerning right.

Actually, the same is true for the italics (which, except for a handful of exceptions, are just the regular glyphs slanted 12 degrees). I'm not gung ho on getting the exceptions right, and as a matter of fact we could even consider maintaining both the classic styles (three of which serve as masters for the variable font), and letting users of the variable font deal with the exceptions themselves. I'm not sure if the exceptions to the slant can even be expressed in features.fea.

Ideally, DINish would be maintainable using only open source tools. But let's resolve that when we get to the point we need to make a decision. I will not let purity get in the way of usability.

So, for the todo list:

• Clean up the existing glyphs so that the contour counts match between Regular and Bold.
  • To QA this, we'd need to generate before/after bitmaps that show the differences to see if they're acceptable. If at all possible, I'd like the diffs for the .glif's to be minimal, as I caught quite some booboos earlier by just eyeballing the git diff. I'll start by normalizing the .glif's in your tree.
• Add a hairline master, starting out with the extrapolation from the cleaned up Regular and Bold. Tweak it till it looks right.
• See if we can use the manually maintained Hairline, Regular and Bold as masters for the VF, without duplicating them under master.
• See if we can do away with the Regular master (my gut feeling says it would be off by too much if we just interpolate between hairline and bold, but the proof of the pudding is in the eating).

Or, alternatively:

• Set up a completely separate tree for the VF, which we'd treat as a different font and maintain separately.

As an aside, seeing that we're not using the hint data to generate the final fonts and that it's getting out of sync with the glyphs anyway, I'd propose to remove all manual hint data from the .glif's.

[StefanPeev]

Have you thought about dealing with the Condensed and Expanded variations as well?

Yes, of course. I'll do them as well as all Italics.

Add a hairline master, starting out with the extrapolation from the cleaned up Regular and Bold. Tweak it till it looks right.

It is a lot of work, not just few tweaks. So, give me some time.

See if we can use the manually maintained Hairline, Regular and Bold as masters for the VF, without duplicating them under master.

I don't understand what do you mean. Please, explain me.

See if we can do away with the Regular master (my gut feeling says it would be off by too much if we just interpolate between hairline and bold, but the proof of the pudding is in the eating).

It is a better idea to work with 3 masters: Thin, Regular, Bold.

[StefanPeev]

@driehuis I offered an upgrade of Dinish with included Cyrillic design.

[driehuis]

Thanks! I'll review the changes. I noticed some build artefacts in the commits, I'll clean those up. Have you run fontbakery on it yet?

[StefanPeev]

@driehuis > Have you run fontbakery on it yet? Still not. I'll change the plan of the project a little bit and I'll try to combine Dinish Normal, Dinish Condensed and Dinish Extended in one file preparing it for future variable version and well interpolated instances.

[driehuis]

I have integrated your Cyrillic glyphs into the main build. Thanks, that's a Herculean effort and the characters look like they've been part of DINish from day one!

I've had to make some touch-ups to make the glyphs consistent with the Latin glyphs, and added some glyphs for Ukrainian and Mongolian. Some of the side bearings were tweaked, notably for Ge and Gje. I will probably release v3.006 soon, announcing beta level support for Cyrillic. I've tested with pangrams in Bulgarian, Macedonian, Mongolian, Russian and Ukrainian, but not being a native speaker in any it is hard for me to judge the final results. That said, the OpenType magic seems to work correctly and the texts looks okay.

The variable font does not have anything lighter than 400, nor anything heavier than 700, so on the weight axis it is not a fully variable font yet. The Fontlab workflow conflicts with the build process, so in my estimate the variable font does not bear enough fruit to justify having to redo the entire build process. Feel free to release the VF yourself if you think it helps people, but please rename it to DINish-VF or some such to avoid confusion with the released versions of DINish.

[StefanPeev]

Thank you for the efforts, Bert. I tested the UFO Regular file in FontLab 8 and FontForge. FontForge does not provide any comments about the file. However, FontLab 8 refuses to generate features and gives the following error:

[F] Fatal error in font "D:\Fonts\Altinn DIN\Dinish-main_v.3.005\dinish-main\sources\Dinish\Dinish-Regular.ufo/metainfo.plist" in file "features" at line 712

Line 712 is:

    \guilsinglleft \guilsinglright \Euro \trademark \.null \zero.dnom

When it comes to .null, I'm guided by John Hudson's explanation in a discussion on the Typedrawers forum. So what do you think. Do we need to rename .null to NULL as John Hudson suggests?

[driehuis]

I'm surprised fontbakery doesn't complain about it (and about the fact that it's inconsistent across the family; as DinishCondensed has both a NULL and a .null).

That said, I find it hard to find authoritative information on this topic. For example, the Apple TrueType spec refers to NULL as if it's a keyword rather than a name, and afdko lists NULL as a reserved word. There must be a reason a .null glyph was added (as you can see by the position in features.fea, after \trademark, it was not present from the outset). Other notable fonts, for example Google's Roboto and IBM's Plex Sans, also include a ".null" glyph. I think an older version of FontLab was originally used to draw D-DIN, so it may well have been Fontlab that added the .null in the first place. I'm reluctant to change the name without knowing more of the reasons so many well known fonts have .null glyphs. As a matter of fact, removing the erroneous NULL glyph has been on my todo list for a while now.

I think .null should not be in the GDEF table, and especially not in @GDEF_Simple, so the quick fix is probably just to remove that keyword from features.fea to get Fontlab to like the features.fea. I'll test that change tonight.

[driehuis]

There appear to be no regressions from the cleanup, and FontBakery just stopped warning about the NULL glyph in DinishCondensed, so I'm happy...

[StefanPeev]

@driehuis The same is in FontLab 8 when I delete /.null from GDEF table (line 712). Without /.null at line 712 the feature file works fine.

[driehuis]

v3.006 just got released. Please let me know if you see anything untoward!

[driehuis]

Just noticed I had never come round to closing this issue. I just released v3.008 with a missing glyph for Mongolian, with a couple of positive reactions to the Cyrillic support to date. If any new issues arise, please raise a new issue.

I will enable Discussions soon for this project, to create an avenue for discussions that do not need to end in a specific resolution.