googlefonts / fontmake

Compile fonts from sources (UFO, Glyphs) to binary (OpenType, TrueType).
Apache License 2.0
764 stars 93 forks source link

UFO subsetting flag documentation #343

Open chrissimpkins opened 7 years ago

chrissimpkins commented 7 years ago

Would it be possible to document the glyphsLib subset / export flag key/value strings (or other types if used) that are used in your subsetter and where in the UFO source this lives so that these can be implemented directly in UFO source? It looks like it is maybe an array of glyph paths/names in a property list under a com.schriftgestaltung.XXX key within the lib.plist file of UFO?

https://github.com/googlei18n/fontmake/blob/master/Lib/fontmake/font_project.py#L322

Thanks!

anthrotype commented 7 years ago

You can use either com.schriftgestaltung.Keep Glyphs (which is a list of glyph names that will be kept, the rest are dropped) in the global font's lib.plist, or the com.schriftgestaltung.Glyphs.Export boolean flag in a glyph's lib element.

If com.schriftgestaltung.Keep Glyphs key is not present or empty in the lib.plist, it's ignored (all glyphs are kept).

If com.schriftgestaltung.Glyphs.Export is not present, it defaults to True, which means you can add a False value for the glyphs you wish to drop.

chrissimpkins commented 7 years ago

Thanks Cosimo!

To confirm that I understand, you mean like this:

lib.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>com.schriftgestaltung.Keep Glyphs</key>
  <array>
    <string>A</string>
    <string>B</string>
    <string>C</string>
  </array>
</dict>
</plist>

where A, B, C are the names (not paths to *.glif files)?

anthrotype commented 7 years ago

Yes

chrissimpkins commented 7 years ago

Thanks again! Interested in adding this to your documentation in some fashion? Happy to PR in. If not, I can close this.

anthrotype commented 7 years ago

ok, if you like. So many other things need documenting. But one needs to start from somewhere, so any contribution is welcome of course. Maybe the Github "Wiki" page could be a place to have something like a "FAQ" with things like that...

chrissimpkins commented 7 years ago

Will do.

moyogo commented 7 years ago

I’d rather have the documentation in the repository instead of the wiki.

chrissimpkins commented 7 years ago

Will try to draft portion Cosimo and I discussed tonight and leave it somewhere that you can pull it in whenever / wherever convenient.

chrissimpkins commented 7 years ago

Would a tool that automates addition and removal of these subsetting flags in UFO be of any use to anyone else? And does this exist elsewhere? I am giving some thought to this for our web font builds as a source modification step prior to the compilation steps.

chrissimpkins commented 7 years ago

FAQ

How do I subset a font built with UFO source?

fontmake uses the UFO lib.plist source file to determine the glyphs to maintain within the subset font built from a given directory of UFO source. This file is formatted as an XML property list and sits in the root of your source directory according to the UFO source specification. It is an optional file and therefore may not exist in your .ufo source directory. If it does not, simply add a file on the path lib.plist in the root of the UFO source and follow the instructions below.

The information that you need to create a list of glyphs that you intend to maintain in your compiled subset font include:

Glyph names can be identified as the keys in your UFO source contents.plist file that is found in the glyphs directory of your source on the path glyphs/contents.plist.

Format the property list with the glyphsLib key string followed by an array of glyph name values that are formatted as string elements.

An example of a build subset that includes only the upper case A, B, and C glyphs in the compiled font is demonstrated below:

lib.plist

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>com.schriftgestaltung.Keep Glyphs</key>
  <array>
    <string>A</string>
    <string>B</string>
    <string>C</string>
  </array>
</dict>
</plist>

Extend the array of glyph names to include all glyphs that you desire in your final font by adding additional lines that are formatted as <string>GLYPHNAME</string>.

To build your subset font, execute fontmake with the --subset flag on your UFO source directory that includes the above lib.plist modifications as follows:

$ fontmake --subset -u Test-Regular.ufo
chrissimpkins commented 7 years ago

Feel free to add above wherever most appropriate if this is satisfactory.

chrissimpkins commented 7 years ago

An issue with lib.plist use for this task that arose during our consideration about how to approach collaborative typeface development in UFO source among contributors who might use different font editors.

https://github.com/source-foundry/Hack/issues/277

Unclear how best to address this issue on our end. It would be helpful to eliminate font editor specific changes to source files in a collaborative project where the goal is to support the use of any source editor in local development environments. Ideally, you should be able to do this with UFO. In practice, this means that everyone pushes editor specific changes upstream with their commits that must be reviewed (unnecessarily).

moyogo commented 7 years ago

I'd recommend normalizing the lib.plist instead of adding it to gitignore. You could only keep the keys you care about. You may want to make sure you're not dropping useful keys.

On Tue, 22 Aug 2017, 17:05 Chris Simpkins notifications@github.com wrote:

An issue with lib.plist use for this task that arose during our consideration about how to approach collaborative typeface development in UFO source among contributors who might use different font editors.

source-foundry/Hack#277 https://github.com/source-foundry/Hack/issues/277

Unclear how best to address this issue on our end. It would be helpful to eliminate font editor specific changes to source files in a collaborative project where the goal is to support the use of any source editor.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/googlei18n/fontmake/issues/343#issuecomment-324073895, or mute the thread https://github.com/notifications/unsubscribe-auth/AB1ao1ktqe-pZqa6iYv-iTcXBwkDyrk9ks5savwygaJpZM4O4UDl .

chrissimpkins commented 7 years ago

@moyogo thank you very much Denis. Normalization is not a term that I am familiar with. Can you explain what this is and what tool can be used to remove specific keys in the plist files? I would ideally like to have contributors maintain clean lib.plist files so that we do not need to review and manage these changes upstream. We could certainly handle this with documentation if there is a way to 'clean' the source of application specific metadata before a pull request.

madig commented 5 years ago

Normalization means taking some input and turning it into some canonicalized form. There are a million ways to format XML files and font editors do all of them, a normalizer would standardize e.g. the indent (how many spaces? tabs?) and sort the plist keys. Take a look at https://github.com/unified-font-object/ufoNormalizer/. Or, as @anthrotype once suggested to me, just load a font with ufoLib, lazy=False, and save again and see the output as normalized.

As for cleaning lib and glyph files, you can script this. Just load a font with e.g. ufoLib2, and delete all lib and glyph lib keys that do not start with public..

Regarding the topic, this needs to be revisited now that we have public.skipExportGlyphs.