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

Important design changes #18

Open
wants to merge 31 commits into
base: master
Choose a base branch
from
Open

Important design changes #18

wants to merge 31 commits into from

Conversation

rbmntjs
Copy link
Contributor

@rbmntjs rbmntjs commented Sep 7, 2012

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!

rbmntjs and others added 30 commits February 28, 2009 16:24
…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.
Git cruft got into the files, on my side. Very strange. Cleaned out.
I was younger then. I have learned since.
@codingisacopingstrategy
Copy link
Collaborator

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

@codingisacopingstrategy
Copy link
Collaborator

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

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.

3 participants