source-foundry / Hack

A typeface designed for source code
http://sourcefoundry.org/hack/
Other
16.49k stars 615 forks source link

Any plan to create compressed/condensed or thin styles? #48

Open c02y opened 9 years ago

c02y commented 9 years ago

I enjoy PragmataPro, which is relatively thin, so if you can create compressed/condensed styles for it, I would appreciate that.

chrissimpkins commented 9 years ago

Do you mean thinner strokes or narrower horizontal spacing between the characters?

c02y commented 9 years ago

I don't exactly understand the meaning of your expression.

You don't have to change anything, just make the width smaller or height bigger, you can google "compressed/condensed font " for images of those kinds of fonts, many fonts consist of regular, italic, bold, compressed/condensed, and maybe even more complicated font styles combined of those basic styles.

chrissimpkins commented 9 years ago

Interested to know if you want the individual glyph shapes to appear narrower (i.e. finer like a thin style font) or if you want narrower spacing between glyphs so that they appear closer together (a condensed set).

c02y commented 9 years ago

When you already made characters narrower, if you don't make them closer, the big space between characters would make your code/text extremely ugly.

chrissimpkins commented 9 years ago

There are no immediate plans to support a thin set. Let's leave this open and see if we can attack it down the road.

c02y commented 9 years ago

The space between characters of compressed/condensed could just be the same as the regular style, no need to be smaller than regular.

davidcelis commented 9 years ago

Hey @chrissimpkins, I was about to open an issue with this same request. I think what @c02y is trying to say is just that it would be nice to have a set with thinner strokes. For example, I currently use Source Code Pro and prefer to go all the way to ExtraLight. I love the look of Hack but I've gotten so used to a thin stroke that it seems bold to me :wink:

I'm not a font designer so I could be totally wrong, but it doesn't appear that a thin set would require any sort of spacing changes. It should be similar to creating a bold set but on the other end of the spectrum.

chrissimpkins commented 9 years ago

Thanks @davidcelis and @c02y. I understand. Let me look into whether there is a reasonably straightforward interpolation approach that we could use. Unfortunately this isn't (/may not be) a simple request and may require a manual draw of an entirely new set.

sjrmanning commented 9 years ago

I believe @c02y is actually after a condensed version, whereas @davidcelis is after a set with, like he said thinner strokes. I would like to +1 for thinner strokes — especially on retina displays I find light variants are much nicer to read.

chrissimpkins commented 9 years ago

@sjrmanning noted. thank you very much

chrissimpkins commented 9 years ago

Have been looking into this in more detail over the last week. I think that this may be possible. Will update here.

c02y commented 9 years ago

Thank you. I'm looking forward to it.

anna-is-cute commented 9 years ago

I was also looking to move from Source Code Pro, which is what I use everywhere. Using Hack is nice in my IDE, but I prefer a lighter font weight for terminals and IRC. I would love to see this, since then I could use Hack everywhere!

chrissimpkins commented 9 years ago

@jkcclemens Thanks Kyle. We are working on improvements to the current sets over the next several releases and then will revisit this, if even to begin a smaller character set release and build simultaneously from there. Will post here when we have something for you.

mdkcore0 commented 8 years ago

Hey, +1 for the condensed/compressed set (like PragmataPro or Input Mono Compessed) ;)

Also, nice work on Hack!

chrissimpkins commented 8 years ago

@rodrigogolive thanks for your feedback! This is something that we will definitely consider down the road. We are in the process of implementing a significant change in our build tool chain and have a number of planned changes in the current sets. Once things settle out with these primary areas of focus we will definitely revisit this issue.

c02y commented 8 years ago

PragmataPro and Input Mono Compessed are my only fonts for my Emacs after testing a lot of fonts.

On November 28, 2015 12:15:18 AM GMT+08:00, Rodrigo Oliveira notifications@github.com wrote:

Hey, +1 for the condensed/compressed set (like PragmataPro or Input Mono Compessed) ;)


Reply to this email directly or view it on GitHub: https://github.com/chrissimpkins/Hack/issues/48#issuecomment-160168570

chrissimpkins commented 8 years ago

Will the two of you push some screenshots so that we can see what you are seeing (and want)

davidcelis commented 8 years ago

Sure thing, @chrissimpkins. Here's what a normal weight font (Source Code Pro, for example) would look like:

screen shot 2015-11-27 at 7 02 31 pm

And here's what Source Code Pro looks like when set to Extra Light (which is what I personally use):

screen shot 2015-11-27 at 7 02 44 pm

chrissimpkins commented 8 years ago

@davidcelis Thank you David!

davidcelis commented 8 years ago

No problem! There are more examples of weight differences here, from 200 to 900 in increments of 100: https://www.google.com/fonts/specimen/Source+Code+Pro

c02y commented 8 years ago

Thanks for the snapshots, but I'm afraid I'm have to tell your that these are not what I'm talking about at all, these are just normal and light fonts, not compressed/condensed, I have no access to my personal computer right now, I'll post them here tomorrow.

-------- 原始邮件 -------- 发件人:David Celis notifications@github.com 时间:周六 11月28日 08:03 收件人:chrissimpkins/Hack Hack@noreply.github.com 抄送:c02y cody.chan.cz@gmail.com 主题:Re: [Hack] Any plan to create thin styles? (#48)

Sure thing, @chrissimpkins. Here's what a normal weight font (Source Code Pro, for example) would look like:

screen shot 2015-11-27 at 7 02 31 pm

And here's what Source Code Pro looks like when set to Extra Light (which is what I personally use):

screen shot 2015-11-27 at 7 02 44 pm


Reply to this email directly or view it on GitHub: https://github.com/chrissimpkins/Hack/issues/48#issuecomment-160228154

mdkcore0 commented 8 years ago

Hey @chrissimpkins, I'm adding some screenshots of my environment, all of them using the same settings for the fonts (the code snippet is from the live preview of Input):

PragmataPro: st_pragmatapro

Input (on their site there are a configurator that helps to mimic the feel of other fonts): st_input

Hack: st_hack

I like Hack, it's pretty nice to use, but when developing (~80% of my time in front of a computer), I miss the condensed style of the other fonts.

chrissimpkins commented 8 years ago

@rodrigogolive thank you very much! This is very helpful to see how tight things are in your working fonts.

Are you generally in a small terminal window rather than a full screen editor? Is the intent more glyphs per width or is it the appearance that you prefer?

mdkcore0 commented 8 years ago

You're welcome @chrissimpkins! i am used to have a full screen terminal (generally 1920x1080), running a terminal multiplexer (tmux), so I can quickly run/edit/navigate on them. Here are two new screenshots at this resolution, with a current project so you can see the differences (just resized a little, as the intent is to show the difference of the font on screen).

Hack (attention on the top panel, vim vertical splits): st_hack_1920x1080

PragmataPro (same environment, with this style of font I can have an additional vim split): st_pragmatapro_1920x1080

When developing, I prefer to have more glyphs per width, but I'm OK with the appearance on other tasks. But, as I'm developing at the most of the time, a compressed/thin style is better for me ;)

chrissimpkins commented 8 years ago

Got it. Thank you very much!

c02y commented 8 years ago

@rodrigogolive These are my screenshots in my Emacs, a little difference from yours, I think it is caused by your teminal:

PragmataPro

pragmatapro


Input Mono Compressed

input mono compressed


Hack

hack


Oh GOD, these three pics took me several hours to upload to Github, always says file type not supported, but they are just jpeg or png.

chrissimpkins commented 8 years ago

@c02y wow, you really do like it tightly set. Just to confirm, these are all at the same font size? The glyphs look larger for Hack. This may be an x-height difference or just a visual distortion based upon the narrower glyph widths in the condensed fonts you are showing.

chrissimpkins commented 8 years ago

@c02y and I'll ask the same question, are you trying to achieve more glyphs per width or you simply have a preference for this appearance in your text?

chrissimpkins commented 8 years ago

And final question for the day... how does Hack look to you if you take the font size down a few pixels? There will be a point where you will achieve the same character / width threshold. With the large counters and x-height on these glyphs you can get away with pretty small font sizes in many cases (platform/display/renderer dependent). The sacrifice will be in the height of the glyphs, but they may actually be more clear because of the wider relative fixed width than in the condensed fonts. I see issues with the glyphs like the wand m in those condensed font screenshots. These are notoriously problematic in fixed width fonts because they need space between the strokes to display well on the screen.

c02y commented 8 years ago

@chrissimpkins

The fonts in my three screenshots are all the same size(14), I was using (If you know how to use Emacs)

(set-frame-font "PragmataPro-14" t t)
(set-frame-font "Input Mono Compressed-14" t t)
(set-frame-font "Hack-14" t t)

to change the font temporarily and then take the screenshots, I didn't change anything but the font name and font size, and yes, the Hack-14 is lager than "PragmataPro-14" and "Input Mono Compressed-14".

You can simply think that all I need is more glyphs per width.

That (14) is the best font size both for my eyes and in my screen, so if I make the Hack font smaller, it may be not friendly to my eyes, and I still like the ProgmataPro and Input Mono Compressed way, I mean more glyphs per width.

chrissimpkins commented 8 years ago

Got it, thanks!

anna-is-cute commented 8 years ago

There are still those of us who want thin styles, which are not compressed styles. Feels like compressed styles should be in a compressed styles issue, and thin styles should be in the thin styles issue. However, it would be nice to have compressed styles and thin styles.

chrissimpkins commented 8 years ago

@jkcclemens Thanks Kyle. The condensed variants will require a full redesign of the glyphs. This is a big project across the 1500+ glyphs x 4 variants that we release. The thin styles will be more straightforward but will still require a significant amount of work. Both of these are likely to be medium to long term projects for us as we still have a great deal of work to improve the current sets before we are prepared to tackle either of these projects with the size of our development team at the moment. I see these as derivatives that start as ASCII sets and expand in the breadth of character set support from there.

If we can attract more typeface developers who would like to participate in the project or someone takes an interest in creating their own fork to generate a derivative along these lines, these would be perfect areas to tackle sooner rather than later.

c02y commented 8 years ago

@jkcclemens Thanks, already changed the issue title to compressed/condensed.

davidcelis commented 8 years ago

Should we open a separate issue for thin styles?

c02y commented 8 years ago

@davidcelis Unnecessary, I changed the issue title to contains both compressed/condensed and thin since there are already conversations about thin font in here.

oryband commented 8 years ago

Hi. Any update?

chrissimpkins commented 8 years ago

Nothing in the works at the moment. Remains on the to do list.

oryband commented 8 years ago

PING! How about now?

mistadikay commented 7 years ago

Would love to see Hack Light! It's the only reason why I won't consider it over Hasklig Light which I currently use

chrissimpkins commented 7 years ago

@oryband @mistadikay

We need some type designers to help with these draws to support them on our end. The lead author crew here is very slim in number and our project goals/time demands elsewhere (in and outside of the project) have not permitted this to date. Would love to make all of these things happen but a complete re-draw to achieve this is an enormous effort. To date, no one with an interest has come forward to do this.

For those who are interested in these new variants, I would encourage you to grab a FLOSS font editor (e.g. TruFont, FontForge) and get to work drawing from the new UFO source! We highly encourage and support forks. Upcoming changes are very much intended to support this to a much greater extent and we are happy to help get derivative projects off the ground in any way that we can.

Few updates on our recent changes that apply here. As of v3.0 we will be modifying the license to remove the reserved font name so that anyone who designs any derivative / fork of Hack can use Hack in the name. In addition, our new automated build tool chain (all FLOSS tools, fully scripted) that is coming as of v3.0 should make everything outside of the design itself (including desktop builds, automated hinting, and web font builds of woff + woff2 files) very simple to maintain in derivative projects. The build tools are currently under review by the Debian and Fedora projects so that anyone who forks and builds new things with the build tooling here can release on these platforms that build fonts from source under free software guidelines.

mkleehammer commented 6 years ago

Ping?

chrissimpkins commented 6 years ago

No plans to do this work myself. If someone out there wants to draw them we would be more than willing to support it and I would personally be willing to help however I can. It is going to take someone with the type design skills and a lot of free time on their hands... This is a very time intensive request.