Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UFO/OpenType conversion #25

Open
wants to merge 61 commits into
base: gh-pages
Choose a base branch
from
Open

UFO/OpenType conversion #25

wants to merge 61 commits into from

Conversation

dpk
Copy link

@dpk dpk commented Mar 1, 2021

In 2015 I forked this repository, converted the files to OpenType format using FontForge and added several nifty OpenType features. At the time, I was modestly satisfied to have this fork for my own use without merging my (rather dramatic changes) upstream. Those who wanted these features could find them in my repo; the original remained here, untouched.

Nearly six years later, I have redone this conversion using a more modern, Git-friendly UFO-based process using Adobe’s open-source AFDKO tools, and this time, I would rather immodestly like to suggest that my version should, when I’ve completed and checked everything, be the new official version of the ET Book open source fonts.

There are a number of issues in this repository’s tracker which either have already been fixed or will be fixed in my version. #19 and some of #20 have been fixed (and as far as #19 is concerned, I intend to make further improvements on kerning later), #21 should be fixed when the fix on #20 is done, and I intend to make a start on #22/#24 soon. Further, as @skosch pointed out in #20, using a UFO-based toolchain would make this project far more contribution-friendly — at the moment, there are no font source files in this main repo which a typical font editor application could edit properly, only completed binaries converted from the original PostScript Type 1 fonts.

There is one stipulation I would add before allowing my branch to be merged into the main upstream repo: that #2 be dealt with. I cannot do this alone as I am (obviously) not the original copyright holder on the fonts, but I am willing to relicense all my own contributions under the OFL if the licence on this repository changes. The MIT licence is extremely unsuitable for fonts and its actual requirements are almost certainly not those which @tufte and his team intended to impose on users of the open-source versions of his fonts. Technically, as it stands, every web page using this font should include a copy of the MIT licence — this has not been enforced and I can’t imagine that it was intended. The OFL has some minor issue, but is the de facto standard for open source font licensing. I would like to repeat @davelab6’s plea and ask the copyright owners of the original fonts (Dmitry Krasny, Bonnie Scranton, and Edward Tufte) to reconsider their choice of licence and use the OFL instead. (There was also a suggestion in #17 to use the GPL with the Font Exception instead. I would possibly be open to doing that; indeed, it may be that I would prefer it to the OFL, but I’m not sure of the exact difference between the two in practice. I’ll await feedback from those more knowledgeable than me.)

This pull request is not yet ready to merge — I’ve opened it to solicit discussion about whether this should happen, and in particular to try to get issue #2 pushed along a bit.

@skosch
Copy link

skosch commented Mar 1, 2021

Wow, incredible. This is a massive gift to the community—thank you for this work 🙂

I, for one, wasn't aware this was under MIT. What an odd choice. I can only assume that the original creators were concerned only with the source files, and didn't consider the binaries to require inclusion of the license text (or perhaps that inclusion in the name table would do). @adamschwartz & @tufte please clarify—the easiest solution is to switch to OFL, which is MIT-in-spirit but tailored to fonts.

@Discordius this PR is the real deal, I'm happy to turn over my bounty to @dpk if this gets merged and solves your problem.

@dpk
Copy link
Author

dpk commented Mar 5, 2021

Here’s a quick status update:

  • Essentially all of the merging of features and characters from the original fonts into consolidated UFO files using OpenType features is done, including the fiddly fractions feature I could never get working in the old version. This means that you access old style vs lining figures using the corresponding OpenType feature (accessible, for instance, though font-variant-numerals in CSS, the ⌘T Typography panel in Mac OS, Numbers=Lining or OldStyle in fontspec for LaTeX, etc.) instead of loading separate lining and old-style fonts (saves bandwidth), small caps likewise through the OpenType feature instead of the Expert font, etc. There are still some different-looking characters in the Expert font which I’m not quite sure how I can sensibly merge into the main Roman font, but I’ll sort it out.
  • This includes kerning information from the fonts which was missing both in my original conversion and in the one done for the upstream repo here, albeit that it’s unfortunately very limited and somewhat inconsistent. Sometime after 2.0 I’d like to investigate the possibility of funding the use of iKern on the fonts. (I got a quote last year and it was well under €1000 iirc, but I’ve since lost the email thread. D’oh.) (Issue 12 in my fork.)
  • My goal for 2.0 is to support at least all the official languages of the European Union which use Latin script (most of the ones which aren’t supported so far are Eastern European languages). To this end I have been analysing the metrics and diacritic placements on the existing glyphs and coming up with a way to compose accented characters nicely. I hope to be able to generate a huge number of appropriate-looking accented characters automatically based on this analysis. I’ve also drawn a Croatian d-with-crossbar in all the weights and styles of the font, which was the only missing character needed for this set that isn’t a simple base character + diacritic combination. (Edit: Damn, I forgot the h-with-crossbar used in Maltese. Will have to draw that one too.) (Issue 2 in my fork.)
  • Shortly after 2.0 I hope to extend that to all the minority and regional languages of Europe, too. To that end I’ve drawn eng, Eng, and ezh (for Sami, but also useful for some African languages and English IPA) in the Roman font, and am looking at the possibilities for drawing them in the other weights and styles too. (Same issue.)
  • Since I was messing around in the glyph editor anyway and it was relatively easy to put together, 2.0 will also likely include an fj ligature (useful for Norwegian, Swedish, etc., and for the English loanword fjord) — like đ, I now have it ready in all weights and styles.
  • The hinting issue (On windows and linux: Capital and lowercase 'w' have size and kerning issues ($500 bounty) #20 and On windows and linux: Font weight is too light for comfortable reading #21 in this repo) continues to be somewhat vexing. I’ve learned a lot about how PostScript font hinting works and how to get psautohint to work a bit better on the font, but there are still some behaviours I just don’t understand (most bafflingly, hinting causing characters which were drawn shorter to appear larger in comparison to other characters — and vice versa)! I tried converting the finished OTFs to TTFs and running ttfautohint over them, but the result didn’t look any better than having no hinting at all. psautohint hints more aggressively and thus gives more legible results, but also requires more work to get it not to do strange things. This is the one issue I could most use outside help with, from someone who knows how these things really work. (Issue 4 in my fork.)

And now the bad news: this has been a fun distraction between two exam seasons for me while trying to work off the stress from the first one, but I do have to study for an exam near the end of the month, and I have other (paying) work to do as well. So progress might slow a bit now. I’m good at using projects like this to procrastinate other things, though 🙈, so it definitely won’t grind completely to a halt ;-)

dpk added 27 commits March 6, 2021 09:38
This will help determine which characters I need to add to support
more languages.
@dpk
Copy link
Author

dpk commented Sep 21, 2021

My work on the font has stalled again, but it looks like the first outing for the new đ character will be in my current term paper for university — and not in Croatian but in (an older reconstruction of) Proto-Indo-European!

Screenshot 2021-09-21 at 11 50 16

(Don’t be confused by the other funny characters — they’re mostly bodged together in TeX from the other accent marks that are available in ET Book already. The superscript w is just a superscript w, and the gamma is from GFS Porson (which works well as a drop-in to mix with the italic, don’t you find?).)

I hope I’ll be able to get back to work on the font in mid-October maybe, but after my current uni stress is over, the next semester starts right away, so maybe not. Let’s see.

@skosch
Copy link

skosch commented Sep 21, 2021

Nice! I was just about to ask about the gamma – it looks great!

@inklesspen
Copy link

@dpk in your opinion, is this branch currently suitable for use as a webfont for English-language content?

@dpk
Copy link
Author

dpk commented Apr 20, 2023

Probably, yes: if you install all the dependencies (which aren’t documented, sigh, but just install anything that looks like it’s missing) and run make woff woff2, you should get reasonably hinted (through ttfautohint, tested with FreeType though not on Windows) fonts with ‘good enough’ support for English.

Caveats to this:

  • If you ever use the double-dagger sign (‡), for instance as a footnote indicator, you’ll get an ff ligature instead; if you have a website theme that (ab)uses the ‹ and › quotation marks as arrows, you’ll get other ligatures.
  • The kerning is not very good, although it’s better than the main branch here which completely omitted the kerning data present in the original AFM files.

@adamschwartz
Copy link
Member

@dpk Would you recommend I merge it? You’ve done so much great work here. I’m happy to defer to you. (And thank you!)

@dpk
Copy link
Author

dpk commented Apr 21, 2023

I ideally wanted to significantly improve language support, which is currently the main sticking point, but I guess an interim release without that would be okay.

I would like to fix the issue with the double dagger and single guillemets, and fix the other two issues under the 2.0 milestone. https://github.com/dpk/et-book/milestone/1 The copyright metadata one should be fairly easily; I’m not sure how much work it will be to stop makeotf’s warnings. Double dagger is designed in roman and italic, it just needs bold and semibold. Correct single guillemets are in the roman only.

The other issue not mentioned there is the fate of the Display Italic font. It seems very sad on its own – is there perhaps a corresponding Display Roman that wasn’t released here? I’ve considered just ditching it as it seems odd to have an optical display size for an italic only.

@dpk
Copy link
Author

dpk commented Apr 21, 2023

Oh, and it needs a new gh-pages build.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants