Index to resources in repository for Source Code Pro (SCP) This document’s purpose is to provide a description of the file types and folder structure found in this repository and the tools used to generate and process them. This index also lays out the workflow from making and editing the sources to compiling working fonts. A. Key to File Types: 1. Files for type design The vast majority of files in this repository belong to the Unified Font Object (ufo) storage format, which is an open format and largely XML based. This document will not describe UFO-related files that are found in the UFO file packages in this repository. For information about these file types, please consult the official documentation of the UFO specification, that can be found online at: http://unifiedfontobject.org OR https://github.com/unified-font-object/ufo-spec 1.1 Master UFO files A master, in the context of typeface design, is a designed reference point that defines the bounds of the type design space. Master UFO files house all the information needed to compile a working font in a format that is easily read by font editors and humans alike. However, this information is stored using XML syntax, whereas the tools used to compile fonts for this project use the feature file (.fea) syntax (see §3 for more information). Perhaps most imporatantly, the masters define the paramaters of a typeface family. Each master is a separate design that relates to the others. Basically this means that the the masters must be compatible with each other in certain ways: masters must (except for the case of intermediate masters) contain the same number of glyphs, each of which must be point-compatible with the corresponding glyph outlines in each design master. Additionally, These parameters include designed glyph outlines at the extremes of the design space, sometimes with intermediate poles that help with more fine-grained control of the design space. Glyph outlines must be point-compatible with all other masters in order to enable the interpolation of intermediate instances within the design space that the masters define. Master UFO files are what the designer modifies directly using a font editor that has UFO import / export support. Master UFO files will also be the inputs for tools that will ap- ply kerning and anchor information to the design. The master UFO files live in the directories named 'RomanMasters' and 'ItalicMasters'. These have the family name, eg. 'SourceCodePro', in the UFO file name, to which is appended '-It' for italic masters, and '_d' where d is a digit that corresponds to the the master’s index number. [ 1.1 UFO files in this repository a. Default UFO data files: The UFO files in this repository follow the structure outlined in the documentation referenced above, however you will also find some: b. Custom UFO data files: b.1 com.adobe.type.processedHashMap, in 'data' folder This file stores a hash of the outlines of all glyphs in the default layer (glyphs folder). This is for the purpose of tracking which modified glyphs need to be processed by checkOutlines (FDK) and autohint (FDK). 1.2 UFO types in this repository ] 2. Files for interpolation 2.1 Design space file (.designspace) This is a MutatorMath file in XML format that maps the relationships between the design master UFOs and the instances that will be generated by those using the makeInstancesUFO (FDK) tool. The designspace file can be output by Superpolator (3rd party, proprietary tool), or crafted and edited by any text editor. 2.2 Superpolator file (.sp3) This is a Superpolator file that maps the relationships between the design masters to define the design space and also plots the postions of intermediate masters to be interpolated. As stated above, this information can be exported to a .designspace file. 3. Files for font compilation The entirety of this project leverages a workflow that relies on the Adobe Font Development Kit for OpenType (FDK) to compile the final font software. The FDK is a set of open source tools developed and maintained by Adobe for the purpose of developing, compiling, and processing OpenType (OT) fonts, specifically for Compact Font Format (CFF) fonts, but with some TrueType (TTF) font support as well. Documentation on the FDK can be found on Adobe’s website: http://www.adobe.com/devnet/opentype/afdko.html The open source version of the toolkit can be found on GitHub: https://github.com/adobe-type-tools/afdko Many of the files in this repository are input files used by the makeotf tool to compile font software. A full description of these input files can be found as part of the FDK distribution package on GitHub: https://github.com/adobe-type-tools/afdko/blob/master/FDK/Technical%20Documentation/MakeOTFUserGuide.pdf However, a brief description of each of these files will follow. 3.1 Family-wide files Files that contain information that applies to the entire type family (or sub-family) are typically stored at the top-level directory. a. family.fea This file contains the OT shaping rules that apply to all fonts in the family. Because there is currently a discrepancy in the glyph repritoire of the upright and italic fonts, there is also an italics.fea file that overrides the family.fea file. b. FontMenuNameDB A text file which stores font naming information. c. GlyphOrderAndAliasDB A text file which stores relationships between glyph names used in production and glyph names to be used int he final font. In general, the production names follow those that can be found in the Adobe Glyp Dictionary (AGD.txt), which is part of the FDK distribution. Final names follow a strict set of rules laid out by the Adobe Glyph List Specification: https://github.com/adobe-type-tools/agl-specification This file is also used to set the order of glyphs in the final font software. d. tables.fea For this project, this file only houses some of the table information that is shared across all fonts in the family and the table information. However, this file can also be used to house other table information as needed. e. widthsAdjust.fea This file is specific to this project. Because SCP is a monospace font, some interpreters expect strict adherance to a common set width for each character, including those which are defined by Unicode to be non-spacing (have 0 width). To satisfy both these requirements, the combining diacritics are set on the full width and then OT positioning features adjust the width of these char- acters so that they effectively become non-spacing. 3.2 Font-specific files Files that contain information that applies to a specific font style. These can be found in the directories that correspond to the font style names, eg. 'Regular' for the Regular style. a. Instance UFO files An instance, in the context of font development, is a input file that is automatically interpolated from within the design space of the master files. Instance UFOs are generated by the makeInstancesUFO (FDK) tool, which will also flatten (remove overlaps) and add hinting instructions to all glyphs. Instance UFO files will also contain interpolated kerning and anchor infomation if present in the master UFO files. The instance UFO files typically are simply named 'font.ufo'. In additon to the default UFO structure, these instance UFOs also inlcude a file named 'com.adobe.type.processedHashMap', in the 'data' folder. This file stores a hash of the outlines of all glyphs in the default layer (glyphs folder). This is for the pur- pose of tracking which modified glyphs need to be processed by checkOutlines (FDK) and autohint (FDK). 4. Files for storage of font meta information These files, although not strictly necessary, are helpful auxilliary files that can aid in the type design / font development process. 4.1 Masters meta information files a. derivedchars_0 Stores information on the relationships of components for composite glyphs. b. anchors_0 Houses anchor information that is used in generating the various mark features files that are used by the FDK. 4.2 Instances meta information files a. derivedchars_TT Similar to the other derivedchars files previously described, these files are used to regenerate composite glyphs in the font.ttf. b. tthints This is a storage file for TT hinting information. c. ppms Another file storing TT hinting parameters. 5. Build scripts & misc. These files do something: 5.1 build.sh DESCRIPTION GOES HERE. 5.2 package.json DESCRIPTION GOES HERE. 5.3 .gitignore Self-explanatory. 6. Docmentation These are human-readable files and should be self-explanatory: 6.1 LICENSE.txt 6.2 ReadMe.html 6.3 README.md 6.4 relnotes.txt 6.5 Roadmap.txt 6.6 SourceCodeProReadMe.html B. Key to Folder Structure*: SoucrceCodePro └ RomanMasters └ SourceCodePro_0.ufo ├ metainfo.plist ├ lib.plist ├ fontinfo.plist ├ features.fea ├ groups.plist └ glyphs ├ contents.plist ├ _notdef.glif ├ a.glif ├ … ├ … ├ SourceCodePro.designspace ├ SourceCodePro.sp3 ├ anchors_0 ├ anchors_2 ├ derivedchars_0 └ derivedchars_2 └ ItalicMasters └ do. └ Roman └ Regular └ font.ufo ├ metainfo.plist ├ lib.plist ├ fontinfo.plist ├ groups.plist ├ layercontents.plist └ glyphs ├ contents.plist ├ _notdef.glif ├ a.glif ├ … └ glyphs.com.adobe.type.processedGlyphs └ do. └ data └ com.adobe.type.processedHashMap ├ features ├ fontinfo ├ markclasses.fea ├ mark.fea ├ mkmk.fea ├ font.ttf ├ derivedchars_TT ├ tthints └ ppms ├ … └ Italic └ do. ├ family.fea ├ FontMenuNameDB ├ GlyphOrderAndAliasDB ├ tables.fea ├ widthsAdjust.fea ├ build.sh ├ package.json ├ .gitignore ├ LICENSE.txt ├ ReadMe.html ├ README.md ├ relnotes.txt ├ Roadmap.txt ├ SourceCodeProReadMe.html └ index_to_resources.txt * This structure breaks from alphabetical ordering and uses logical order where it would help to simplify the the representation of the file structure. The fol- lowing conventions are also used to this end: do. to connote that the contents are structurally the same as the previous item at the same level (if having dif- ferent file names), … to connote an ellision of files of the same type as the previous item at the same level. C. Workflow