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

Strange plus #130

Closed
quicknir opened this issue Oct 15, 2015 · 32 comments
Closed

Strange plus #130

quicknir opened this issue Oct 15, 2015 · 32 comments
Assignees

Comments

@quicknir
Copy link

Hey, I like Hack a lot and am considering switching to it. I have to say though that I find the plus sign very strange, I could swear it looks shorter on the bottom than on the top. Am I seeing things? If not, why such an unusual plus?

@chrissimpkins
Copy link
Member

Mind posting your platform and the editor that you are using? Screenshots tend to be very helpful for us to understand what you are seeing. Please include so that we can see the length of those strokes if possible. I haven't noticed this, but we can take a look into it in more detail.

@quicknir
Copy link
Author

I'm on fedora core 20. Screenshot attached. I zoomed in and it really does look like the vertical part below is shorter than above (on the plus). This was in size 12, in terminator. Eclipse it looks the same.

screenshot-3

@chrissimpkins
Copy link
Member

are you using the otf files by any chance?

@quicknir
Copy link
Author

All the Hack files I used to install have the .ttf extension.

@chrissimpkins
Copy link
Member

I agree that does not look right and it isn't designed that way. Are you using the current release (v2.015)? I will check the glyph.

@quicknir
Copy link
Author

Yes, 2.015.

@chrissimpkins
Copy link
Member

Here is the design:

plus

I verified that the stems are the exact same size in the design. EDIT: sorry, I see that you are using 12px from above. Let me take a look at the rendering with hinting at that size.

@stompychump
Copy link

I am seeing this also:

  • v2.015
  • Windows 7
  • Sublime Text 2 with "directwrite" font option and size 8
  • also in Notepad2 at size 8

Looks fine at all other tested sizes, though.

@chrissimpkins
Copy link
Member

@stompychump thanks for letting me know. Can you let me know what other sizes you tested?

@stompychump
Copy link

Here it is in Sublime Text at sizes 6-14 (same specs as above):

plus

@chrissimpkins
Copy link
Member

@stompychump thank you very much

@chrissimpkins chrissimpkins added ready and removed ready labels Oct 21, 2015
@ciscorucinski
Copy link

@chrissimpkins the look of the + is very similar to what I was seeing earlier when we were on ChrisRM's issue thread. In the picture, the symbols are spaced out, and is harder to see, so I have a magnified version.

And just to restate, using ChrisRM's theme, on font sizes 7 - 11, the top bar of the = sign is missing. I have not tested size 6. But this last thing could be a different issue.
.
magnified

@chrissimpkins
Copy link
Member

@ciscorucinski queued up to investigate. Can you remind me of your platform and the editor where you are seeing these issues? Is this still a JetBrains editor? If so, which one and which version? When we discussed this last night you told me that you are using Hack v2.015. Please let me know if this has changed as well.

Thanks

@ciscorucinski
Copy link

OK, I noticed that the displayed text is different if the text is a comment or code

Check this video out here - http://tinypic.com/player.php?v=2zhikbt%3E&s=8#.Vi_D6fkrLIU

I was going to test of all font sizes from 6 - 14, but noticed this strange behavior.

The video shows...

On Windows 10
Using Android Studio 1.5 Preview
Hack v2.015
ChrisRM's JB Material Theme
ChrisRM's color scheme

I am switching between pictures I have taken of the same text, but one is commented out, and the other is rendered as if it is code. You will see the + will move up and down, the - remains fairly stable, but the = will lose the top bar. I have the # symbol there for reference.

@ciscorucinski
Copy link

Before I had noted that for the = symbol...

This issue with the top bar disappearing was only seen when using JB Material Theme in Java, C/C++, and Groovy with font sizes 11 and below. Places like XML, HTML, JSON, etc. didn't have this issue at all.

However, I have just come to realize that within Java, the comments with font size 11 DO show the = symbol correctly.

Turn off JB Material Theme, and at least the = symbol is displayed correctly...no matter the font size. But I assume the + and - still have their issues

@chrissimpkins
Copy link
Member

This + symbol issue appears to be a hinting problem. I found the it at the sizes reported here and we will address it in an upcoming release. Thank you very much for reporting it!

@chrissimpkins
Copy link
Member

Would it be possible to check whether you are seeing this in the bold, italic, and bold italic sets as well?

@chrissimpkins chrissimpkins added this to the v2.017 milestone Oct 29, 2015
@stompychump
Copy link

Yes, I am seeing it in all sets:

plus_styles

The above is v2.015 TTF, Windows 7, Sublime Text 2, size 8, directwrite.

@chrissimpkins
Copy link
Member

Thank you very much. This is helpful @stompychump . I am going to try to get this fix in with the next release. Hope to have it out ~ this weekend. Will update here.

@chrissimpkins
Copy link
Member

@ciscorucinski Christopher, do you mind opening a separate issue report for the = glyph issues that you are seeing? Have you received any feedback from the developer of the highlighter?

@ciscorucinski
Copy link

@chrissimpkins Yes, I can do that. I have not recieved feedback from ChrisRM yet. He has been gone for over a week.

@chrissimpkins
Copy link
Member

@ciscorucinski thank you. Let's see what he has to say before we take on that issue. The behavior suggests that there may be a highlighter specific issue and I will likely need input from him to see if there is something to fix on our end.

@chrissimpkins
Copy link
Member

I identified the hinting problems and added new manual instructions to this glyph. This should address these problems. The changes will be part of the upcoming v2.017 release due out this week. Will post here when available.

@chrissimpkins
Copy link
Member

The hinted v2.017 ttf release files with this fix are now in the development branch. They are available here if you want to try them hot off the presses:

https://github.com/chrissimpkins/Hack/tree/development/build/ttf

The official release will take place in the next day or so. Please let me know if you still see problems with the + glyph before we push these.

@stompychump
Copy link

Here are v2.015 and v2.017a side-by-side (TTF, Windows 7, Sublime Text 2, directwrite, sizes 6-14):

plus_sizes_v2 017

The original issue appears to be resolved, although the hinting is tending to make the crossbar indistinct at smaller sizes (perhaps unavoidable?).

@chrissimpkins
Copy link
Member

@stompychump thank you very much for the images. What text sizes do the comments about the crossbar apply for you? There are ways to address this if it is falling within a commonly used text size range. I suspect that few are using 6/7px sizes, but perhaps I am wrong.

@stompychump
Copy link

To my eyes, sizes 8, 9, and 10 now have a blurrier crossbar in v2.017a in the image above (on the right), and also slighty in sizes 11 and 12. Here's an animated image that might make it clearer:

plus_sizes_animated

For sizes 9-12, I prefer the sharper plus in v2.015. I generally use size 8 though, and for that size it's a toss-up which version I prefer - v2.017a seems blurry, but the original issue is fixed which is great. I realise that there are trade-offs when hinting, so this is just my subjective opinion and not meant as a complaint.

@ciscorucinski
Copy link

Just as a side note, the horizontal bar on the + should match with that on the -, right?

If so, then what is being done differently on the - that it is displayed correctly but the fixed v2.017 update is getting better, but not sharp. Using the = as a base, there are anywhere from 1 - 2 pixels of space in between the top and bottom bar.

The horizontal bar in the - is displayed...

  1. along the bottom pixel space IF there are 2 pixels between the top and bottom = bars
  2. along the "center" pixel space IF there is only 1 pixel between the top and bottom = bars

These seem reasonable.

The horizontal bar on the + is different...

  1. For size 7, the symbol as a whole is still +1 pixel too high
  2. For size 8, the horizontal bar was shifted +0.5 pixels, and is now blurry
  3. For sizes 9 - 12, the horizontal bar was shifted -0.5 pixels, and is now blurry

If the horizontal bar was shifted by whole numbers, in this case +1 or -1, then they would be in the correct place an sharp.

Note: I have not installed v2.017 yet, and I am only using the animation above. Also, I used the Magnifier App on Windows to look at the zoomed in typeface without further anti-aliasing the font.

@ciscorucinski
Copy link

@stompychump What are you doing to get those animated screenshots. My current train-of-thought on doing that with multiple font sizes with the Hack typeface is very cumbersome. I can easily do it with one font size; not multiple. Would it be easy to add testing with a JetBrain IDE into the toolchain?

I would like to do this for the whole suite of regular printed characters...easily do multiple font sizes...animated between different style...with a specific IDE

@chrissimpkins
Copy link
Member

@ciscorucinski we're not going for pixel perfection (yet). This was a quick monkeypatch for the upcoming release that will be out tonight. The horizontal strokes are now aligned at ~ the midline of the vertical stroke in the post-hinted versions. This led to lines that are straddling pixels at some text sizes. Most text sizes that were mentioned in this issue report were out of alignment by a half pixel in the post-hinted versions and you were noticing this difference in the render. I don't know that we will be able to approach this in the glyph design. I suspect that we are going to need to generate size specific manual hints of the entire glyph (not just the horizontal stroke) across this size range in order to achieve a sharp glyph that is aligned to the pixel grid at each size. This may throw alignment off relative to other glyphs at certain sizes and will require a much more thorough evaluation in order to implement this.

We will continue optimizations with upcoming releases and can leave this open to discuss them here. I definitely consider this a high priority glyph for the fonts.

I am going to push the current iteration as part of the v2.017 release and we will work on further improvements from there. (see next post) Happy to address this further in the next and future releases.

As a side note, we are about to start work on the build toolchain and once this is in place, you are likely to see more frequent iterative updates to the fonts. The releases are currently a significant, largely manual, effort and we intend for this to change (very, very soon).

@chrissimpkins
Copy link
Member

All: Changed my mind. I am going to pull these changes out of the upcoming release and we will address them in a bit more detail before we push them. Let's not create more problems in the attempt to fix the original problem. When we have a satisfactory solution, we will go live with it.

Do you mind having a look at the bold, italic, and bold-italic sets as well? I made changes across all sets and we may have similar problems with blurred strokes in each area.

These changes are very simple to reverse and reimplement.

@chrissimpkins chrissimpkins modified the milestones: v2.018, v2.017, v2.019 Nov 3, 2015
@chrissimpkins chrissimpkins added this to the v2.020 milestone Jan 11, 2016
@chrissimpkins chrissimpkins modified the milestones: v2.021, v2.020 Mar 28, 2016
@chrissimpkins chrissimpkins removed this from the v2.021 milestone Jun 28, 2017
@chrissimpkins
Copy link
Member

All ASCII glyph hints were reviewed from 8-14ppem and modified where necessary as part of our v3.000 release. Please upgrade and let us know if this issue is still a problem for you with these updates. Closing this issue. Please reopen if you would like to discuss further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

4 participants