Skip to content
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

Open
alerque opened this issue Jun 22, 2020 · 4 comments
Open

RFC: Choose folder layout for distribution packages #19

alerque opened this issue Jun 22, 2020 · 4 comments
Labels
question Further information is requested

Comments

@alerque
Copy link
Member

alerque commented Jun 22, 2020

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

@alerque alerque added the question Further information is requested label Jun 22, 2020
@alerque
Copy link
Member Author

alerque commented Jun 22, 2020

Here is an example of my suggestions. The distribution file LeagueSpartan-2.202.zip would extract to a structure like this:

LeagueSpartan-2.202
├── static
│  ├── OTF
│  │  ├── LeagueSpartan-Black.otf
│  │  ├── LeagueSpartan-Bold.otf
│  │  ├── LeagueSpartan-Extrabold.otf
│  │  ├── LeagueSpartan-Extralight.otf
│  │  ├── LeagueSpartan-Light.otf
│  │  ├── LeagueSpartan-Medium.otf
│  │  ├── LeagueSpartan-Regular.otf
│  │  └── LeagueSpartan-Semibold.otf
│  ├── TTF
│  │  ├── LeagueSpartan-Black.ttf
│  │  ├── LeagueSpartan-Bold.ttf
│  │  ├── LeagueSpartan-Extrabold.ttf
│  │  ├── LeagueSpartan-Extralight.ttf
│  │  ├── LeagueSpartan-Light.ttf
│  │  ├── LeagueSpartan-Medium.ttf
│  │  ├── LeagueSpartan-Regular.ttf
│  │  └── LeagueSpartan-Semibold.ttf
│  ├── WOFF
│  │  ├── LeagueSpartan-Black.woff
│  │  ├── LeagueSpartan-Bold.woff
│  │  ├── LeagueSpartan-Extrabold.woff
│  │  ├── LeagueSpartan-Extralight.woff
│  │  ├── LeagueSpartan-Light.woff
│  │  ├── LeagueSpartan-Medium.woff
│  │  ├── LeagueSpartan-Regular.woff
│  │  └── LeagueSpartan-Semibold.woff
│  └── WOFF2
│     ├── LeagueSpartan-Black.woff2
│     ├── LeagueSpartan-Bold.woff2
│     ├── LeagueSpartan-Extrabold.woff2
│     ├── LeagueSpartan-Extralight.woff2
│     ├── LeagueSpartan-Light.woff2
│     ├── LeagueSpartan-Medium.woff2
│     ├── LeagueSpartan-Regular.woff2
│     └── LeagueSpartan-Semibold.woff2
└── variable
   ├── OTF
   │  └── LeagueSpartan-VF.otf
   ├── TTF
   │  └── LeagueSpartan-VF.ttf
   ├── WOFF
   │  └── LeagueSpartan-VF.woff
   └── WOFF2
      └── LeagueSpartan-VF.woff2

@alerque
Copy link
Member Author

alerque commented Jun 23, 2020

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 FooBar-1.002.zip we could generate FooBar-1.002-variable-otf.zip, FooBar-1.002-static-ttf.zip, FooBar-1.002-variable-woff2.zip, and so forth. This might save bandwidth and allow some people to cherry narrow in on just what they need at the download level, but I feel like that saved bandwidth might not be worth the cost of confusion of "which file do I download", "where did all the files go", etc.

@alerque
Copy link
Member Author

alerque commented Aug 20, 2020

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

@alerque
Copy link
Member Author

alerque commented Aug 22, 2020

One alternative: Separate packages for every possible version. Looking at you Iosevka. Although Recursive could have had it beat if they'd gone that route.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant