The Google Fonts API uses these files in combination with [pyftsubset](https://github.com/behdad/fonttools/blob/master/Lib/fontTools/subset.py) to generate script subsets from the full `.ttf` files in this repository.
There are "legacy" encodings, the files directly in this directory and the newer "2016" encodings contained in the `GF 2016 Glyph Sets` subdirectory.
The latter directory contains itself a [`README.md`]('GF 2016 Glyph Sets/README.md').
# The "Namelist" file format
The extension of a Namelist file is "`.nam`".
Namelist files are encoded in UTF-8.
### *legacy* subsetting
* all encodings with the exception of `khmer` include `latin_unique-glyphs.nam`
* all *extended* encodings with filenames like`{lang}-ext_unique-glyphs.nam` also include `{lang}_unique-glyphs.nam`
This is implemented in the `CodepointFiles` function of [google_fonts.py](../util/google_fonts.py)
### *2016* subsetting
The [`README.md`]('GF 2016 Glyph Sets/README.md') describes mostly how each of the Namelist files depend on each other, however, this is not implemented anywhere yet. To make the system more flexible and self describing I suggest using [header includes](#header).
## Codepoint format
A line that starts with `0x` and then have 4 **uppercase** hex digits; what follows is an arbitrary description to the end of the line.
A line that starts with at least six spaces describes a glyph that has no Unicode and will usually be accessible via OpenType GSUB. These glyphs are used to ensure the fonts contain certain OpenType features.
The description is a human readable glyph name that can be used in the authoring application (targeted at Glyphs) to create and process the glyph properly.
Example:
```
aacute.sc
abreve.sc
abreveacute.sc
abrevedotbelow.sc
```
## <a name="header"></a> Header (proposal)
To make the Namelist format more self contained I suggest a file header.
The Namelist header is made of all consecutive comment lines at the beginning of the file. The first non-comment line ends the header.
Specially crafted comment lines, "header data", define the meta data of the file. Other comments are just that, comments.
A header data line begins with "#$" then is followed by a keyword and then followed by the arguments for the keyword.
The keyword is separated from its arguments by one or more space characters.
The keywords, the semantics of a keyword and the syntax of the arguments of a keyword should be documented here.
Format for header data:
```
#$ {keyword} {arguments}
```
### Keyword `#$ include {namfile}`
The `include` keyword can be used zero or more times. Order of appearance should have no effect on the resulting set and thus be not important.
It specifies the namfiles on which the current namfile depends. The file plus all of its includes together define the complete char-set.
Includes are loaded recursively, meaning that the includes of an included files must also be loaded.
E.g. a 2016 a "pro" encoding would include its "plus" encoding and the latter would include its "base" encoding. The Pro charset then is the union of pro, plus and base.
Loops in the includes are not followed; the final result as a `set` wouldn't have a different value whether the same file is included once or many times.
`{namfile}` is a file path to a namfile relative to the path of the file that contains the include statement.
### Possible Keywords
*`author {name}` (zero or more) since we can already find `# Created by` comments in the 2016 namfiles we could as well just institutionalize it.
*`label {name}` A human readable name for the file, to be used in user interfaces. Could also have a further `{locale}` argument for internationalization.
The `[wgl-latin.enc]` file can be used by [Fontlab Studio 5](http://www.fontlab.com), and represented Microsoft's [Windows Glyph List 4](https://en.wikipedia.org/wiki/Windows_Glyph_List_4) glyph set.
