Add support for font files #2516
Comments
|
+1 |
Linguist currently defines 'data', 'programming', 'markup', 'prose', or 'nil': https://github.com/github/linguist/blob/master/lib/linguist/languages.yml#L3 I agree none of these are a great fit but it also doesn't feel right to define a |
|
@arfon What about a |
|
And just to clarify - the actual font files aren't currently being classified but you often have some shell/python or other files in your font project too that gets recognised. |
OK thanks for the clarification. Through the
I'm not in love with that idea to be honest but it's definitely not a terrible suggestion 😄. It would be helpful for me to know what you would like to see accomplished here. Is it the ability to discover font files on GitHub, have them accurately rendered/syntax-highlighted on GitHub, contribute to the language bar statistics or all of the above? There's been some prior discussion on SVGs here and here which might be useful for context. |
|
Rendering + syntax highlighting isn't that important as you rarely edit and look at the glyph data "directly" but almost always use a font editor of sorts.
You could easily make the case that fonts and thus font files are mini programs so the programming type could be fitting too. What I'd also like (but that's another issue in it self) is to have categories/tags of sorts...to make it easy to find all font projects regardless of what language/format they are in. |
|
Off the top of my head:
cc @twardoch who may know more |
There are more here, but a lot are legacy: http://fileinfo.com/filetypes/font |
|
@davelab6 wouldn't it be a good idea to discriminate between "source" files (type: programming), and then "binaries" (ttf, otf etc.)? Also not sure if e.g. ufo and sfdir can be recognised as they are technically just folders? |
|
I don’t think it would make much sense to put the multitude of source files that font binaries are built with these days under a common type It all makes it similar to how regular software projects are built, and as with other projects each and every source file should be classified by the particular ‘language’ it is written in, not by the type of target product it happens to be compiled into. That’s because particular people, or for that matter particular font editors, write code with particular languages. It’s only the various target font binaries that, if stored in the repo, could have their type recognised as |
|
I agree with @grzegorzrolek but if Github is unwilling to recognise each item in the table, a single group item for all would be better than nothing :) Github also refuses to add the SIL Open Font License to the license picked dropdown because fonts are now too niche for their scale of operations :( |
|
Well, I don’t think there’s a need to recognise all formats listed, as only a fraction of these are really distinct or meaningful as far as Linguist is concerned. Most of those listed are:
This leaves us with a handful of file types for Linguist to consider, really. It’s MetaFont (.mf), FontForge sources (.sfd and thus .glyph, but these are still more like custom data-containers), and various PostScript-derived formats in their readable form (let’s say .ps’s, if PostScript as such isn’t supported already). I would also add Adobe’s OpenType feature file to the list (commonly .fea), as well as various Apple’s AAT input files (.atif, or the .mif, .jif, .kif family), or the SIL Graphite Description Language (.gdl). That, I think, would be about it for the time being, but I might have missed something. If more font projects would use ‘proper’ build systems with more of those ‘source’ kind of files, maybe it would help these kind of projects be distinct enough to make their sources more interesting to parse and make statistics of. For now, though, it looks like most font-production people either aren’t savvy enough or they just don’t care, and simply dump into a commit whatever they happen to have in their working directory, including duplicated data scattered through different formats, intermediate files, various blobs and binaries… all of which of course does not necessarily make it any more useful or interesting, most often to the contrary. |
|
@grzegorzrolek please keep off topic rants out of this 😄 To me:
|
|
Thanks for the extra information @larsenwork and @grzegorzrolek. I've been struggling to know exactly how to proceed here but your last comment @larsenwork has cleared up some of my thinking. Firstly, Linguist is primarily a (programming) language detection library. Being able to detect the syntax contained within a file is important when trying to render the contents of the file in the browser (i.e. with the correct syntax-highlighting). While we do some rudimentary stuff to identify other types of files e.g. images this information isn't really surfaced anywhere in GitHub.com (i.e. as a browse/discover experience to find 'images'). To your points @larsenwork (in reverse order):
Unfortunately I think this is a non-starter. Linguist works on a file-by-file basis and so we can't do anything smart with a folder, only the (file) contents within.
We actively avoid doing anything with things like binary blobs. Given that they're not human-readable or index-able by our search infrastructure I don't think we can do anything with binary font files here either.
This makes the most sense to me. I'm still most in favour of defining some new Languages for these last few types in
I hear you 😄 - we could mark them as Finally, for completeness, you can currently find font files with searches like this: / cc @github/languages @pchaigno @larsbrinkhoff incase they have strong opinions here |
|
@arfon sounds good
Didn't know this but not really useful though :) |
No, unfortunately not. I meant to write that in my last comment. Perhaps the best option is to go with |
|
Another option is to classify |
|
👍 |
|
This issue has been automatically marked as stale because it has not had activity in a long time. If this issue is still relevant and should remain open, please reply with a short explanation (e.g. "I have checked the code and this issue is still relevant because ___."). Thank you for your contributions. |
|
This issue has been automatically closed because it has not had activity in a long time. Please feel free to reopen it or create a new issue. |
There are many (and popular) open source font projects on GitHub but currently font projects get's classified as shell, python etc. projects as the source files for the fonts aren't recognised.
There are two formats primarily used for open source fonts:
Type: would it be possible to add "font" as a type similar to how e.g. "programming" is a type - if not then I'm unsure which type category they belong to?
The text was updated successfully, but these errors were encountered: