Some work I have done #9

Closed
wants to merge 19 commits into
from

Conversation

Projects
None yet
3 participants
@rbmntjs
Contributor

rbmntjs commented Apr 8, 2012

Hey,

I see I need to update my own repo, but here's a bunch of things that have been bugging me for over a year, and I never committed any of it. So there.

—r

rbmntjs and others added some commits Feb 28, 2009

Cleaning up my deal: fixed a few points, made a few curves more balan…
…ced, changed some tiny particulars. Should be more sensible, once more.
Updated font name in metadata to Open Baskerville
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.
Cleaning the UFO
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
Converted (through Area51) the UFO from v1 format to v2
-Extra Opentype metadata fields in fontinfo.plist
-PostScript Hint information now moved to fontinfo.plist
-OpenType features in their own file
Remove stray carons, fixes #3, line height
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
Remove other extraneous accented glyps
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.
♪ Build-scripts and a Rakefile
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.
Programatically generate FONTLOG.txt
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.
'rake install' installs the font
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.
'rake release' creates font with generated version number ♫
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.
@codingisacopingstrategy

This comment has been minimized.

Show comment Hide comment
@codingisacopingstrategy

codingisacopingstrategy May 10, 2012

Collaborator

Somehow our paths had diverged, but I git cherry-picked my way through this!

( I think you need to reclone the klepas repo )

takk!

Collaborator

codingisacopingstrategy commented May 10, 2012

Somehow our paths had diverged, but I git cherry-picked my way through this!

( I think you need to reclone the klepas repo )

takk!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment