Thanks—and a plea

[psb1558]

I’d like to thank all who’ve submitted issues over the past couple of weeks. Your contributions have made an enormous difference in the quality of the font. As we approach the release of Junicode 2, I’d also like to beg for more checking and more issues, because I can’t give the font a comprehensive review myself.

By way of explanation, here are a few stats. Between the roman and the italic faces, the font contains 10,180 glyphs. Each glyph is interpolated from six masters—so the font’s source consists of 61,080 masters. There is a roughly similar number of kerning pairs. All of the masters and kerning pairs should be checked, because a small, barely visible error in a single master or kerning pair can trigger an all-too visible error in one or more of the font’s instances. Speaking of instances, the static version of the font consists of 38 files containing a total of 193,470 glyphs, each of which should be checked.

How did the font get so big, when it is the creation of just one person? The answers are, first, that it has been in development for over thirty years (340-odd glyphs per year is not so bad, even for a spare-time project), and, second, that it has always been responsive to requests from users, including medievalists (of course), classicists, linguists of every stripe, and scholars in many more fields requiring the kind of font support that commercial products don’t typically offer because there’s little or no money in it.

I recently tried to estimate the number of Junicode users, but discovered that it couldn’t be done, except by checking font sites that offer download stats. I stopped counting somewhere between 450,000 and 500,000—and of course I had no way of counting people who’ve downloaded it in TeXLive, or various Linux distributions, or Homebrew. The total number of downloads must be well over a million, and even if only a fraction of those represent active users, still the number of users is probably pretty large for a font of this kind, mainly aiming to serve a scholarly audience.

I have received almost nothing by way of compensation for my work on Junicode. Once someone donated, I think, $25 via a button on my old SourceForge page, and another time a fellow-medievalist at a conference bought me a beer because, he said, “You made Junicode.” The kind of compensation I would like most is engagement—for some fraction of Junicode’s user base to download the beta of Junicode 2 (currently version 1.067, but I am posting a new version every couple of days), set one of their favorite texts in it, and examine it for problems: faulty letter-shapes, bad spacing, glitches in OpenType features, etc.

Because I can’t do it all by myself.

Many thanks.

(Feel free to share this if you know of any place where it might reach Junicode users.)

[jsbien]

I had no way of counting people who’ve downloaded it in TeXLive, or various Linux distributions,

Debian Popularity contest statistics for fonts-junicode (https://qa.debian.org/popcon.php?package=fonts-junicode).

[alerque]

In a similar vein, here are relevant package stats for Arch Linux. The scale is a percentage of Arch Linux systems participating in (opt in) reporting of installed packages that have X package installed. 5% of systems may not seem like a lot at first, but for a specialty font and given the size of the Arch install base that's a pretty sizable number.

[psb1558]

Thanks, Janusz!

[kenmcd]

As we approach the release of Junicode 2, I’d also like to beg for more checking and more issues, because I can’t give the font a comprehensive review myself.

Your post about the Italics now being complete was the trigger for me to take a closer look, and start posting some issues. And that will continue.
As some of the big stuff is fixed, we (I) can get into other issues like OpenType features.
The only way to really check OpenType features is to document them completely.
Then the errors appear.
Stuff that is wrong.
Stuff that is missing.
The devil is in the details.
So I am going to fire-up my old LO docs and take an updated closer look.

The kind of compensation I would like most is engagement—for some fraction of Junicode’s user base to download the beta of Junicode 2 (currently version 1.067, but I am posting a new version every couple of days), set one of their favorite texts in it, and examine it for problems: faulty letter-shapes, bad spacing, glitches in OpenType features, etc.

When you feel the beta is ready for wider review, you should start doing actual releases.
Right now you are only "releasing" to a few GitHub font geeks (e.g. moi).
GitHub users can subscribe to just get notices of the releases, and many do.
A release says - this is ready for more users to look at closely and to give feedback.
With the release text, you can ask for help testing, point where to submit issues, etc.
And releases do end up in various GitHub activity streams for all GH users.

An actual beta release is a sort of press release - which does have a link on the project home page, which goes directly to the download.
Makes it much easier for non-GitHub-geek regular ol' end users to download.

We can also do some "press release" type posts in the most logical places.
I can certainly post it in the Affinity forum - with info, images, links, requests, etc.
Spent 8 years living with a global corp PR expert, so I've got the basics down.
I am sure both you and Janusz also know a few places where it would be good to post.

If I post updates to the Affinity thread, that will push it to the top again.
Affinity applications do support the cvXX and ssXX descriptions, etc.
I sent them some fonts to use to help get it done.
And then tested it when released - works well.

Hmm... just looked at the v1.064 static Regular - and no cvXX descriptions.
Hope you did not remove them because of InDesign's bugs.
I see the GF folks talking about this from time to time, and their usual policy is to not work around Adobe bugs. (or other apps bugs - otherwise never-ending)

Summary: I am going to keep looking at stuff and posting issues,
and you should do actual beta GitHub releases to get more eyeballs.

[jsbien]

The only way to really check OpenType features is to document them completely.

Looks like possibly useful tools exist for the STIX fonts: stipub/stixfonts#247 (comment)
Both myself and Karl Berry tried to persuade David Jones to make them available publicly, but he didn't respond.

[psb1558]

@kenmcd: Thanks for these observations. The bizarre family name and lack of releases were meant to discourage scraping by the free font sites, which are happy to post beta versions of fonts and then never update. But the time has come, I suppose, to change the name back to "Junicode" and start putting up releases.

Both Junicode and Elstob have a full set of cvNN descriptions. I have tested them in Affinity (last I checked the only major apps that can use them), and I keep them up to date whenever I make any change in those features, but they are currently commented out in the source because of the situation with InDesign. You're probably right about not working around InDesign's bugs (I have long refused to work around MS Word's bugs and deficiencies). I suppressed the descriptions because I was doing some testing in InDesign, but perhaps it's time to put them back. I like to think that the existence of one more font that doesn't work in the Creative Suite will encourage them to fix their code, but probably they don't care much about any but commercial fonts, and especially the ones in their own font library.

@jsbien: I get where the Stix people are coming from. I've got lots of little scripts that I wrote for particular purposes, and I keep them in case I want them again, but I mostly don't put them in the repository because (1) they will only work with the fonts they're written for, and (2) they are messy and amateurish. I include them only when they're needed to build the font, or in the case of fontloop.py, when it demonstrates a thing that others might find useful.

Still, those Stix code charts are nice, and it would be interesting to have a peek at the sources used to make them.

[alerque]

SILE should be able to handle open type features properly (uses Harfbuzz for shaping). That makes FontProof available as one way to test fonts either locally, remotely in CI, or both. We just need to come up with some sample texts. We can probably automate generation of tests covering some of the feature types, but automation wouldn't show them in context very well, at best I think it would just be a grid of affected glyphs. For best effect a hand tailored set of samples demonstrating a case where a feature matters would be much more useful.

[psb1558]

Thanks for this, Caleb! I've installed Sile and FontProof. Sile looks pretty accessible for an old TeXhead (and I've grabbed the manual). And I see that it supports variable fonts! My first attempt to get FontProof going with Junicode hasn't succeeded—but I confess that I'm the sort who tries out a piece of software before reading the manual.

I can contribute texts in Latin, several medieval western European languages (Gothic, Norse, French, German, all stages of English), and several modern western languages. I don't know Greek, but have found it easy to obtain polytonic texts.

For other languages, I think it would be best to recruit experts. Languages I've been asked to support, over the years, include Lithuanian, Polish, Vietnamese, Turkish, Sanskrit (in transliteration), and Egyptian (in transliteration). Probably more that I've forgotten. Of course requests for support from linguists have been very frequent, and phonetic transcription can be very demanding of OT features. I would want to locate sample texts in these languages and scripts, at least.

So the testing regimen you describe sounds very worthwhile. It will take some time, but the time will be worth it.

[alerque]

Well I'll be able to help with Turkish some, and of course with the SILE and FontProof end of things. Lets get this party started and play around with how it should work (just post PDF artifacts for review? do automatic visual comparisons?), where data should be kept (e.g. if the test cases have a lot of overlap with Elstob or other fonts it might make sense to share some of the proofing data), etc. I'll be in slow-mode for a few weeks at least traveling, but can probably piddle around with contributing.

[psb1558]

I've just now posted version 1.068. Issues addressed so far include #188, #190, #191, #192 (again), #193, #194, #196, #197, #199, #200, #202, #203, #208 (tentatively), #209. Some others partially.

@kenmcd: I've restored the cvNN descriptions. I glanced at them in Affinity Publisher 1.10.6, where they look okay, except that the list (very long for Junicode!) doesn't scroll. (It would be cool if the Affinity Character Variant menu showed only those that are relevant for the current selection.) I don't particularly want to pay for an upgrade to version 2.N, since I haven't got a use for that app. If you've got Affinity 2 and can check it there, that would be very helpful.

Restoring the cvNN descriptions means that OT features won't work in InDesign until Adobe fixes that bug.

[kenmcd]

@kenmcd: I've restored the cvNN descriptions. I glanced at them in Affinity Publisher 1.10.6, where they look okay, except that the list (very long for Junicode!) doesn't scroll. (It would be cool if the Affinity Character Variant menu showed only those that are relevant for the current selection.) I don't particularly want to pay for an upgrade to version 2.N, since I haven't got a use for that app. If you've got Affinity 2 and can check it there, that would be very helpful.

OK. Great.
I will check out v1.068 in Affinity Publisher v2.1.1.
And if I see any problems (like not scrolling), I will post an issue with Affinity.
Note: their method of showing what OpenType feature is relevant is kinda wacko.
The issue has been mentioned multiple times - and no response. I gave up.
But, I will mention it again if I need to post an issue about this.

[kenmcd]

Restoring the cvNN descriptions means that OT features won't work in InDesign until Adobe fixes that bug.

I just remembered something...
When I sent the fonts with cvNN descriptions to Affinity so they could use them to add the feature, I also sent a font that I had added generic text to - filled all the fields with stuff like "DesciptLabel1" and "ToolTip1" and "SampleText1" etc. so they could see what field was appearing in the interface.
I also sent some FOSS fonts that I knew had cvNN descriptions - Charis SIL, Source Code Pro, and Source Sans 3.
And I noticed back then that the Adobe fonts, Source Code Pro and Source Sans 3, had a different format for the feature code then what came out of the font I did in FontCreator OpenType Designer.
Did a little research and found there were two different formats.

So perhaps InDesign does support this feature with Source Code Pro and Source Sans 3, because they use a different format.
IIRC I did check all the fonts I sent in Affinity Publisher and they all worked fine.
So Affinity apparently supports both formats (I will check all this again in v2.1.1).

So check Source Code Pro and Source Sans 3 in InDesign and see if they work.
https://github.com/adobe-fonts/source-code-pro
https://github.com/adobe-fonts/source-sans

Regardless, InDesign should support both formats.
And they certainly should support what Glyphs is producing (dumb not to).

[psb1558]

I tried out Source Sans 3 in InDesign, and it worked fine. Then thought: "Haven't tried Junicode in InDesign in a few months: I'll have one more look before I go to any more trouble."

And it worked. I have no idea whether Adobe repaired InDesign, or some recent version of fontmake (which I use instead of Glyphs to generate: I've got an entirely Open Source toolchain for generating fonts) started producing a more Adobe-friendly format for cvNN descriptions.

I guess I won't worry about it. The fact is, it works now.

[psb1558]

I've just posted 1.069 (static ttf and otf, variable ttf). I believe I have addressed all the issues posted so far: if you posted any issues, please check the font and close yours if you're satisfied.

After this one, I would propose changing the family name to "Junicode" and the version string to "Version 2.000beta1" (which I have discovered is quite possible with Glyphs/fontmake). I will also start tagging and making releases as suggested by @kenmcd and @alerque.

The next step, as suggested by @alerque, is to stress-test the fonts (including OT features) by throwing as many different kinds of text as possible at the font using Sile and FontProof.

But of course I still welcome issues concerning outlines, anchors, metrics, etc.

[psb1558]

@alerque: I've uploaded a little file, ancrene_wisse.sil (a demanding bit of early Middle English), and I'm wondering if you could take a look at it.

As you can see, I've already found a few things that need fixing. But what I'm mainly wondering is what I'm doing wrong with \add-font-feature and \font: I can't figure out how to supply an index for a cvNN feature with \add-font-feature, and I'm getting odd results when I try to turn off or change an active cvNN feature. Unfortunately the docs don't go into this particular corner of SILE usage in great detail, but it seems important for testing Junicode.

I think maybe I should make a proofs directory and put your demo and any other proof documents there. Will I break anything (like your workflow doc) if I do that?

[alerque]

I'll take a look but I'm also on the road all this week...

[psb1558]

Thanks, Caleb. No hurry at all.

[alexmyczko]

Thank you! I'm just a bit irritated because:

24,781,764 B in 38 files fonts/otf/* of 20230104
61,902,396 B in 38 files fonts/otf/* of 20230730

it might be all fine, but a little bit it's surprising... can this somehow be explained easily?

[psb1558]

fnt looks interesting. I'll grab it and have a look.

I don't know how Debian sets up FreeType. My understanding is that FreeType's built-in autohinting is good, but if I remember rightly it has to be turned on.

There's a method of stripping out CFF hints mentioned here. But it seems better to me to simply build without hints. I have a halfway decent build script now, and the only programs needed to build the fonts (if you're skipping hinting) are fontmake and glyphspkg (install with pip in a reasonably current Python environment). To build without hints just use the -n option:

./build_font -n otf
./build_font -i -n otf

Without hints:

-rw-r--r--@ 1 peterbaker  staff   701492 Jul 30 16:20 Junicode-Bold.otf
-rw-r--r--@ 1 peterbaker  staff   694912 Jul 30 16:20 Junicode-Regular.otf

With hints:

-rw-r--r--@ 1 peterbaker  staff  1584376 Jul 30 16:23 Junicode-Bold.otf
-rw-r--r--@ 1 peterbaker  staff  1568000 Jul 30 16:23 Junicode-Regular.otf

[khaledhosny]

I don't know why psautohint more than doubles the size of the files

psautohint desubroutinizes the CFF before hinting, and does not subroutinize it back, so if it is the last step and you are applying it to the binary file, this might be the cause. You might want to use cffsubr to subroutinize the file again after calling psautohint (note if you are also generating also WOFF2 files, they might compress better when desubroutinize, so you might want to check for that).

[khaledhosny]

It looks like it, I run cffsubr on Junicode-Regular.otf and the file is cut by nearly half:

$ du -h --apparent-size Junicode-Regular*
800K	Junicode-Regular-subr.otf
1.5M	Junicode-Regular.otf

(psautohint seems to leave out also the old Subr data even it is now unused, increasing the file size even more, so you might want to disable subroutinization in fontmake with --optimize-cff=1 so even if you don’t subroutinize again you won’t have unused Subr and it should be faster anyway)

[khaledhosny]

You might also want to use --optimize-cff=1 as I think psautohint undoes the specialization as well, so it is just waste of time.

[psb1558]

This is extremely useful, Khaled! I will definitely try these things.

[psb1558]

I have uploaded Junicode 2.000beta1 and tagged it. I have not created a release--not until I figure out how to organize it (for example: should there be separate zip archives for otf/ttf/variable versions?).

I have tried to address all issues that don't require new features, but if you have opened issues, please check. There are some outstanding issues on my to do list:

1. STAT table needs revision (format is not the current practice: Adobe doesn't like it!).
2. Italic face of variable version is missing a number of hints.
3. Checking of OT features has only just begun; there are at least two bugs that need fixing.

[alerque]

I would suggest one ZIP for all formats. Of course having written it the output structure of fontship is my personal favorite.

[psb1558]

I've just posted version 2.000beta2. I've addressed a few issues, and I'm still working on getting hinting caught up in the Italic, but the most noticeable change is that I have abbreviated several style name elements:

• Semi -> Sm
• Condensed -> Cond
• Expanded -> Exp

That makes the longest style name (I think) 29 characters (Junicode smCond smbold Italic), which should ease the Windows problems quite a bit.

Some of the file names are now different, so when you install, you must uninstall the old version first; otherwise you'll have old files hanging around and making your life difficult.

[psb1558]

And now version 2.000beta3! The only change here, but a significant one, is corrected style linking/naming after @kenmcd found some errors in the naming table. The font appears to work better now in some apps where it was problematic before.

[alexmyczko]

wow beta3 already, final can't be far. /me waits

[psb1558]

Depends on how much more horrible stuff folks discover in the font, and how hard the fixes. 😄

InDesign is rejecting the italic variable font, so there's that. Probably a problem with the STAT table.

[psb1558]

Beta4 is in the repository. It fixes some kerning issues in the Italic face, corrects one error in the roman, and revises the STAT table (using mainly Format 1 Axis Values and adjusting the names to match more closely the patterns in the latest Source fonts).

One thing I'd like to manage before removing the "beta" label is to make the variable version of the font work reliably in InDesign, which is very particular about the STAT table, the PostScript names in the fvar table, and presumably other things (Illustrator is not nearly as persnickety). Beta4 doesn't get us there: Beta5 will either solve all problems or be accompanied by a plea for help in this area.

I also need to finish hinting the variable italic (the variable fonts are manually hinted, the static fonts autohinted).

[kenmcd]

@alexmyczko
This is totally inappropriate and does not belong here.
Please delete it now.

[psb1558]

Version 2.000betat6 is now in the repository. This includes minor fixes (most of the major stuff has been done now) and a significant change: flattening all the glyphs with components so that component nesting is never more than 1. This should take care of some problems with a few old, buggy printer drivers.

One major outstanding issue remains, namely that something about the italic variable font causes InDesign to crash when you attempt to use the axis sliders. (It performs perfectly in the other apps I've tried.) You'd normally expect the STAT or fvar table to be at fault, but I've been over and over them, and have tried many ideas (with the generous help of @kenmcd), and none of them has helped. I'm beginning to think that a problem with the STAT or fvar table is unlikely, but I can't think where else to look. A font is a big complicated thing, and if the fault is not in STAT or fvar, well, it could be anywhere.

If anyone with more expertise than I have wants to look at the current incarnation of the fonts, I'll be grateful. For my part, I am completely stuck, and I'm thinking that I can't release the variable font until the issue is resolved.

[khaledhosny]

One major outstanding issue remains, namely that something about the italic variable font causes InDesign to crash when you attempt to use the axis sliders.

InDesign (and other Adobe apps) has a bug/limitation that requires setting name ID 25 (Variations PostScript Name Prefix) and making it different between upright and italic fonts.

[psb1558]

Thanks, @khaledhosny. Unfortunately, Junicode VF has had name ID 25 set correctly for a long time:

<namerecord nameID="25" platformID="3" platEncID="1" langID="0x409">
  JunicodeVFItalic
</namerecord>

<namerecord nameID="25" platformID="3" platEncID="1" langID="0x409">
  JunicodeVFRoman
</namerecord>

The problem seems to be somewhere else.

[psb1558]

I've just dropped a couple of files in the docs directory: language_samples.tex and language_samples.pdf. This sets a number of short texts in various languages and styles as a way of stress-testing the font's character set and features. It has already helped me turn up at least a dozen errors and desiderata. If anyone reading here happens to glance at it and spot things that still need correcting, I'll be grateful. And if you've got suggestions for other languages or texts to look at, I'll be glad to hear of them too. I'm particularly interested in languages that (like Lithuanian) pose typographical challenges and texts (like the Middle English and Old Icelandic samples) that make heavy demands on Junicode's character set and features.

[psb1558]

I am thinking that the InDesign crash problem is never going to be completely solved. But it turns out that ID doesn't have to crash on using Junicode VF.

It appears that the solution is (you're gonna love this, @khaledhosny, as one of the top contributors to HarfBuzz) to switch to the World-Ready Paragraph Composer!

[kenmcd]

It appears that the solution is (you're gonna love this, @khaledhosny, as one of the top contributors to HarfBuzz) to switch to the World-Ready Paragraph Composer!

Well, that is interesting.
So it could be something in the GPOS or GSUB feature code.
Maybe a more advanced structure, or format?
And the ID standard shaper just cannot figure it out.
And Harfbuzz does.

I tested exporting the fonts from FL8.
If I leave the feature code as is (set it to not decompile), the fonts will export.
If I set it to decompile the feature code, and then export, it shows multiple "FEA compiler error" messages and says "Feature compilation fails" for different features.
I guess that is what also happens for you with Glyphs - it cannot compile the feature code.

Now going to try exporting from FontCreator also.

[psb1558]

So it could be something in the GPOS or GSUB feature code.

I'd say probably GPOS, since only there will you find values that change with the various axes.

[psb1558]

I've just uploaded (and tagged) version 2.000beta7. Since issues have slowed way down, and I am feeling much more satisfied now than I was a little while ago, I'm thinking that this may be the last beta.

(@alexmyczko, get a load of the sizes of the .otf files. They're fully hinted, but smaller than the .ttf files now!)

[kenmcd]

Glad you found out they work in ID with WRC enabled.
All the VFs I exported from FL and FC did not work at all.
So moving on...

I've just uploaded (and tagged) version 2.000beta7. Since issues have slowed way down, and I am feeling much more satisfied now than I was a little while ago, I'm thinking that this may be the last beta.

OK. Great.
Will install those and actually look at some other stuff.