Why not contribute to the DejaVu project?

[wasamasa]

This GIF shows both DejaVu Sans Mono and Hack, the frame with the red square denotes Hack. Given the few differences (i and 0 are different, spacing of underscores and parentheses is off, hinting is slightly different) I can't help but wonder why I should go for this font instead of DejaVu Sans Mono.

Did you consider contributing the extensions to the original DejaVu project instead? It may not be as much of a chance to gain notoriety on Github and news websites, but would help more people in the long run.

[alerque]

I don't know what the author's reasons were, but this doesn't make any sense to me. The DejaVu project is a whole family of fonts designed for a broad range of contexts. As such it has to weigh a lot of considerations in the balance where a specialty font can shift to meet the needs of one specific context. Hack is designed for source code. This is a rather different thing than a general purpose monospace font, much less one that has to keep within the visual family of a matching Sans and a Serif font as well. In fact a lot of the changes to Hack are mixing and matching serif styles and spacing that would make it inconsistent as part of the DejaVu family but give it a leg up for the specific needs of source code. Others are the inclusion of features and glyphs not normally included (e.g. powerline) and the adjustment of metrics to fit source code usage patterns that might break other things (and there is a lot more to notice than what appears in your gif!). These things would not be easy to retrofit into the DejaVu project and compromises would have to be made, not to mention that it would take a lot of time. If somebody sees value in that and the changes make are of interest to the DejaVu project I'm sure they can be back-ported.

[Earnestly]

For one, a "monospace" typeface has no actual programmatic property inside the outline, it's merely a design choice to keep the advance of each glyph constant. In fact this is how the fontconfig library classifies what a monospace font is.

This misunderstanding alone has lead to a great deal of confusion about how alignment should work when modern font stacks use a pool of glyphs to find replacement glyphs if the current font lacks them.

The argument that this is designed for source code has some weight but does not apply as DejVu Sans Mono already distinguishes potentially conflicting glyph shapes (il1 O0 S5, and so on).

Given that the goal of the DejVu family is to provide a wider range of characters I fail to find any reason that the author could not have simply contributed to DejaVu instead of creating this cynical fork.

The changes are also detrimental for both source code use and aesthetics. The change to i results in breaking the DNA of the typeface design and the slashed zero could simply be included as an outline feature flag as some people don't wish to confuse 0 with Ø.

The spacing added to the parentheses also make it less clear whether a space has been placed between them, () vs. ( ).

The only improvement this font has made imo is narrowing the underscore.

It's also fairly distasteful that behind all the flashy web design and media attention only is it buried in the small text that it might have anything to even do with DejaVu while it is the first sentence of the DejaVu website that it is based on Vera.

[manuel-uberti]

@Earnestly thanks for the links and the clarifications.

I know little to nothing about fonts and just judge them about how pleasant they look to my eyes, however these insights are really interesting.

[Earnestly]

Typefaces are surprisingly complex beasts but if you wish to learn more about them then see what is considered the "Bible of Outline Hinting": http://www.rastertragedy.com/ and this document by Behdad. They both discuss more of the challenges of rendering typefaces on a digital medium than going into design choices.

[alerque]

@Earnestly Honestly what you just wrote is another big reason I see for this being a separate font face. You just listed a whole pile of objections to exactly the changes that were made that make Hack distinctive, and in my view better. Its only natural that you and a lot of other folks will prefer to keep DejaVu the way it is in most regards. There is nothing wrong with that. But it is those very opinions about what changes are for the better that necessitate letting you keep using the font the way you like it while those of us that did not like it can make all the changes we like off in another space. I think it's pretty obvious from your own criticism of design choices that many of the changes would not be well received by DejaVu users. That's okay. If you do see parts you like they can be ported to improve DejaVu as well. In the mean time I should point out that on hearing about Hack and looking it up learning that it was based on the Vera family was one of the first things I learned. It's a top level heading on the site and mentioned prominently in the source.

A typeface in the Bitstream Vera lineage

Hack has deep roots in the libre, open source typeface community and includes the contributions of the Bitstream Vera & DejaVu projects.

The face has been re-designed with an expanded glyph set, modifications of the original glyph shapes, and meticulous attention to metrics.

Additionally from discussions I've read the author would have even included that heritage in the name if licensing had allowed.

[Earnestly]

I would not call a small paragraph half way down a page as "prominent". What is written is only included because the license requires it.

You provide lots of hand-waving and even further unsubstantiated claims about others preferences (I don't even use DejaVu). This is nothing but a cynical fork under the umbrella of an equally useless/pretentious website: http://sourcefoundry.org/ where the only typeface they have is plagiarism. (Oh right, it's open source so this is fine.)

Edit: I don't even see any attribution to the Arev Fonts which provided many of the Greek and Russian glyphs for DejaVu. http://dejavu-fonts.org/wiki/License

[duud]

Any confusion about the roots of this work should be eliminated. Statements which hinder new ideas or hinder the modification of old ideas should be ignored.

[alphapapa]

@Earnestly said:

I don't even use DejaVu

Sir, who are you, and why are you here?

[chrissimpkins]

Here is the long form of the Hack story from concept to the present. It is intended to dispel some untruths, address the concerns that were raised in this thread, and provide a factual basis to continue your conversation/vent your concerns as you so choose.

I have absolutely no background in type design, or design at all for that matter. I do develop in text editors using monospaced typefaces and Bitstream Vera Sans Mono has been my font of choice for years. About a year ago, I took screenshots of 20 - 30 monospaced typefaces with the intent to create a site that developers can use to view differences in the typefaces that are in common use for source code. The directory of images sat on my desktop for months and then became a reality earlier this year as Codeface. This repository generated interest among developers and it became apparent from the feedback that I received through the project that type design preferences diverge widely among developers. There are staunch supporters of most typefaces out there and those opinions are honed through years of face time with the typeface in their editors. The one unifying theme that did emerge is that type is important to developers, and rightly so. While type design has a rich history in the computer science/development community (dating back to at least Donald Knuth’s early contributions to his own TeX typesetting system as far as I can tell), it seems to me that it remains a relatively underappreciated and underdeveloped area of the source code development experience. I found this to be somewhat remarkable given that we stare at this embodiment of our source code every day. We have hundreds of text editors to choose from and drive the developers of these products to address our every whim in order to optimize the development experience. The same occurs with nearly every other element along the source code development chain. But not type. For some reason, there are very few faces that were designed with source code on the screen in mind despite the fact that developers arguably spend more time with type on the screen than the vast majority of other occupations/pursuits/hobbies out there. Just because a face bears the monospaced categorization (as was rightly noted above), does not mean that it is optimized for source code and the fact that its use has been in place for extended periods of time does not mean that there is not room for improvement.

I dove into some education about type history and type design. This began with a read of Robert Bringhurst’s Elements of Typographic Style. If you have any interest in type, this is a fantastic read. As it so happens, there is a rich history surrounding type design in general that I found very intriguing. With this introduction, I began to study hundreds of sans serif faces used in and outside of development settings, including all of the monospaced (partially serifed…) faces that we included in the Codeface repository. I evaluated the glyphs that are used for street signs because they face a similar problem of legibility under poor conditions (street signs face bad weather, type on the screen faces the challenges of the artificial manipulation of the actual design that is required to display the face within the confines of the pixel grid and the small glyph sizes favored by many developers in order to allow for more code on the screen). Many of the design concepts used to address these problems overlap between these two realms (e.g. large x-height, wide apertures, open counters).

It became clear that it is somewhat difficult to make monospaced typeface glyphs, that largely lack serifs, look dramatically different and remain appealing for use in development. The monospaced spacing forces you to use a strategy to bridge the empty space for narrow characters in order to achieve some semblance of a visually appealing rhythm in the design. Without this, monospaced type has a disrupted widely spaced/narrowly spaced character discord that does not appeal to most. A great example is the lowercase i. Many monospaced faces use the top and bottom serifed typewriter style i. Source Code Pro elected to go with a different approach that includes no bottom serif but a larger than typical upper serif. In source code where the commonly used if blocks are generally offset from other text and quite apparent in code, this single character change lends a different feel to the type. Moreso, I would argue, than the same character change would in standard text. You can change the x-height, modify the curves, adjust the weights, round or square the points, and make slight realignments of the strokes but an H looks like an H looks like an H. Most of what you see on the screen, however, is empty space and this is part of the type design as well. It can be modified to enhance or detract from the legibility of the surrounding glyphs and lend a very different feel to the face.

Hack began as an experiment for my own use. I was using Bitstream Vera Sans Mono at the time, loaded it into a font editor, and used the character set as a base for my initial modifications. I don’t recall the first change that I made but one of the earliest changes was to the counter on the zero. The zero holds a special place in the hearts of developers and there is division between the circle/dot fill camps and the slash camps. When I landed on that oval fill it brought back memories of old bitmap typefaces and it stuck. This was different. I built a copy of the font, opened up several source examples in an editor, and realized that I liked the style of the new zero better than I liked the original. The curved tail on the lowercase i was another style change and it came a bit later. It was intended to soften the face compared with the typewriter style lowercase i’s that are out there. I disagree that this departs from the DNA of the typeface as suggested above. It follows the curves in the lowercase l and t, and mirrors the curve of the lowercase j. I changed all of the points over alphabetic characters to rounded squares with the same design intent. These changes seemed to remove the harsh squared lines of the perpendicular serifs and square points. With these early style changes, I started to review the fonts across a broad range of source with a goal to optimize it in that medium. Development took place largely in C, Python, Ruby, JavaScript, PHP, shell scripts, HTML, and CSS. This led to taller left and right brackets to better surround and set off the text contents, an extension of the middle stroke on the left and right curly braces to make these more apparent representations of code block contents in C, JavaScript, and CSS. Punctuation points were rounded (from squares) and most received increased weight to better delineate these glyphs from the alphabetic glyphs because of their importance in source code. Exclamation points in particular tend to become anemic at small text sizes used in source. The exclamation point in this face is beefy and apparent. I gave it a semi-bold weight in the regular set and tapered the stem. “Not” is important to see in your code. The parentheses as you noticed do include increased side bearings on the side adjacent to contained alphabetic characters. This was an intentional design decision that was meant to enhance legibility of the text contents inside the parentheses and support the relationship between the left hand parenthesis and function/class names in these definitions. I increased the side bearings on the side of alphabetic characters for the semicolon as well because this is commonly used as a line ender. I feel that the increased weight of the glyph, change to a circular point, and additional spacing helps it to stand out. Around this time I released the font on Codeface and some developers began to use it and then provide recommendations for further improvements. It so happened that one of those developers was interested in seeing Greek glyphs in the set. Given that DejaVu Sans Mono is an extension of the original Bitstream Vera Mono character set, this was a natural choice. I anticipated the need for other character sets and merged Cyrillic, Georgian, and Armenian glyphs along with a number of non-alphabetic glyphs. This was a big endeavor and required an enormous amount of work over a period of a couple of months in order to achieve a release version that was ready for general use. I adjusted every curve on every glyph across all four sets, changed diacritic marks to rounded points rather than squares, changed their centering / vertical orientation, and implemented the changes in the i from the original set along with a handful of other changes that developed along the way. These included angled terminals on glyphs like the lowercase t, a curved tail on the lowercase a, and tapered stems on glyphs that include the lowercase d, g, m, n, p, q, r, and u. These occurred across all glyphs that contained these sub glyph shapes (i.e. those with diacritic marks across all four sets) as well as in the characters that fall outside of the Latin character set. I put a tremendous amount of effort into the spacing of the glyphs by using published recommendations for relative side bearing sizes and then manually running them through tests between capital H glyphs, lowercase n glyphs, lowercase o glyphs, and hundreds of other triplet character combinations to optically center them to the degree possible within the constraints of the monospaced requirements. There are some glyphs like the lowercase m that must be wide and look crowded next to other glyphs. There is no way around it. We added Powerline glyphs (not contained in original versions of Bitstream Vera or DejaVu) to support vim, zsh, and other platforms that use this UI. We also developed web fonts in complete sets and subsets of basic Latin and the Latin-1 supplement character to support developers who use web based editors or want to discuss code in a web based context. These fonts are also implemented through a free CDN so that use is as simple as adding a single import statement to your HTML page. You can’t design for small text on the screen without addressing hinting. With the input of Werner Lemberg, we created a set of ttfautohint parameters that are in the process of being optimized for this face. In light of some new issues that were reported in the last couple of weeks, these have been further tweaked through a Control Instructions File to lead to improved display across new platform/editor combinations.

SIL defines any change that modifies the display of the face as sufficient to eliminate the functional equivalence criterion that is necessary to use a Reserved Font Name for a derivative. Changes in something as seemingly minor as hinting are cited as sufficient to warrant a name change when a reserved font name is declared. It is difficult to argue based upon the description of the above changes that this is a different face from a licensing standpoint. It therefore required a new name.

Despite what you may or may not be able to see in a low resolution animated gif (and incidentally you can make out the spacing changes in the c and r glyphs in the gif as well) of a single script, there has been a tremendous amount of effort placed into this typeface. That work extends back to Jim Lyles development of the original glyphs at Bitstream decades ago, includes much of the body of work that the DejaVu camp added, and continues to move forward through this project as a result of contributions from hundreds of developers both within and outside of this repository.

To address the question from the OP, I do not intend to convince you to use the typeface. It’s a labor of love and many of us do find added value above what is offered in other faces out there (including the original sets from which it was derived). We continue to extend it in a direction that I hope improves the appeal for more general source code use across additional platforms and editors with input from other interested developers who have been convinced by the appearance of the face, not by me. I anticipate that this will lead to further departures from the original glyph set so that it does broadly address source code needs. This is a moving target and if you don’t see anything that you like now, check back in six months and see where things stand at that stage. If you are not one of the developers who takes an interest in the typeface, please feel free to use whatever you like. The appeal of fonts is subjective and the appeal of fonts for source code development on the screen is platform, renderer, editor, and display dependent. You either like it or you don’t in the context in which you give it a try. We would be very interested in hearing why you don’t like it if that is the case, but short of that I don’t believe that anyone involved in the project honestly cares what typeface you use. If it serves you well, take advantage of your freedom to benefit from our efforts or take advantage of your freedom to study it and modify it in a way that does.

As for the contribution back to DejaVu, I am all for it and think that it would be the highest level of praise for our efforts here if the DejaVu group did implement any of these changes in their typeface. It intentionally falls well within the license to use any part of the face, or the entire face as part of other projects. The Bitstream and DejaVu typefaces are fantastic faces that required an enormous amount of effort over years to produce. I made the choice to base this face on these glyphs because of my admiration for these typefaces. I have acknowledged the efforts of both groups and all developers involved, making these very explicit. Jim Lyles and all of the DejaVu designers/developers are included on the contributors list in the Hack repository because of the branching/extension nature of all of these projects. I felt that it would be disingenuous not to include them there even though they were not directly involved in the changes associated with the current state of the typeface. It is explicitly stated on both the sourcefoundry.org typeface page and the repository README that this is an extension of these typefaces. The comment that this project has deep roots in the libre, open source font community is a true statement and is intended to acknowledge the heritage of the project extending back over the years of its development. Contrary to the comment above, this attribution is not a stipulation of licensure. There is absolutely no attribution requirement in these licenses. It is simply the right thing to do and I do acknowledge the efforts that they put into creating these glyphs. I recognize through my own efforts how much work is involved. Furthermore, the changes that are happening here are the result of the investment of time and efforts by numerous other individuals and they are being appropriately added as contributors to the project as well. I am behind on this list because I have been working diligently on some changes to support the release of a Debian package that is being developed by one of our contributors, but to date it includes 60 individuals and numerous others belong there. This information is also included on the sourcefoundry.org page to further inform readers about the collective effort that has gone into the project. The most recent set of contributors will be added as of the next release. I don’t consider this my typeface and have not included my name anywhere on the sourcefoundry.org page. There is a link to my Twitter account at the very bottom of the page for contact purposes as the repository maintainer should anyone need to communicate with me about the project. It happens to remain in my personal Github account rather than an organization account because that is where it started and over the last two weeks gained popularity. The effort is collective, but there must be oversight to organize and implement ideas in order to make progress.

As for the media frenzy that was generated around the typeface, I am as astonished as you are. It came about because someone found the repository and posted it on Hacker News. This generated a significant amount of interest, led to a great deal of discussion, and made the top story on HN a couple of weekends ago. The level of interest over the past couple of weeks stems from that publicity. I would like to believe that it is the quality of the typeface that stimulated this interest, but my honest opinion is that the news led individuals who haven’t given much consideration to type design in source code to do so and this simply propagated through the media in the context of this typeface. This has been good for the project because it led to an overwhelming response from developers out there who suggested improvements based upon use in their own bodies of code and we have already implemented a number of changes as a result. As for the notoriety seeking comment from the OP, I don’t understand the source of that accusation. This has never been a popularity contest among typefaces and, if anything, I suspect what will emerge is greater recognition of the need for good type design for developers and a broader range of choices which benefits all of us. I suspect that if you ask around in the type development community you will find that no one ever became famous for developing a font. To test that hypothesis, name the developer of Helvetica, one of the most widely used fonts of all time. I rest my case.

And as for the suggestion of plagiarism @earnestly, I must say I am a bit dismayed. It appears that you dabble in type design yourself based upon the contents of your own repository and I would expect you to have enough understanding of this area to review the project’s merits and actual contributions before you launch an accusation like that. There are a number of libre typefaces that change a single character from another open source typeface (e.g. a different zero) or patch them with the Powerline glyphs and are widely accepted as participants in the open source font development process. I daresay that we have done much more than that in this project and your comment is an insult to all of us who have dedicated our time and effort here.

[manuel-uberti]

@chrissimpkins thanks for this explanation, and I mean it. I'm sorry if I promptly jumped on the bandwagon of the "opposition".

As I already said once: Hack is the reason I left Source Code Pro behind. I haven't used DejaVu Sans Mono before so the differences didn't strike me at first. I also know Hack is a work-in-progress, and I've never looked at a project like this as a matter of plagiarism.

I can see the effort put in this font, though as posted above I know little to nothing about type design. I'll keep following the development, I can say that.

[Earnestly]

I see now where your "60" contributors claim comes from then (with only 2 listed here).

A wall of text that says almost nothing as well. Yes, I have toyed with typefaces in the scope of hinting on low resolution displays. Hinting is not something you'd do on displays with a high pixel density, so I really don't see why you put so much weight on throwing ttfautohint at an outline.

Having actually created typefaces from scratch mostly as a learning excercise, I find much of what you write to be unconvincing.

And yes, you have to include the licenses (Vera and Arev) as you use their work . I'm not sure why you think this isn't the case. You can use DejaVu's additions with impunity though.

[duud]

@chrissimpkins Please remove all licensing issues. Don't waste your time listening to people who are trying to preserve the DNA of something, this is not how progress works.

[chrissimpkins]

DejaVu does not include this license in their own releases of Sans Mono, simply stating that their contributions are in the public domain.

The documentation on the Bitstream derivative page indicates that the merges of these glyphs are either public domain or licensed under the Arev license. I suspect that the former applies to this set (or else DejaVu has their own licensing issues) but will attempt to confirm.

[wasamasa]

@chrissimpkins Thanks for the lengthy explanation. I'll take a look at your project later again, but have to admit that with my requirements none of the listed improvements appeal to me. Variants of a few special glyphs can be easily added to any existing font. The extra spacing looks rather weird to me (a pair of parentheses almost looks like there's a space between them). I don't edit code with foreign character sets often and when I do, font fallback works pretty well. Powerline glyphs aren't necessary for me either since my text editor supports arbitrary shapes in its graphical user interface. And finally, the spacing changes you've made hardly make a difference for me since I neither design for print with monospace fonts nor own a retina display. Under these conditions they look like sloppy hinting adjustments which hardly compare to the results of manual hinting for specific point sizes.

I've missed a pretty specific point in your response though. Yes, you did provide attribution to the DejaVu project and would be delighted if your modifications made it back into it, but did you actually get in contact with them and ask what they think of your project?

[duud]

...but did you actually get in contact with them and ask what they think of your project?

@wasamasa Sorry, but I don't understand the intention behind this question. The DejaVu project provides licences for their fonts. The licence states what they think about projects like this, so that there is no need for every individual project to ask them separately. So what's the motivation behind this question?

[wasamasa]

@duud It's the same as in the original post:

Did you consider contributing the extensions to the original DejaVu project instead? It may not be as much of a chance to gain notoriety on Github and news websites, but would help more people in the long run.

[duud]

@wasamasa Thx, this makes more sense now.

I think github is more appropriate tool for collaboration/development of this font. I don't see why using github contradicts the idea of contributing back to the DejaVu project.

[alphapapa]

@Earnestly I see that you ignored my question. I conclude that you are not acting in good faith. You should leave; and if you do not, your "contributions" should be removed.

Whatever it is that you are actually angry about, taking out your frustration on the people here will not accomplish anything except to make yourself more bitter. For your own good, you should take a hike--figuratively and literally.

[chrissimpkins]

The Arev license is a valid issue and I am clarifying this with the DejaVu team. Caleb prepared a PR to include it if it does apply to the Mono Sans typeface that was used here. DejaVu includes serif, sans (non mono), and condensed sets in their repository as well and the Arev license is not included in the Mono Sans ttf builds that were used here. Feel free to follow in the PR thread if interested in this issue.

[chrissimpkins]

Arev license issue addressed in #110.