Community guidelines
In the spirit of Wikipedia, these are guidelines and not hard, immovable policies. They are written in an attempt to best summarize the consensus of the FontForge development community, they are not rules. If one of these guidelines prevents you from improving FontForge, ignore it, but don't be reckless, and remember that at least one person thought that they reflected consensus at one time.
The original author of this document was Fredrick Brennan (@ctrlcctrlv), so it may be unintentionally biased towards his understanding of consensus. Feel free to open issues against this document, or be bold and edit it yourself.
New guidelines should be added to the bottom. If a guideline loses consensus and there's no logical alternative thing that should go there now, it should be removed, but guidelines below it should not be renumbered as they will be referred to by number. It might be better to strike guidelines which have fallen out of fashion, like this.
The FontForge project has no Code of Conduct, and is unlikely to ever do. We discussed this in depth in №2765. To summarize our reasons against adopting one:
- CoCs are, rightly or wrongly, seen as not politically neutral;
- a codified CoC is overly bureaucratic;
- many of the words used in CoCs are ill defined (people of different cultures may disagree on what is polite, for example);
- and, for at least the Contributor Covenant, we'd need to change our ill-defined governance structure, which doesn't suit us.
That is not to say that our community is a free-for-all. Community members are expected at all times:
- to be respectful of each other;
- to avoid personal (ad hominem) attacks;
- to avoid engaging in any other "conduct which could reasonably be considered inappropriate in a professional setting";
- to first assume others are acting in good faith (with good intentions);
- and, to be inclusive of developers from all backgrounds.
Our bug tracker has a limited, but important purpose. It is to track bug reports and feature requests. An issue does not need to be closed if a workaround is found unless the workaround is sufficient to solve the issue.
Our tracker is not a forum, it is not a social network, and it is not a place to announce your projects. All of these things should happen at either our user mailing list (fontforge-users@lists.sourceforge.net) or our IRC channel (#fontforge at irc.libera.chat).
We have moved away from issues like №2055 that are just large wish lists; wish lists and observations of use by new users should go on the mailing list now, or be opened as separate issues. Previously our tracker was used as a forum, so some of these might still be open, (if you see one, and can't close it yourself, ask for it to be closed please,) but we don't use it that way anymore.
There are several reasons:
- most importantly, they seemingly never get closed;
- we can't close "sub-issues" from within PRs, and it's hard to refer to them;
- they make it harder to track what needs doing, the primary purpose of a tracker.
The exception is "new release" issues, which are usually pinned. That's because those have a timeframe for closure, and are useful for figuring out what remains in a release. There's also only ever either zero or one open at a time.
If one of these issues is closed, it's nothing personal, and isn't a rejection of your criticisms or requests. Please reopen all of the sub-issues that remain unsolved and relevant as new self-contained issues.
Currently via SourceForge, lists.sourceforge.net:
| List name | Description |
|---|---|
| fontforge-announce | Where new releases are announced. |
| fontforge-devel | For asking development questions, like "what is most needed?" and "how do I make a new window with GDraw?" |
| fontforge-users | For asking questions about using FontForge, sharing your new fonts, et cetera. |
| fontforge-testcases* | Defunct. Should not receive new messages. |
* Test cases should just be posted to the relevant issue on the tracker now instead.
Currently irc.libera.chat #fontforge.
For rapid communication among developers and users. @ctrlcctrlv always idles here, but doesn't always reply quickly. Please don't ask whether you may ask a question, just ask it, and please be ready to wait possibly 12 hours or longer for a reply. It may be wise to email the mailing list if a reply is not forthcoming, and link it in IRC, or mail the list first then link it in IRC.
(Note: The channel was moved from Freenode on 11 June 2021 due to the Andrew Lee incident, which caused most large channels, including #httpd, #ubuntu, and #archlinux to leave, as well as most of Freenode's staff.)
Currently we only "microblog" via Twitter, but this could change; we may consider opening a GNU Social channel and microblogging from both, for example.
As many people use Twitter, it is a good place to keep the community updated on development and happenings in our community. Therefore, we have an official Twitter account, @FontForge. Its primary purpose is announcing new commits, and new serious bugs users should immediately be aware of.
This account isn't any one person's, it's the community's. All developers are welcome to link blog posts they write about FontForge internals or font formats on it, for example.
Users are invited to follow, and to tweet their work at the account, which will almost always be retweeted. (If that doesn't happen, feel free to direct message a reminder to the account.)
The main person who tweets on this account is Fredrick Brennan (@ctrlcctrlv), but more than one developer has the password.
See also: CONTRIBUTING.md
While we value all bug reports, we advise against filing most types of security issues. The exception would be, if somehow, for example, something done outside of FontForge, e.g. in Firefox, can cause arbitrary code execution in FontForge, and this is somehow FontForge's fault and not the OS's or Firefox's. (In this case, you should contact Frank Trampe privately first, and if he does not reply in a reasonable timeframe, other recent committers.)
Untrusted input issues, in particular, are advised against. If you insist, such an issue should be tagged as �unțrușted inꝑüt�.
FontForge SHOULD NOT, EVER receive untrusted input. Most users only use it to edit their own fonts and sometimes popular open-source fonts. Even if we fix all the issues findable with automated tools, there are many, many memory bugs in FontForge.
Some websites might be using it that way, they are using it wrong and should either (a) stop, or (b) run it in a sandbox, and recreate the sandbox with each invocation.
As Skef Iterum explained:
The primary three ways that software systems present security vulnerabilities, given problems like those reported in those issues (buffer overflows, wild pointers, etc.) are:
- They take "untrusted" inputs of one sort or another, usually over a network. Those inputs can be carefully constructed to exploit the wild pointer or buffer overflow.
- The program is itself available over the network in some way, like a mail transport agent, and nefarious people can interact with it directly.
- The program executes with "elevated privileges", and can be manipulated by a user without those privileges in order to gain them.
Without some connection like this a segfault is "just a segfault" -- it doesn't present a security risk. A user gains nothing by tricking FontForge (for example) into executing carefully constructed instructions because FontForge doesn't run with elevated privileges. And FontForge does not present any network interfaces (at least since the collaboration system was removed).
So any viable vulnerabilities would have to be in the form of a carefully constructed font file, which would exploit a buffer overflow or wild pointer to do something when loaded. This scenario is possible but very improbable. The main problem facing the hacker is that FontForge users tend to either develop their own fonts or open specific existing fonts for reasons very specific to them. The other problem is that FontForge is cross-platform and the file would have to be constructed to work on the specific OS of the targeted user.
It is not a goal of the project to assure users that they can open any file and nothing bad will happen.
FontForge includes two scripting capabilities: first, via a legacy scripting language created by George Williams, FontForge's original author, called internally ff. The other is Python 3.
We recommend no new scripts in the legacy language be written. FontForge's Python API is always to be used for new scripts.
It is allowed, as of at least PR №4154, to implement a feature in the Python API and not backport it to the legacy language.
There are no plans to remove the legacy language, and we of course still accept pull requests fixing issues in it and bringing it up to parity with Python. However, a request to add a feature to it that's not in Python must add it to Python as well to be accepted.
Everything possible in the GUI, within reason, should also be possible in Python, so it's also usually not acceptable to add a feature only to the GUI.
How FontForge (PfaEdit) looked as of 2 November 2001
FontForge is old. It began as PfaEdit on 7 November 2000. Some parts of the codebase are unchanged from that time. Breaking changes which could affect users, therefore, need more consensus than in other projects. The longer something has been a certain way, the more consensus we need. That's not to say that subsequent versions of FontForge must produce binary-equal fonts, but if we're going to remove a feature, we need a very good reason to and a lot of advance notice.
It is our hope that if people are still around, and those people want to edit fonts on computers, they will be using FontForge in 2040, 2100, et cetera. We've made it the first 20 years!
It is tempting to add features to the Python API and nowhere else, but this should not be done. As established in PR №4320, the GUI is not second class, and where it makes sense to do so, it should have all of the features of the Python API.
It is not a bug in FontForge if an external program, free or proprietary, has trouble with some SFD file FontForge itself doesn't have trouble with. №4339, therefore, is not generally fixable other than by improving the error message.
When we make changes to the SFD format, we only think about ourselves, and not external programs which are, at their own risk, using our internal format.
If you need some SFD-only data, the right way to get it is through implementing, or making a new, UFO format extension.
CID-keyed fonts are a legacy font format, including so-called "SFNT-wrapped" CID-keyed fonts. Of course, we still will merge code that fixes them, but making new ones (especially) is not a development priority.
To use a CID-keyed font as the base of a new font, you should flatten it first. See №3955 for more information.