I also have a difficult time reading large numbers without commas. Because I use Alfred (mac command launcher) quite a bit, I wrote up a simple workflow to re-display selected numbers with commas. Not as universal as the font-based solution but might be useful to some:
In most cases, you'd want this to be handled at the OS-level by setting your locale preferences to match your region. However, this would require the app to be properly internationalized (using number formatters, etc.) to work correctly.
So you bring up a neat idea. I'm not sure which OSs support it, but OpenType does have a `locale` feature, primarily for glyph variants (ex: same codepoint, but different glyph for Chinese vs. Japanese). I'm guessing it could be abused to accomplish what you want and not require an app to adopt i18n APIs.
If you're downloading and installing a custom font, why do you need it to be locale-aware? Just down the variant that uses whatever your locale needs. (Or if there isn't one, fork it and change the commas to periods and the install that.)
It seems like the only reason you'd need a locale-aware one is on a multi-user system where you'd expect users to have different locales and you're installing the font globally.
But that doesn't really seem like a likely use-case for this pretty niche font that is almost exclusively going to installed on single-user machines by the end-user.
Probably cool, but the website disables zooming in phones so I can't tell. I wish pages couldn't disable zooming -- that should be up to me. Does anyone know browsers that always allow zoomi
(If any Jane Street blog folks read this, please fix your blog.)
Interesting article! Time to start a new crusade, I guess like I did for True Colors[1], and BiDirectional[2] text. This time for a better font shaping support. If you have ready tests it would help a lot. Personally, I am waiting for ligatures support to be merged[3] in alacritty terminal emulator.
Update: I started a list[4] of terminal emulators supporting it and not.
Previously bugs in how iOS with how it handles certain unicode combining characters meant that an attacker could crash someone's iPhone just by sending a text. I'm not sure if it was buggy logic in the font.
AFAIK general style guides don't recommend using thousand separators in numbers below 10000, so "variable #1,234" is not quite good, it should've been simply "variable #1234". "Variable 12,345" would've probably been OK, but then there's another semantic issue: thousand separators are only used in numbers that mean quantities, not identifiers. Long numeric identifiers like phone number or SSN are usually separated differently.
Generally the issue should not be handled at the font level, it lacks sufficient context to make intelligent decisions and can never handle all possible cases. The font should just provide the required glyph variants and means to use them.
So, one could have a font that, say, hides the flag of Taiwan in a Chinese locale? (Yes, there are multiple ‘Chinese’ locales:
zh-CN Chinese (Simplified, PRC)
zh-SG Chinese (Simplified, Singapore)
zh-TW Chinese (Traditional, Taiwan)
zh-HK Chinese (Traditional, Hong Kong S.A.R.)
zh-MO Chinese (Traditional, Macao S.A.R.)
)
Not just Germany. Comma vs dot is just a big mess with some countries using both[1]. Even in Germany, which is decimal comma country, the dot is ubiquitous in science and technology publications. Best thing is to stick with dot and us neither comma nor dot as thousands separator but a thin, fixed space. This also what NIST recommends[2]:
> #16 Digit spacing
> The digits of numerical values having more than four digits on either side of the decimal marker are separated into groups of three using a thin, fixed space counting from both the left and right of the decimal marker. Commas are not used to separate digits into groups of three.
There are much more variants. E.g. Russia uses space for thousands and decimal comma. And I may be mistaken, but I believe in Japan the grouping is by four digits, not by three.
Not touching 4 digit numbers is a good variant idea, I might do that, it would only be a one line of code change.
I also still think an alternative world where we decided to use font shaping for digit grouping would work out better, it would just maybe have different conventions. Numbers that you manually separated wouldn't be touched anyways unless you use any group longer than say 4 digits.
For contexts with long identifiers that don't represent quantities like database IDs there could be a stylistic convention of prefixing them with a @ or something instead of a manual stylistic convention for quantities. Then maybe your font could do something cool to make it easier to tell when two big ten digit random numbers in a column are the same, like a pattern of underscores based on hashing. Also having digit grouping in your meaningless IDs is way less of a problem than not having digit grouping in your quantities.
This is fantastic for command line output and whatever that doesn’t natively support digit grouping. I have no idea how people live without enabling it.
I turn it on my Windows calculator, and I’m also happy that now programming languages like JavaScript, Python and recently Go allows using underscores in numeric literals for doing this in code to make it more readable.
Presumable it handles text that already has a comma separator OK, since there isn't a continuous group of >3 digits in '1,234'.
I suppose the same is true of continental Europe's '1.234', though it would be very cool if it could be determined that the '.' was a thousand separator and modified to ','.
What happens though if the text is using '.' separator and ',' decimal, such as (roughly 123 and a half) '123,456789', is it going to determine there's a missing ',' between '6' & '7' (making it roughly 123 and a half million)?
42 comments
[ 4.4 ms ] story [ 90.7 ms ] threadThis should be an opt-in feature in all programmers fonts.
I also have some good fonts pre-patched on the download site at https://thume.ca/numderline
I also have a difficult time reading large numbers without commas. Because I use Alfred (mac command launcher) quite a bit, I wrote up a simple workflow to re-display selected numbers with commas. Not as universal as the font-based solution but might be useful to some:
https://github.com/abhik/tres-commas
So you bring up a neat idea. I'm not sure which OSs support it, but OpenType does have a `locale` feature, primarily for glyph variants (ex: same codepoint, but different glyph for Chinese vs. Japanese). I'm guessing it could be abused to accomplish what you want and not require an app to adopt i18n APIs.
There are no commas in his font.
"I realized that instead of inserting commas, I wanted to underline alternating groups of 3 digits so that the font would work in monospace contexts."
https://thume.ca/numderline/
It seems like the only reason you'd need a locale-aware one is on a multi-user system where you'd expect users to have different locales and you're installing the font globally.
But that doesn't really seem like a likely use-case for this pretty niche font that is almost exclusively going to installed on single-user machines by the end-user.
With this feature enabled, I can zoom in on this site.
With this feature disabled, I can not zoom in on this site.
Update: I started a list[4] of terminal emulators supporting it and not.
[1] https://github.com/termstandard/colors
[2] https://gist.github.com/XVilka/a0e49e1c65370ba11c17
[3] https://github.com/jwilm/alacritty/pull/2677
[4] https://gist.github.com/XVilka/070ed8b1c1186097cad65ef492201...
https://github.com/tonsky/FiraCode/wiki/VS-Code-Instructions
More advanced but totally doable would be switching to that mode for hex strings after "0x" or "0X"
https://news.ycombinator.com/item?id=16386444
Generally the issue should not be handled at the font level, it lacks sufficient context to make intelligent decisions and can never handle all possible cases. The font should just provide the required glyph variants and means to use them.
(Though I still don't think doing this in the font is a good idea, in general.)
ZHP seems like it's unlikely to be used in the wild.
> #16 Digit spacing
> The digits of numerical values having more than four digits on either side of the decimal marker are separated into groups of three using a thin, fixed space counting from both the left and right of the decimal marker. Commas are not used to separate digits into groups of three.
[1] https://en.wikipedia.org/wiki/Decimal_separator#/media/File:...
[2] https://physics.nist.gov/cuu/Units/checklist.html
I also still think an alternative world where we decided to use font shaping for digit grouping would work out better, it would just maybe have different conventions. Numbers that you manually separated wouldn't be touched anyways unless you use any group longer than say 4 digits.
For contexts with long identifiers that don't represent quantities like database IDs there could be a stylistic convention of prefixing them with a @ or something instead of a manual stylistic convention for quantities. Then maybe your font could do something cool to make it easier to tell when two big ten digit random numbers in a column are the same, like a pattern of underscores based on hashing. Also having digit grouping in your meaningless IDs is way less of a problem than not having digit grouping in your quantities.
I turn it on my Windows calculator, and I’m also happy that now programming languages like JavaScript, Python and recently Go allows using underscores in numeric literals for doing this in code to make it more readable.
I suppose the same is true of continental Europe's '1.234', though it would be very cool if it could be determined that the '.' was a thousand separator and modified to ','.
What happens though if the text is using '.' separator and ',' decimal, such as (roughly 123 and a half) '123,456789', is it going to determine there's a missing ',' between '6' & '7' (making it roughly 123 and a half million)?