Skip to content

RFC: Choose folder layout for distribution packages #19

Open
@alerque

Description

@alerque

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:

  1. 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 of FooBar-1.002. I'll defend this the merits of this vigorously, but unless challenged I'll just assume this.

  2. 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.)

  3. 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:

    TTF/FooBar-Thin.ttf
    TTF/FooBar-Black.ttf
    ...
    TTF/FooBar-VF[weight].ttf
    

    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/... not TTF/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 level OTF folder might be disappointed to find only a static entry and no variable (since it's only in the TTF version).

Metadata

Metadata

Assignees

No one assigned

    Labels

    questionFurther information is requested

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions