Chinese does the same thing, using prefixes like 西 (western), 番 (foreign), and 洋 (foreign) for introduced items.
For tomatoes, interestingly, it has two common names that follow this pattern: 西紅柿, literally translated as "Western Red Persimmon", and 番茄, literally translated as "Foreign Eggplant".
Other produce examples include 番薯 (Foreign Yam) for sweet potato, 西瓜 (Western Melon) for watermelon, 洋蔥 (Foreign Onion) for bulb onion etc.
The recorded English-language etymology for "ketchup" suggests that the word comes from one of the Chinese dialect's word for tomato. Do you have any idea which Chinese word sounds like ketchup?
My personal theory based on nothing more than the vibe of the thing is that it comes from the Malay/Indonesian word ‘kecap’ (which is pronounced almost identically to “ketchup”), the word for sweet soy sauce. This is soy sauce that is thickened and sweetened with palm sugar, and I could see European cooks attempting to replicate it based on the vague descriptions given by sailors, and ending up with ketchup.
Are the Vietnamese and Chinese languages related? Or perhaps one of the two cultures was introduced to that fruit by the other, and thus preserved the name?
Not related at all in recent history and I have no insight on the etymology links but Vietnamese used to be written in a mix of original Vietnamese Chinese-style characters before they changed to a Latin alphabet with Colonialism and Communism so there was definitely contact.
In Chinese the use of 西 (western) often really means from the West compared to China so India/Central Asia/Middle East, which can be a little confusing at first if you are used to the word meaning "Western World".
For instance, watermelons come from Sudan/Egypt and thus arrived in China from the West long before Europeans visited.
Another example is The Journey to the West (Monkey King) novel which is also about travelling to India.
Better analogy would be that even though the coffee machine is still worse, we choose it because it's more convenient (at least I think that's the case).
Anecdotal, but the best machine will never be able to do something as good as the best human in most circumstances. That is because, unlike machines, humans have passions and character that subtly imbues itself in the end result. This, of course, isn't limited to coffee, but to anything a machine could do that isn't strictly tied to exercises in logic (for example, computers will always be better than humans at most games because they can be analysed logically and acted upon)
But the point is you will never have the best barista all the time l. Unless you are 0.0001 % of population who can afford personal barista to follow you anywhere, you accept whoever is serving coffe at the corner shop. And for a machine to be better that <average> barista is not a tall order. So it makes good coffee accessible for many
I feel like, despite not being my (and presumably most of HNs, given the general demographics) cup of tea, sports are largely that. The players are skilled but also uniquely themselves. The world cup wouldn't be nearly as interesting if it were just unthinking robots fighting to see who can run around and kick things the best
I love this kind of stuff (ASCII art, if you will), but it just breaks down too easily as soon as Unicode characters (mainly CJK, as I'm Chinese) and fonts are involved.
For example, on your website, any chart or plot involving horizontal arrows breaks down because the assigned font-family (`ui-monospace, SFMono-Regular, Menlo, Consolas, monospace`, which ends up as Consolas on my machine) has no such glyph. Thus, it falls back to Segoe UI Symbol, which does not have the same fixed width (or is not fixed-width at all) as other characters: https://i.imgur.com/d2DPGHE.png
I ran into this problem recently on one of our blog posts: we used some Claude output which included tables drawn with Unicode line drawing characters. However, our monospace font did not include these characters, and so rendering fell back to another font in our font stack with different width metrics. I fixed it by using a font that had similar metrics and did include those characters with `unicode-range` (to only select characters we needed) and `size-adjust` (to match font width more exactly), and adding it to the stack. It's a little hacky but works pretty well in practice.
> Thus, it falls back to Segoe UI Symbol, which does not have the same fixed width
That seems like a glaring omission to me. If you are rendering fixed-width-per-character text and need to fall back, surely it makes sense to keep to the same character grid even if it does mess up the feel of your negative space somewhat (thin characters having a lot of space around them, wide characters butting into those beside them slightly). You've explicitly asked for text aligned to a grid, either by using a mono-spaced typeface, by using a <pre> tag, or with other relevant CSS choices, the browser should be trying to achieve that.
The first issue is due to the assumption that character count equals character display width. Thai tone markers usually[1] should not contribute to the display width (เพื่อน is chars = 6, width = 4), so it caused a layout shift.
The second issue is due to the program's layout engine not adjusting the glyph width of a fallback font to that of the main font. A lot of terminals do this, but it's not common for text editors or browsers (arguably this is the correct behavior for non-terminals, since you cannot assume everything must be snapped to a grid).
Fun test for this:
|กล้วยหอม|
|Bananas|
This has the same character width. Ghostty, etc., will render it correctly (| aligned). Most browsers and text editors will not.
[1]: some layout engines render free-standing tone markers as 1 character; in that case, this rule only applies to when tone markers are following a character.
This isn't a renderer bug, it's font. Proportional fonts aren't designed with alignment in mind at all, and you can't just expect monospace fonts for all languages outside of ASCII range to be present on random systems, or a single font or font family to support multiple different languages consistently.
You can't really control alignment of deeply Unicode characters like Thai or "→" against monospace characters without serving your own monospace fonts that are guaranteed to work for the characters you'll be sending out, assuming you can always have one in hand.
You can still handle this well enough in the renderer, so I'd still consider this a renderer bug - e.g. my terminal emulator will scale any glyph that exceeds the bounding box as defined by the expected number of cells for a given character range. You can't expect any given feature of random characters to align, but I can expect box drawing characters surrounding any given characters to align correctly or consider it a bug (my terminal is almost certainly going to get CJK and Thai wrong - it's entirely untested -, but if so it is a bug, not a font issue).
That includes if I have to fall back, including fallback to proportional fonts, which will look ugly, but work and remain aligned.
ok... I disagree, and I mean no offense, but there's going to be too much contexts and nuances to be taken into account that it's probably not worth trying for both of us. All I can say is that the problem is not that the pipe characters are given inconsistent width but that non-ASCII characters has all different random widths, and if you need texts with double-width characters like ▶, 漢, ก, etc., to align in a grid, you have to pick a fixed-width(not "monospace") font for the specific language and exclusively use that font for everything within that contiguous text area. Or you can try to fix Unicode so that symbols become variable width so to align to grid or something, but that's going to take a lot of effort.
No, you don't need to pick a fixed width font for that. You will get the best results with one, but rescaling the glyphs works just fine. I've written a font renderer. It's not hard.
In fact my terminal, using said font renderer, rescales glyphs by default because even a lot of "fixed width" fonts are buggy and not truly fixed, and so enforcing the grid alignment and scaling to fit was the easiest way to ensure consistency.
Mixing and matching fonts for full coverage works fine, especially for wide characters.
I thought this discussion is more about somehow aligning pipes over multiple lines in existing console emulators(impossible), than about implementing a complete custom graphical text rendering system specific to your app that butcher font files to put glyphs wherever you want?
That feels like cheating since you're not rendering provided font at that point. Besides you might as well just use SVG for diagrams than pretending to be text only.
> I thought this discussion is more about somehow aligning pipes over multiple lines in existing console emulators(impossible)
I am aligning pipes over multiple lines in my existing console emulator. It's not just not impossible, but near trivial.
> than about implementing a complete custom graphical text rendering system specific to your app that butcher font files to put glyphs wherever you want?
It's not butchering anything. It is using the font data to render them in the way that fits the constraints of the output.
> That feels like cheating since you're not rendering provided font at that point.
Any font renderer makes just adjustments to make the font look as good as possible. That is the entire point of providing a scalable font instead of a bitmap font: That you can render the provided glyphs at any scale suitable.
Fitting the bounding box of the glyph to the bounding box of the cell the text is rendering into is entirely reasonable and the lesser of two evils when faced with a glyph that does not fit the cell, which is a relatively common occurrence, when the alternative is to clip.
It looks awful if you were to render e.g. latin script with a proportional font in a fixed grid, but for many scripts with more uniform widths the variation is a lot less, and so it's butchering things far less than rendering fallback glyphs for missing code points.
Considering the Chinese are one of the major contributors to AI, I would think this was a solved problem by now, at least in some other CLI based coding agent.
Aren't those non-ASCII "rich" symbols from Japanese fonts around PC-98/Win95 domains anyway? For me with my background, it was always obvious that mixing full-width character in ASCII text never go well for various reasons. For ASCII arts, it is obvious that vertical lines never line up, and there are going to be tons of wasted spaces and different kinds of whitespaces needed to compensate for those. I wonder if specifying MS Gothic and retuning widths for it could help, at least for Windows/Linux.
Funny you'd mention MS Gothic (fixed-width), since old school Japanese ASCII-art on image boards assume MS PGothic (proportional!) instead. Some sites even try to detect ASCII art and force font-family on that specific post.
Yup, 2ch.net/5ch.net/5ch.io uses the MS P Gothic and there were app features and fonts like Mona Font to emulate that. They were not imageboards, though.
I just thought that MS Gothic(non-P) should be kind of widely supported, have all the symbols you need, while also being a monospace, unlike most monospace fonts that only support ASCII symbols.
There is a couple of factors: openclaw's system prompt and instructions, I had to re read emails multiple times due to the issues mentioned in the blog, there was quite a bit of tinkering with the agent and the VPS, I was asking the agent to do more things (track the emails it has read in a csv file, for example), among others.
Chinese people have been developing similar obfuscation protocols and playing a cat-and-mouse game for years, and most of them are "open source" (in quotes because lots of them have to be somewhat hidden because the Chinese gov threatens the devs).
Props to Mullvad, but it's not like they're unique in this regard.
For tomatoes, interestingly, it has two common names that follow this pattern: 西紅柿, literally translated as "Western Red Persimmon", and 番茄, literally translated as "Foreign Eggplant".
Other produce examples include 番薯 (Foreign Yam) for sweet potato, 西瓜 (Western Melon) for watermelon, 洋蔥 (Foreign Onion) for bulb onion etc.
reply