What is a font design public API? #361

New Issue

2026-02-17T11:55:56-06:00

GiteaMirror commented

2026-02-17 11:55:56 -06:00

Originally created by @mina-shafei on GitHub (Jan 22, 2019).

How can I use semver for my font design project? What public API documentation could I use?

Originally created by @mina-shafei on GitHub (Jan 22, 2019). How can I use semver for my font design project? What public API documentation could I use?

GiteaMirror closed this issue

2026-02-17 11:55:56 -06:00

GiteaMirror commented

2026-02-17 11:55:58 -06:00

@klehelley commented on GitHub (Jan 22, 2019):

That is a difficult question to answer. The public API is there to describe the contract between the project you are working on and its consumers (I use a vague term here but these are other pieces of software if we are to follow the spirit of the specification). So to see how SemVer might fit your needs, it would I think be good to answer these questions first:

What are the consumers of your font? Pieces of software, people ?
To these consumers, what kind of expected changes would be:
- A minor, "backward-compatible" tweak? (near-indistinguishable change in the curve of a few glyphs, etc.)
- A new "feature"? (additional glyphs for codepoint that were not covered by the font before, noticeable changes with no negative impact in the legibility of the font maybe, etc.)
- A breaking change? (removal of glyphs, big modifications in shapes and sizes, etc.)

Once you have clear answers, that you are happy with, then SemVer will likely be a good fit for your project. For a project such as your it may feel a little bit fuzzy, with gray areas or potential overlap between. In that case it is up to you to decide if you are comfortable with it, or if you feel it would be better to use a different versioning strategy.

@klehelley commented on GitHub (Jan 22, 2019): That is a difficult question to answer. The public API is there to describe the contract between the project you are working on and its consumers (I use a vague term here but these are other pieces of software if we are to follow the spirit of the specification). So to see how SemVer might fit your needs, it would I think be good to answer these questions first: * What are the consumers of your font? Pieces of software, people ? * To these consumers, what kind of expected changes would be: * A minor, "backward-compatible" tweak? (near-indistinguishable change in the curve of a few glyphs, etc.) * A new "feature"? (additional glyphs for codepoint that were not covered by the font before, noticeable changes with no negative impact in the legibility of the font maybe, etc.) * A breaking change? (removal of glyphs, big modifications in shapes and sizes, etc.) Once you have clear answers, that you are happy with, then SemVer will likely be a good fit for your project. For a project such as your it may feel a little bit fuzzy, with gray areas or potential overlap between. In that case it is up to you to decide if you are comfortable with it, or if you feel it would be better to use a different versioning strategy.

GiteaMirror commented

2026-02-17 11:55:59 -06:00

@mina-shafei commented on GitHub (Jan 23, 2019):

So I can wright a simple public API (for example in text format) and include it in project? The questions you mentioned are well described main issues of font release that I want to cover all. I think contents of such a simple public API could be the answers to these questions. Am I right?

@mina-shafei commented on GitHub (Jan 23, 2019): So I can wright a simple public API (for example in text format) and include it in project? The questions you mentioned are well described main issues of font release that I want to cover all. I think contents of such a simple public API could be the answers to these questions. Am I right?

GiteaMirror commented

2026-02-17 11:56:00 -06:00

@klehelley commented on GitHub (Jan 24, 2019):

Since the rules described in SemVer are not specific enough for your use case, such a documentation is not only useful but I think necessary (as another font designer might not exactly have the same interpretation as yours). A simple text file (maybe using a format like Markdown or Asciidoc that would make it easy to export if needed) in the project is a pretty good choice IMO.

@klehelley commented on GitHub (Jan 24, 2019): Since the rules described in SemVer are not specific enough for your use case, such a documentation is not only useful but I think necessary (as another font designer might not exactly have the same interpretation as yours). A simple text file (maybe using a format like Markdown or Asciidoc that would make it easy to export if needed) in the project is a pretty good choice IMO.

GiteaMirror commented

2026-02-17 11:56:01 -06:00

@grv87 commented on GitHub (Feb 3, 2019):

See my comments on art in general and specifically on fonts: https://github.com/semver/semver/issues/468#issuecomment-431406734 and https://github.com/semver/semver/issues/468#issuecomment-431407832.

In my opinion, current edition of semver is not applicable to art, including fonts.
Versions of artistic objects should have two parts, without major version.

@grv87 commented on GitHub (Feb 3, 2019): See my comments on art in general and specifically on fonts: https://github.com/semver/semver/issues/468#issuecomment-431406734 and https://github.com/semver/semver/issues/468#issuecomment-431407832. In my opinion, current edition of semver is not applicable to art, including fonts. Versions of artistic objects should have two parts, without major version.

GiteaMirror commented

2026-02-17 11:56:02 -06:00

@steveklabnik commented on GitHub (Feb 11, 2019):

This repository is used for developing the specification itself, and so I'm giving it a close, as it's not really what the spec is about directly. Thank you!

@steveklabnik commented on GitHub (Feb 11, 2019): This repository is used for developing the specification itself, and so I'm giving it a close, as it's not really what the spec is about directly. Thank you!