July 30, 2011

iPhone Navigation a Bumpy Road

Filed under: Cars, Design, Software Blog, Travel — marcstober @ 10:45 am

Your Road Ahead
Photo credit: Trey Ratcliff on Flickr under a CC BY-NC-SA 2.0 license (thanks for sharing!)

I left behind my paper maps and GPS device on our recent trip to California, navigating with my iPhone 4 instead. We got where we needed to go, but the iPhone was limited and frustrating for a state-of-the-art smartphone.

We flew into northern California to visit relatives and attend a wedding, then drive along the coast to LA sightseeing. This meant we had to locate points of interest as specific as a San Francisco apartment and as vague as a spot along those coast where you can see elephant seals, and drive in LA traffic. I knew I’d need more than the built-in Maps app. Before the trip, I used TripIt and Google Maps on the web to store various destinations. For voice-guided navigation, I purchased NAVIGON MobileNavigator, which was expensive, but cheaper than either buying a new GPS device or even updating the maps on my old one. (I’d also tried the less expensive MotionX GPS Drive app around eastern Massachusetts, but it came up with some strange routes, which proved to me that all navigation apps are not the same.)

I also purchased NavAssist. If you have Navigon or TomTom apps, buy NavAssist. It’s only 99 cents and it lets you copy and paste addresses from other apps (including the native Maps app) into your GPS app. On the other hand, it’s ridiculous that there not a better way to share addresses designed into the iPhone. For example, to navigate to our hotel address saved in TripIt: open the record in TripIt, click to open the address in Maps, copy the address, paste into NavAssist, click to search then click to launch Navigon. This should not take so many clicks through 4 different apps!

My big disappointment came when I tried to view the customized map I’d saved in Google Maps. I’d dropped multiple pins on a map and planned to use that to see what I was near and decide what to visit next. I didn’t expect that the native Maps app (which isn’t really “Google Maps” even if it uses Google data) would support this, but I’d assumed I’d have all the functionality of the web-based Google Maps through the mobile web. It was not possible. The Google products are a confusing mix of “Maps,” “Local”, “Places,” and the Google Earth app. It is possible to view saved maps via Google Earth, but this is both too slow to use well without good WiFi, and doesn’t provide you with the sort of road and address data you need for driving navigation at all.

Fortunately, I’d printed out on a paper a list of the points of interest I’d saved in Google Maps. The native Maps app doesn’t support dropping multiple pins (or even a single pin precisely). I briefly tried free Bing and MapQuest apps before buying two more map apps: CityMaps2Go by Ulmon, and Map+ by Shinya Sugawara. I’d used Ulmon’s Paris guide app on another trip with much success, but it worked better for finding landmarks (like the Louvre and the Eiffel Tower and the closest subway stop) than for finding specific street address and driving to them. Finally, the 99 cent Map+ app was only thing I could find for dropping multiple pins on on a street map.

Maybe the developers of NavAssist and Map+ could get together and build an app that combines the ability to drop multiple pins with the ability to paste in addresses and launch a navigation app? Does it seem wrong that $300 of GPS hardware and software is made usable by $1.98 of apps? Has Apple restricted the functionality of map and navigation apps while it works on its own? I’d consider this a possibility, but I can’t do much else with a speculation of an unannounced product.

July 29, 2011


Filed under: Software Blog — marcstober @ 5:32 pm

Yet Another Article Comparing Software Development To Building A Bridge:

What Happened to Software Engineering? – Developer.com

This is just the latest one example; liberally paraphrasing, it’s always the same: ‘Bridge building is so cheap and easy, there’s no excuse for programming not to be even cheaper and easier.’

Seems to me this meme is an insult to both software developers and civil engineers. Then again, it’s mostly perpetrated by people who expect software and bridges to magically appear without paying for them. Or worse, by someone trying to sell technical products and services without hiring enough technical talent.

July 6, 2011

Fun With Hebrew Fonts: Liturgical Use of Meteg

Filed under: Judaism, Software Blog — marcstober @ 7:00 am

For the Family Service Siddur I’m editing, we set the Hebrew text in Times New Roman1 using Microsoft Word, because this was a volunteer project and we all had that software available, and because that font is actually quite nice at rendering Hebrew with vowels as needed for liturgy.

A reviewer noticed an error in Mah Tovu:

The quamats2 that should be under the resh is under the kaf. It’s not a typo; I had typed the letters correctly: kaf , shva , resh , qamats , meteg .

I realized the issue was with the meteg. (In liturgy, meteg is used to indicate the stressed syllable, particularly when it’s not the last syllable, which is usually stressed in Hebrew.) Without the meteg, the vowel is centered below the “point” of the resh, not the center of the letter:

So far, so good; this contributes to the readability of the letters. The problem is that Times New Roman shifts vowels to the right when followed by meteg. This is okay if the vowel starts off below the center of the letter:

But when the vowel is centered under right edge of the letter to start with, it ends up appearing under the previous letter, incorrectly. For example, the font Cardo doesn’t shift the vowel when a meteg is added, which I think is better:

It’s worth noting that not all Hebrew fonts even include meteg, which is not used in modern Hebrew.
I solved the problem using the overstrike feature of Word’s equation editor:

To reproduce this:

  1. Press ctrl-F9 to insert the special equation editor brackets.
  2. Paste in the following: eq \o(רָ,ˌ)

Note that the character used here is actually the Unicode MODIFIER LETTER LOW VERTICAL LINE character (hex 02CC), because Hebrew points without a consonant are rendered with a dotted circle by the software. I think this character is used as a phonetic symbol to indicate stress anyway, so it’s not inappropriate. However, I consider this a work-around; in a perfect world, I’d like to have an accurate digital text that renders into print without pretending it’s an equation.

Hope someone finds this helpful or at least interesting!

1This would be version 5.01 of Times New Roman from Microsoft. I’m pretty sure the original 1930’s version of the font for the London Times didn’t include Hebrew!

2I am not a not usually fan of the letter “q” in Hebrew transliterations, but I am using the standard Unicode names of Hebrew characters.