-
Notifications
You must be signed in to change notification settings - Fork 120
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
Important design changes #18
base: master
Are you sure you want to change the base?
Conversation
…ced, changed some tiny particulars. Should be more sensible, once more.
The font menu name in the OS is not based on the file name, but on the font metadata. James Puckett's working title for his revival of Fry's Baskerville was Large Frys.
By roundtripping through Area51. - Floats that want to be ints become ints - Widthname 'normal' normalised to a field value from the Opentype OS/2 table usWeightClass 'Medium (Normal)' - Placeholders for PostScript hinting data
-Extra Opentype metadata fields in fontinfo.plist -PostScript Hint information now moved to fontinfo.plist -OpenType features in their own file
We had problems with excessive line-height in FontForge generated OTF’s. Big thanks to Khaled Hosney: he pointed out in a discussion on fontforge-devel that some of the characters had accents way above their normal positions. This was causing the seemingly superfluous linespace. The problem manifests itself in alternate versions of the Scaron, scaron, Zcaron and zcaron glyphs. They were removed. bug: http://openbaskerville.lighthouseapp.com/projects/24633/tickets/3-excessive-line-height#ticket-3-5 discussion: http://sourceforge.net/mailarchive/forum.php?thread_name=6D03471D-AADA-4071-837C-12F060810309%40authoritism.net&forum_name=fontforge-devel
For accented glyphs as acute.glif there exist alternative versions aacute_001.glif, acute_002.glif. The versions without the suffix are the ones mapped to a unicode point, and the ones actually used by applications. The alternative versions differ in their exact placement of the accent. Since having multiple variants is confusing, I’m deleting them. If you want, you could look at these glyphs in the history and see if their accent positions look better than those in the standard glyphs. If so, you can copy over the coordinates to the standard glyphs.
Now you can compile a font! Works with both FontForge and the Adobe Font Development Kit for OpenType. The former is what we aim for as our main compiler, as the latter is closed-source, but to have both is great for testing the UFO spec. Run ''rake'' to generate the font. ''rake diagnostics'' will give you an overview of your current build environment and advise you how to proceed if it can’t find the right build tools. If you want more control you can use tools/ufo2otf.py which provides a command line interface: you can choose input and output files, and which compiler to use.
Via ''rake fontlog'' The FONTLOG is SIL’s concept of a chancelog for a font. When doing a release, we generate one automatically based on AUTHORS.txt, README.txt and the repository history.
Or rather, any otf file found in the folder. I had to remove generating OpenBaskerville.otf as a dependency, since it can conflict with the upcoming 'generate release' task. I should probably look into rake namespacing. In the metadata, removed entries related to FOND resources, I am not sure if they are actually useful, and they could cause conflicts when installing multiple Open Baskervilles.
When a designer uses a font, it is critical that she or he can identify the particular version unambigously. We also want to make sure that designers can use our development snapshots. That’s why for every commit there needs to be a potential version number. We could, theoretically, use git hashes as identifiers. However, they look cryptic to end users, and they don’t provide information about the chronology of versions. Taking cues from the semver.org spec, our version number takes a form X.Y.Z., where X is the major version, Y the minor version, and Z the patch version. Minor versions have a defined set of goals, and get tagged in Git, we started with 0.0.0 and we are now working towards 0.1.0. Our patch versions, are built from the source tree after each commit. So from the first commit after 0.1.0 we can build 0.1.1. To do a release, we use the ''git describe'' command to tell us the last tag and the number of commits since that tag, whereupon we base a version number that we bake into the ufo and thus into the generated font.
Error seems to be related to the features, a syntax error in the onum feature.
This reverts commit 7f8a325.
Git cruft got into the files, on my side. Very strange. Cleaned out.
I was younger then. I have learned since.
Hey Rob, I can look in to this, sorry I didn’t react earlier! The reason that I didn’t just went and merged it is that I can’t.. Our histories differ.. You re-added the files, but in git you don’t just need to have the same files, you need the same history! I’m going to try ‘git cherry-pick’ your changes. After I merge, would you be so kind to re -clone the klepas repository and work from there? Thanks! best, E |
Rob, I don’t succeed in merging. Like I said our version histories started to differ… Can you clone Klepas Baskerville under another name, open it in RoboFont, and copy paste from your version into the Klepas one, commit, and push to a new repo? thanks! e |
I have revised a few of my character designs, trying to get closer to the design voice of the specimens. The last real connection between our code bases has been a long time ago, so I took care to pull in all of the better glyphs into mine. A pull would not give too many problems, I think. I’ve done local diffs and the changes are now, aside from some RoboFont-generated data, intentional and better. Please get in touch if you disagree. I’ll happily discuss the work I’ve done on this.
Thanks!