Hack: Cyrillic С looks odd

[bofm]

This bug was introduced by _v2.016_ or _v2.017_. "С" looks good in _v2.015_.

Here is how C letter looks in Russian layout in v2.017 and v2.018. That strange thing on the top, it should be removed.

Cyrillic C should look the same as Latin C.

The screenshot is captured in Sublime Text 3 on Windows 10.

[chrissimpkins]

This change was at the request of fellow Cyrillic users in #22

[bofm]

[updated description]

[bofm]

I'm Russian and this kind of "C" hurts my eyes. I asked around people at my office and they have the same opinion.

I understand the point of distinguishing Latin and non-Latin "C" letters. But text looks like a foreing language text with "C" from v2.018. For me Hack is not usable with it.
https://github.com/chrissimpkins/Hack/issues/22#issuecomment-155801645

[MaxKh]

https://github.com/chrissimpkins/Hack/issues/22#issuecomment-156384822

[vladimir-novoseltsev]

Well, this is just ugly. I certainly see little point in creating separate look and feel for cyrillic glyphs.
On top of that additional strokes break clean feel of the font.

[achkasov]

Another compromise could be not a serif but a "drop" as in lowercase "c" of Times New Roman, which is subtle but still different enough.

[chrissimpkins]

From #22 discussion:

We have been closely following your conversation here and I think that we will be able to address both ends of this spectrum at some stage.

There is not presently a plan to remove the distinct lowercase c shape from our font sets and replace this with the Latin lowercase c shape. We would be happy to attempt to modify the current shape to something more visually appealing and are more than willing to discuss any suggestions that you have. Please post images of illustrations with your ideas or examples from other typefaces and continue to discuss these here.

For those who prefer to view the Latin c glyph shape in the Cyrillic set, there is an immediate workaround using the Copy/Paste feature in FontForge to replace the Cyrillic glyph with the Latin glyph. You can use our ttfautohint hinting script to generate new hints on ttf builds or the autohinting capabilities of FontForge if you intend to build otf files. This modification requires a change in the name of the fonts. The sets that you create should not be redistributed with the name "Hack". Please see the license in the top level of the repository for more details.

Our intermediate term plan is to release a tool that will allow you to replace any glyph in the set with alternates or add new glyphs to the set. This is something that we have been discussing for the last several weeks and it is in the planning stage at this point. This will be our solution to the lack of OpenType feature support for alternate glyphs in most source code text editors and the plan is to create an automated approach outside of font editors to make these changes. The current plan includes an associated repository of alternate glyphs that are developed by the project team and user contributions. For those who do not use the font editor approach above and prefer the Latin lowercase c style, please check back in the next few months as we will be interested in your thoughts about the utility of this tool.

[chrissimpkins]

@achkasov Thanks for this suggestion! This was something that was proposed in #22 as well. The problem is that our target type size range includes small sizes. A subtle change like the one you propose will not be apparent at these sizes and will result in the original problem that this change was intended to address. Other shapes that would work and that will display at small text sizes? We are confined to the pixel grid on the screen. Interested in your thoughts.

[vladimir-novoseltsev]

Why do this at all? I can think of only around 5 upper-case glyphs and 2 lower-case ones. You usually do not mix latin and cyrillic in the same place, so it it pretty much easy to notice if wrong input method is selected.

[chrissimpkins]

@vladimir-novoseltsev please see the discussion in #22

[vladimir-novoseltsev]

I've seen it and I do not agree with original issue. Yes mixing latin and cyrillic symbols can be easy since they are look alike, but it is given since current cyrillic alphabet have been using latin like form since 18th century. On another note Cyrillic alphabet have some additional symbols like https://en.wikipedia.org/wiki/Sje , and some of proposed glyph visually would clash with this one.

[bofm]

@chrissimpkins

There is not presently a plan to remove the distinct lowercase c shape from our font sets and replace this with the Latin lowercase c shape

This means an extremely special and unusual feature (#22) is going to be kept in the main version.

[chrissimpkins]

@bofm we are planning a different design. still to be determined. we hear your concerns and are trying to balance them with those of the users who requested this change in the first place.

[ngleb]

I agree that new "cyrillic" С (S) looks horrible. I completely disagree with previous opinions. Cyrillic symbols should look as it meant to be and this is very bad practice to change such behaviour. This symbol what you created is not cyrillic, there's no such symbol at all. People in Russia just won't understand such behaviour, beacuse this is not the symbol we all know.

[mynetx]

@ngleb Let me take a bold step and claim that you won’t need to find a new font. We’re closely thinking about the Cyrillic shapes to find out what is best for most users. What we did by adding a serif to the Es terminal wasn’t right, but we needed some time to find that out.

Stay tuned and subscribed to this issue to get updates on this matter.

/cc @chrissimpkins

[chrissimpkins]

@ngleb will you please comment on this in #22?(_Addendum_: attempting to move the conversation here about this glyph, request posted to the #22 thread). The change originated there from Cyrillic users who were concerned about confusion between the Latin and Cyrillic lowercase c glyphs in their source code. Let's see if we can reach consensus about the need for such a change. The consensus does not appear to be there at this stage and some Cyrillic users express a real concern that the inability to differentiate these glyphs in source code leads to source code problems.

Out of interest, are you actually using this glyph in the body of source code or are you viewing it in source comments? Some other body of text?

[vladimir-novoseltsev]

@jublo Why not keep such changes in experimental branch? With this changes Hack became unusable for me, so I've rolled back 2.015 which don't have'em or switched back to Pragmata Pro.

[chrissimpkins]

@vladimir-novoseltsev Vladimir, are you using the Cyrillic c in source and if so, can you provide screenshots that demonstrate the appearance in your source for us?

[vladimir-novoseltsev]

@chrissimpkins I've been using both Latin in Cyrillic in HTML code and until now I've never been able to confuse them :)

[chrissimpkins]

@vladimir-novoseltsev So this is the content in your HTML file then?

[vladimir-novoseltsev]

@chrissimpkins Yeah, I don't have newer hack installed right now. Let me fetch one, so I have similar fragments with old and new versions.

[vladimir-novoseltsev]

Well, here it is. 2.015 at the top and 2.018 at the bottom.

[chrissimpkins]

I posted this request to #22:

All, if you take an interest in the Cyrillic lowercase c glyph modifications that were made based upon your recommendations here I ask that you please join us in #155 to discuss this change further. For those who recommended the initial change, I request that you provide us with additional details about:

(1) where the Cyrillic c is being used in your source code
(2) examples of how this is leading to confusion, improper linting, source code errors

Based upon this discussion, we will decide whether it is important to maintain this change or revert to the original appearance of the glyph. We have mounting concern that this is not a problem for many Cyrillic users and the distinct appearance of the glyph is cause for concern among many.

We have the option to modify the design and maintain a distinct appearance; however, we will need our Cyrillic users to reach a consensus about the importance of this issue in source code. As you hold this discussion, please use visuals (screenshots are good) that demonstrate your problem and the type of source code that you are viewing the glyphs in.

Thanks much.

Please have a read through the above and, for those who are of the opinion that this change should revert to the Latin c glyph appearance, I request that you detail how you are using the Cyrillic version of the glyph in your own source code. Visuals are very, very helpful as are additional details of the problem for non-Cyrillic glyph (and keyboard if you are using special keyboards/keybindings etc) users. Let's better understand the original problem as posted so that we can make an informed decision about this issue.

[chrissimpkins]

@vladimir-novoseltsev so for you, the information transmitted to readers is not altered in any way whether this is a Latin or Cyrillic c glyph in the body of the text. They are interchangeable in the rendered HTML or is this not the case? Does the Latin c ever lead to some type of error there? For instance if a user were to copy and paste the text from your HTML page to another document?

Can you provide additional details on what keystrokes are necessary to create Latin vs. Cyrillic c glyphs in a text editor? Are there special keybindings that are required for this?

[vladimir-novoseltsev]

@chrissimpkins All you need for entering Cyrillic is input switch in mine case alt+shift. There are some places in code where strings in Russian are present and theoretical could lead to errors, but you normally do not enter single symbol, you enter a whole line, and with low number of look alike glyphs it is hard to miss if wrong input method is selected, as you'd get garbage if you try to write meaning full text be it English or Russian.

[chrissimpkins]

From @ngleb :

Well, I can say add that the origin of this issue might be a keyboard layout. Cyrillic Es and C are on the same button. For more than 15 years of using PC and writing the code I never had issues with Es and C. Only as example, I once had similar issue with 1, l (lowercase L) and I (lowercase i) and never with confusing Cyrillic and Latin symbols (it was Courier font, btw).

I think that two versions would be very good, with all classic symbols and with modified. I understand that it can be difficult so I this is only my recommendadtion. My eyes just doesn't accept such changes, it looks so unnatural for me.

I understand that such apperance can be useful when two sets of characters are mixed (some programming things). But this looks awful in Russian text (for example, I use emacs org-mode to organize my notes and all texts use Hack font because it it default for Emacs, so if I have some paragraph in Russian, modified Es (C) looks bad).

I will try to follow this case and comment on some your proposals.

[chrissimpkins]

some places in code where strings in Russian are present

@vladimir-novoseltsev can you provide some examples outside of the HTML text content context?

[chrissimpkins]

Anyone have feedback about this point by @ngleb?

the origin of this issue might be a keyboard layout

Are we attempting to deal with an issue in the fonts that is a hardware/keybinding problem at its root?

[MaxKh]

The following regex can be used to find Russian symbols in the code

[а-яА-Я]

There is no any reason to do horrible things with Russian glyphs. I'm sure that 99.9% of Russian users will agree with me.

PS: @vladimir-novoseltsev sorry for initial comment.

[vladimir-novoseltsev]

@MaxKh Yep, not mine idea to make it ugly :)

[chrissimpkins]

@MaxKh The need for a workaround to identify Cyrillic glyphs is the exact point that we are attempting to address. IMO, such workarounds should not be necessary for developers who use this character set and mean that information is being hidden from you. The question is whether this information is necessary for source code development.

I understand the visceral response to design as well as the lack of similar "features" in other typefaces. What we are attempting to do in this face is optimize it for source code text. Aesthetics, while important, are a secondary concern. It should be considered another tool in your source development armamentarium along with your editor, syntax highlighter, linters, compilers, and associated development software. You can view this change as a Unicode code point linter built in to the typeface. When I use a linter I see squiggles under words and bold red circles with exclamation points. These are not aesthetically pleasing, disrupt the rhythm of the text, call attention to their existence, and distract from reading (intentionally!) but they serve a purpose and facilitate development.

The question that I am attempting to force you to address is whether this is, in fact, a problem that warrants a solution within the design of the typeface. The individual who suggested this in #22 (and others in that thread) introduced us to this concept and supported such a change. What I am hearing here is that it is not visually appealing and should be removed. As someone who has not, and never will, type this glyph in the context of source code I have absolutely no understanding of this problem and am attempting to address it based upon your comments and input.

If we take this out of the scope of type, are we dealing with a development application that has an ugly GUI but is extremely useful, or are we dealing with a development application that has an ugly GUI and is useless? I'd venture to guess that we all use the former because it helps us to generate better code or simplifies that development process in some way. If that is the case, we can iterate on the design and attempt something more aesthetically pleasing yet distinct. If it is the latter, then we scrap the attempt altogether and revert to the Latin c shape.

[ngleb]

@chrissimpkins
I don't understand such problems as mixing characters. Yes, symbols looks the same. But in normal practice it is very bad to mix Cyrillic and Latin symbols and not just Cyrlillic Es and C. The problem is much deeper than just two this charachters which are on the same button, so the solution with regexpabove is a very good and much more usable than the font characters that looks unnatural.

Also, I can't imagine when Es and C could be mixed. In many cases Cyrillic Es used in text in Russian (also, it can be Ukranian or Kazakh languages and I think some others) and not between some code in Latin. And in most cases in good practice and good code Cyrillic text is separated from Latin text.

I agree that font is the instrument. But font is quite different from squiggles. Just imagine the case when latin font will looks unnatural. I think that many people won't like it because of their understanding how it should look, because it is their native language and native symbols which they know from the birth. The same is for Cyrillic.

[chrissimpkins]

not between some code in Latin. And in most cases in good practice and good code Cyrillic text is separated from Latin text.

@ngleb : This is one of the points that I am attempting to drill down on. Are developers who use Cyrillic glyphs doing so in the body of the source code? Is there compiler, interpreter support for this in languages that you use and is this something that is commonly done if support is there? I understand that this ignores content text areas like the HTML example above and portions of source code files that include comment blocks. Does the Cyrillic Es glyph ever make it into a variable name or some other use scenario in source code?

[ngleb]

@chrissimpkins
Based on my knowledge, Cyrillic characters is never used in source code, in variable names or so. It is possible in some cases (here's example: http://habrahabr.ru/post/82181/ - it just a joke, btw), but in practice it never happens. Only 1С (accounting software, uses Cyrillic in source code in its own editor, but there's everything in Cyrillic, including variable names and so on).

Cyrillic symbols can be used inside strings, which is in source code:

printf("Пример текста на киррилице");

But as you can see, this is very specific.

[vladimir-novoseltsev]

@chrissimpkins It is in general good idea to separate code and strings.
There were one language which allowed Russian keywords, but I haven't seen it since middle-school with non-pc computers (Korvet systems, algorithmic language - yeah that was actual name) . It was specifically tailored for educational purpose, I have seen no production level languages beside 1C platform which would use Russian for keywords and symbol names.

[bofm]

Python 3 supports unicode identifiers. But it is considered a bad practice.

[chrissimpkins]

Cyrillic symbols can be used inside strings

Are there any scenarios that you can imagine where this would lead to compiler errors and do you need to compile in a different way with Cyrillic (or any expanded Unicode sets) glyphs in strings for languages like C/C++?

I have seen no production level languages beside 1C platform which would use Russian for keywords and symbol names

This is extremely helpful!

Python 3 supports unicode identifiers. But it is considered a bad practice.

As is this!

So, what I gather is that the glyph is not used in the body of source text, except as part of a string in which case it _should_ be surrounded by other Cyrillic glyphs. For this reason, the appearance of a c shape in this context indicates that it is Cyrillic, not Latin. There are perhaps edge cases where you would use a c shape alone in a string but we do not need to design for such cases.

Is this a correct interpretation?

[ngleb]

@chrissimpkins
As you can see, here's the first example when specifiers are used in C to indicate placemnt of a character. I'm not sure will this cause a compiler error or it will just print Cyrillic Es instead.

I didn't find any escape sequiences with c.

UPD: checked, this won't compile, but vim highlighted this in different way.

1. %с where Cyrillic Es
   
2. %c where Latin C
   

[chrissimpkins]

@ngleb interesting so your syntax highlighter recognizes the Unicode character set? Does your compiler indicate that this is a Unicode error or what type of message do you get? And does it indicate the position of the problem in the code or just provide a line number?

[chrissimpkins]

do your keyboards default to the Cyrillic or the Latin version? My understanding is that they are both mapped to the same key with a different keybinding pattern.

[ngleb]

@chrissimpkins
I think that this works different. Syntax highlighter knows that this is a C-lang file, so it turn on the appropriate rules. Then, it shows all characters that a specifiers and match "%c" (i.e., double-quotes, %-sign and latin symbol), the same for escape characters. Other symbols that are not escape characters or specifiers will be just string and will be red (in my example). So it just hightlight everything that a syntax-related inside string.

I also checked Emacs, this editor do not highlight escape-characters and specifiers (it can be fixed with extension, actually the whole editor consist of such extensions). I can't say anything about Visual Studio or Sublime, but accoding to screenshots from google images search Sublime will highlight escape characters (https://i.stack.imgur.com/y9lSG.jpg).

[ngleb]

My default layout is Latin (English US) and this behaviour is the default for most IT guys.

Yes, there's different keybinding with different keycodes on the same button.

[ngleb]

Well, I see your confusion and maybe for you it all looks like there's a huge problem. But the real situation is that there's no such big problem and in most cases mixing charaters is a bad practice at all and not just with C and Es.

Unnatural symbols is much worse than mixing characters. Better to avoid it at all. Example with C-language just show when the problem can appear. In normal ways, especially with multilanguage tools, strings are stored in variables and printf doesn't see Cyrillic.

[ngleb]

Also, I rechecked the compiler and it compile but shows the warning. The specifiers indicate the variable type that should be used. In this case compiled program will output %с (%-sign and Cyrillic Es).

UPD:
normal output without issues:

output when wrong characters is used:

Well, I think we can wait for more comments from others. I think that my point is clear enough for now.

[chrissimpkins]

@ngleb Thank you very much for all of this information Gleb. This is all extremely helpful.

[chrissimpkins]

@retgoat, @istarkov, @achkasov, @Bfgeshka - can you comment on the above discussion. There is a push to remove the modification to the Cyrillic es glyph so that it takes the Latin lowercase c shape again.

The arguments are currently supported by these facts that have been discussed in the thread:

(1) the glyph is not used (or at the very least it is poor form to use) in source code outside of strings.

(2) It is typically surrounded by other Cyrillic glyphs within source code strings. These surrounding glyphs provide context for the Es and indicate that it is a Cyrillic glyph rather than a Latin lowercase c.

(3) It may be found in comments within source files; however, these blocks of text should be treated like standard text and not source code because they will not raise compiler errors or lead to interpreter exceptions if a Latin c is used in place of a Cyrillic Es and vice versa.

(4) Entry of the Cyrillic version of the shape requires a keybinding and an explicit set of key strokes as most developers who use Cyrillic glyphs have keyboards that are laid out in standard Latin (English US) keys. The default keystroke is therefore to enter an ASCII character that should not lead to the issues in point 3 above.

(5) The shape of the glyph is not attractive and calls attention to itself in use. This is not seen as a beneficial feature given the above points. This is in contrast to the opinion expressed by each of you in #22.

Please weigh in if you have thoughts that support or contradict the above points or the discussion that has taken place in the thread.

[retgoat]

@chrissimpkins I kept an eye on the above discussion. So, my point of view is unchanged. It's nice that cyrillyc c differs from latin c. But if most of people think other way — maybe you need to hear them. It's up to you mate.

[chrissimpkins]

@retgoat any comments about the above points? Do you feel that they are all accurate?

[chrissimpkins]

There does not appear to be convincing support for this issue after the above discussion. The Latin c shape will replace the modified shape of the Cyrillic es glyph in the next release.

[chrissimpkins]

The original Latin c shapes for the upper case and lower case Cyrillic es glyphs are now available in the test font builds in this directory:

https://github.com/chrissimpkins/Hack/tree/development/postbuild_processing/posthinted_builds

These changes will be included in the upcoming v2.019 release.

[van-de-bugger]

Hi,

It _would_ be nice to have different glyphs for Latin C and Cyrillic Es (and Latin A and Cyrillic A, Latin B and Cyrillic Ve, etc). However, current Cyrillic Es glyph looks so ugly so I use another typeface, not Hack.

It _would_ be nice to have different glyphs for Latin and Cyrillic letters, but visual aesthetic should _not_ be sacrificed.

In my experience I had some troubles with Latin C and Cyrillic Es. It is not related to source code. It could be a problem for searching in databases or texts (in natural languages). For example, you search for "Москва" and have no results, because someone (ten years ago) typed it with Latin C instead of Cyrillic Es. However, nowadays it is very rare case. Also, such problems can be easily fixed by database administrator — as it noted above, usually Latin and Cyrillic letters do not interleave.

Thus, replacing that ugly glyph with Latin C glyph is right decision. Until someone create distinct but aesthetic glyphs for Cyrillic alphabet.

[chrissimpkins]

thanks

[chrissimpkins]

The Cyrillic es glyphs are reverted back to the Latin C/c shapes as of release v2.019 which is now available in the master branch. Thanks to all for your feedback on this issue here.