-
-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Choose folder layout for distribution packages #19
Comments
Here is an example of my suggestions. The distribution file
|
This whole discussion assumes what we want is a single distribution archive with all available formats it it. It would just as easily be possible to break it up into separate archives by type or format if that's somehow desirable. Instead of just |
Another division I hadn't considered is how to name & distribute hinted vs unhinted fonts for the same project. Some apparently do both (e.g. Castoro). |
Anybody with opinions please chime in!
I'm working on the
make dist
function for fontship and thinking about what folder layout to standardize on. Note this is for what goes in the final ZIP (or otherwise compressed archive) that is intended for font end user distribution — not the Git repository layout.I maintain hundreds of distro packages for various free fonts and honestly the situation I've observed across a variety of sources is pretty chaotic. Even across fonts from The League of Movable Type there are 3 or 4 basic layouts plus some minor variants! Some ZIPs have loose font files at the top level, some have everything in a project name folder. Some have fonts split by format, some group multiple formats by usage (e.g. EOT and WOFF under 'web'), and so forth.
I think the questions we need to answer are:
Do we include a top level folder with the font family name? and a version string?
My suggestion is emphatically YES on this question. A downloaded ZIP file for release 1.002 of font family Foo Bar should be
FooBar-1.002.zip
and extract to a top level directory ofFooBar-1.002
. I'll defend this the merits of this vigorously, but unless challenged I'll just assume this.Should files be grouped, and if so should the main grouping be by format or usage?
a. If yes, should they be capitalized?
My vote is for yes, by format, and capitalized (i.e. ditch things like "web/" and just have "WOFF/" etc.)
Where should variable fonts fit into this? Should they be stuffed in the per format folder (i.e. static and variable TTFs in
TTF/
or separated? If separated should all the formats be lumped together or further split? Should static fonts have a matching structure? Should the static/variable dirs be top level or under formats?I'm not so sure on this one. My first idea was to just keep them alongside statics by format:
The caveat is that it becomes slightly harder for packagers who package these separately because simple glob expansions like
install -Dm644 -t "/usr/share/fonts/TTF/" TTF/*.ttf
become more complicated needing to separate static from variable files.If we do split them, I vote the split be top-level nod mid-level (i.e.
variable/TTF/...
notTTF/variable/...
) and that static instances be split into a matching folder so everything is at the same level and we emphasize the nature of the files (i.e.static/TTF/FooBar-*.ttf
). This should give end users the best shot at both finding what they want out of the package and understanding what is there to pick from. The slight downside is that it would probably be slightly easier on packagers to script installations with the mid-level layout, but since glob expressions could be written either way prioritizing the end user discovery seems to make the most sense. My fear with mid-level layout would be that someone who went straight for the first levelOTF
folder might be disappointed to find only astatic
entry and novariable
(since it's only in the TTF version).The text was updated successfully, but these errors were encountered: