On Wed, Aug 12, 2026 at 5:47 PM Bastian Germann <[email protected]> wrote:
> Google does not operate under DFSG, so it is okay for them to treat TTF > as source even when there is an unpublished (other format) source. An OpenType glyph table (glf, CFF, or CFF2) is fine as source for glyph contours, because it is simple Bezier geometry. This is true not just for for Google Fonts, but for other projects — including the TeX derivative font project already mentioned. There is not a "human readable" representation of Bezier curves; they are (x,y) point sequences. You can see the same thing in SFD, Glyphs, UFO, or any of the font-editor file formats that are not, themselves, somehow obfuscated or encrypted. There have been encrypted file formats in the past, such as .EOT, for which that would not be true. This is not that. One can also compare how the Bezier curves are stored in OpenType files to how they are stored in other formats, like SVG. That fact, that the curve geometry is already in the form needed to read and modify it, is why OpenType fonts are acceptable as source. _Not_ because we can cite examples of people already doing it(*), but _because_ that's what the actual file contents are. The proof that it works is that all font editors can open .otf/.tt/.otc/.ttc files without issue or ambiguity. They use the contour geometry, exactly as FreeType or whichever other renderer is involved. There isn't a "lost" representation of which the glyph table representation is a mere bad copy. > > The manual clearly states that the source is in > VFB format. > It's conceptually possible that the VFB files contained material that did not make it into the final .ttf or .otf, such as un-exported layers. But those, by definition, are not required to generate the resulting file. And also by definition, there is no way of knowing if they existed by examining the final output. They are akin to comments, which could prove helpful and interesting to later developers if they exist, and are always nicer to have than to not have, but they are not necessary to generate bit-for-bit identical output files. The same is true for overlaps, if there was a "remove overlaps" stage as part of the build process. If there were any that were removed at export, then by definition they are not required to reproduce the output. That, too, is speculative; there may not have been any. Finding some might prove a convenience to future designers, but a convenience only. > This was handled very sloppily for some time unfortunately. Conjecturing about what other people did in the past is not a useful strategy and does not solve any problems. Please do not point to other packages where similar things are the case. > I'll do as I wish. Nate * – Although that is demonstrably the case and has been for many years. -- nathan.p.willis [email protected] <http://identi.ca/n8>
