There’s a distinct style of typesetting in Japanese software, particularly videogames, where the English text looks terrible. Like they use the same two fonts (one serif, one sans) from 1982 and they’re typeset wrong. Even in new software, like the brand new Monster Hunter World game. Chinese and Korean software often has the same problem. Why does CJK software do such a bad job with English text?
I found some sources online and they describe several kinds of problems:
Font availability. Your Japanese (or Chinese, or Korean) computer won’t have many fonts that support both your language and Roman characters. So you use the ones that are there. They look fine in your language so you don’t care much if they look awful in Roman. MS Mincho or SimSun for example. It’s a bit like how so much stuff is done in Arial or Microsoft’s Times New Roman. They aren’t great, but they are present.
Typesetting ascenders and descenders. The way Roman characters have a middle weight and then go above that (say the letter d) or below that (p) is a distinctive aspect of American font design. CJK characters don’t do that, they have a totally different shape. Descenders in particular often get squeezed in Japanese fonts for Roman characters.
Mismatched aesthetics. Roman fonts have Serif and Sans-Serif fonts. Japanese has Mincho and Gothic. But while Mincho fonts often make the Roman characters have serifs, there’s no real commonality in design there at all.
Halfwidth Roman characters. Old computers used fixed width character displays. Typography pretty much always looks awful this way. But on top of it in a CJK writing system most characters use a full width cell but it’s two wide for Roman letters, so you squeeze in two half-width characters instead.
None of these issues prevent a Japanese or Chinese or Korean company from producing excellent English typesetting. But if you’re used to seeing badly typeset Roman characters all the time in your daily computer work, it won’t stand out at you so badly when someone is finally localizing your product to America or Europe and they start translating the menus in the fastest, cheapest way. At least that’s my theory.
I’m really glad I chose to use Dexie as my interface for IndexedDb storage in browsers.
Mostly it’s just really professionally packaged. The docs are great. The basic API is very simple to use. Where things get complicated they make right choices. Like bulkAdd() will abort if you’re inside a transaction and try to add on top of some duplicate keys unless you explicitly override that. But outside of a transaction it’ll just do its best to add data that doesn’t conflict and log a warning.
It also has nice support for schema migration. I haven’t stressed this too hard, but adding new columns works nicely and transparently for users. It has simple support for writing custom migration functions, too.
Dexie supports some fairly complex interactions with the database. All I’ve had to do is simple things and I appreciate that simple things are simple. But it looks good for doing complicated things, too.
If the data is 100 records it takes 4000-5000ms to complete. 10 records takes about 400-500ms. So much for batch deletion.
Exacerbating this we had a bug where I was trying to delete 60,000 records at once. This hangs for a very long time and then returns with an error that the operation is too big. Also there was a second bug where we were executing several requests in parallel. This does seem to work but isn’t a good idea. Chrome crashes outright (Oh, Snap) if 26 requests are running in parallel. Firefox didn’t crash but other bad things happened.
So now I’m deleting 60,000 records, 100 at a time every 5 seconds. That’ll be most of an hour.
Working on adding data import to my Wanderings project so I can bring in data from other trackers. I have 6 years of data from OpenPaths. And when I imported it the first time I got so much joy out of seeing it again. Particularly trips to India and France.
Our Wanderings project uploads location fixes with the iOS significant location changes APIs. It includes an accuracy number, distance in meters, and occasionally we get points with accuracies > 1000m. We’re about to stop displaying those, but before I do here’s what the data looks like:
That shows most points have an accuracy of 10m, a significant number have an accuracy of 65m, and a few have 1414m. This histogram tool is misleading, there are also 15 points with an accuracy > 1414m. (Shout out to 7094 meters; you did your best, little iPhone).
If I had to guess, I’d say 1414m means “location from a single cell tower” and 65m means “location from a single wifi access point”. But who knows. It’s possible to ask the iPhone to give you more accurate fixes, we’re deliberately only using the most low power location monitoring to conserve battery life.
I wanted to do some simple unit testing in a Browser context; no NodeJS. I decided to use Mocha and Chai, then found it remarkably difficult to figure out how to just get it working without a bunch of complicated setup.
I finally figured it out: demo here. It’s pretty simple really, grab the CSS and JS from a CDN, then write the tests.
Boy there’s a lot of stuff in these frameworks. Mocha + Chai is literally 26k lines of code, 820k bytes. Minified it’s more like 300k but that’s still huge. I see why folks like tape instead. I wasn’t sure tape really supports running in a browser though.
My friend Brad and I launched Wanderings, a simple location tracker app for iPhone and Web. Put it on your phone and forget about it, come back a few weeks later to have a nice heatmap of where you’ve been. It was inspired by the late lamented OpenPaths. See also Google Timeline, which is much fancier but doesn’t have a heatmap.
I was inspired to start working on this while traveling in Berlin. I just want to know where I’ve been, you know? I don’t know anything about building iPhone apps but fortunately Brad does.