I now have a reply back from the author or WinAPRS on support for ESRI world files. He is working on it, but has one last problem to figure out before it will work. In researching the standard, I came upon an old problem I learned about many years ago, but which never spent the time to find the proper solution for.

While the full-blown GeoTIFF raster image format includes not only the basic georeferencing information but the projection, datum, and units. The commonly used ESRI-created World File (.jpw for JPEG images) lacks the latter three items, and includes only pixel size, image rotation, and origin.

So, when using a world file with a JPEG, GIF, PNG, or other image that lacks the georeferencing capabilities of GeoTIFF, you must also use a projection file (.prj) that includes all this missing information. This has also been defined by ESRI, and has had several flavors over the years. The original format was a multi-line one, used by Arc/Info 7.x, but that has been replaced by a new .prj format originally defined by the OpenGIS consortium as the Well-Known Text (WKT) format, and has since been revised slightly by ESRI, and it’s not clear if WKT has been updated to match the ESRI changes.

But guess what? The National Weather Service doesn’t include a .prj file with its georeferenced weather radar images. And now that I know about this little item, I suspect that most of the so-called georeferenced files floating around are also lacking this important metafile.

I’m currently looking for a better way of mounting a number of different gadgets to my car, including my iPod, two ham radio remote heads, my Garmin eTrex GPS, and perhaps a few more. Since many of these devices will be upgraded over time, I need any mounting system to be standard enough and interchangeable enough to make this a no-brainer. It appears that there are at least two standard mounting systems that would help me—the AMPS and NEC mounting hole patterns. These are common on many of the mounting brackets on the market, including those from Pro-Fit International, Panavise, and RAM Mounts. Some have both, though the AMPS pattern is more common.

It’s not just these three companies that use AMPS—it is found on some GPS navigation systems (Magellan, at least), many XM radios, and many automotive mobile phone mounts.

Yet despite knowing part of the AMPS specification (a rectangular hole pattern measuring 1.496 by 1.181 inches on-center), I can find no verification or definition of the standard; nothing that comes close to a citable source or reference document. I asked Pro-Fit International’s product designer (co-incidentally a fellow ham) about this, and he knows that it was a Motorola-originated standard, but has never seen a specification either. And there is no agrement on the spacing, either. One drawing from RAM Mount Systems shows 1.50″ × 1.188″ with a hole diameter of 0.218″, and nowhere can I find any mention of what size screw or bolt and thread count is to be used when designing female threads into a device.
AMPS appears to be a long-lived mounting system for the mobile electronics industry, but with no technical documents to reference, its specifications and existence seem to get passed around by word of mouth. This is insane. And it has now become one of the acid tests for CADJournal. If you make a product designed to go in a car—or a CAD tool used to design them—that I wind up reviewing, support for the AMPS pattern (along with other interface standards) will be one of the items I grade on.

Today’s task is something that should be simple–I have our radio club logo in vector form as an Illustrator CS2 image (with nothing but vectors, arcs, and text) and need to a scalable vector version that can be used in applications such as PowerPoint. Windows’ Enhanced Metafile (EMF) is the perfect choice for this, since it can support all of these drawing elements correctly, and with 32-bit precision.

WMF, the older 16-bit Windows Meta File standard from Windows 3.1, is not as capable, and is not capable of rendering the line joins correctly, and doesn’t even support arcs and circles. The Windows 95 version of WMF does support arcs and circles, but is still problematic.

Exporting the logo from Illustrator is easy enough, with the Export command. And using Windows XP’s Preview feature in Windows Explorer shows the result to be a perfect copy of the Illustrator file. However, when placing that EMF in Word or PowerPoint (Office XP), the line joins are incorrectly beveled, making the logo ugly and incorrect.

One problem with Illustrator is that it doesn’t let you choose between the two flavors of EMF–the original GDI based EMF from Windows 2000, or the enhanced GDI+ based EMF from Windows XP.

Since Windows XP’s image preview handles the EMF logo just fine but the Office XP applications don’t, I’m fairly confident that the problem lies with Microsoft’s code, not Adobe’s.

There needs to be a reliable way to include high-quality, scalable company logos in a wide range of software that design firms use in their communication and marketing efforts. For at least the Windows platform, this means EMF, so let’s get this right folks!

To borrow a phrase from a former co-worker and tech editor of mine, the Mobile Web “sucks dead bunnies”. Unlike other technologists who believe that WAP was a solution looking for a problem, I’m a firm believer that just reformatting Web pages designed to be used on desktop and laptop computers is not sufficient for providing a fully useful Internet experience to PDAs and mobile phones.

What went wrong, and must be fixed to make the Mobile Web happen for more than just those with deep enough pockets to tie themselves in with the carriers? Something very simple called content negotiation. Every WAP browser I have ever tried makes the same fatal error of claiming to support both (X)HTML and WAP in the header they send to Web servers, and not specifying a preference. When visiting a server that is properly configured for content negotiation with both (X)HTML and WAP pages, the server will properly send the higher-quality file–the desktop (X)HTML one–that most mobile phones can’t handle (either in a usable manner or more oftent not at all). This is relevant for anyone involved in the CAD or design markets because of the coming of SVG and location-based services to mobile phones. Before these can be widely deployed though, this fundamental (and extremely easy to fix) flaw must be corrected.

So the acid tests begin now. My latest site, PDAcritic.com, is properly configured with most pages available in both XHTML and WAP versions. All of the content there fully complies with the IETF and W3C standards, so if a desktop browser (sorry, Microsoft) or WAP browser (sorry, Nokia, Motorola, Samsung, SonyEricsson, et. al.) can’t even load the site, don’t blame me–ditch that browser and go find one that works.

I’ll provide updates as I test browsers, phones, and PDAs for compatibility with this and other technologies of interest to this community. And you’ll know who the winners and losers are, because I’ll be handing out letter grades that won’t pull any punches. Sony Ericsson is the first, and their S710a earned a D−.

I have long been a fan of the Mozilla browser, ever since the Netscape browser nearly died, spinning off the open source Mozilla foundation in the process. Since well before version 1.0, it has been a better browser than Internet Explorer

But the Mozilla Suite will not be developed further. The Mozilla Suite was a hold-over from the days of Netscape communicator, which was focused on being an alternative to Microsoft’s Outlook integrated calendar/E-mail client, and while I and many others loved the integration, it made updating just the browser or just the E-mail features problematic because the whole suite had to be updated, tested, and launched.

With the overwhelming success of the Mozilla Firefox browser—a lean, mean, fighting machine, the Mozilla Foundation developers have decided to put the Suite on life support. Future enhancements will consist of bug fixes, security patches, and perhaps an occasional update of the core rendering engine.

So the main development focus has switched to the stand-alone applications—the Firefox browser, Thunderbird E-mail client, and Sunbird Calendar. There are enough differences in the interface between the integrated suite and the individual applications that I’ll be relearning and lamenting the death of the suite for a little white, but I think the end result will be far better in the end.

In fact, because of the coming integrated support for SVG in version 1.1, I’ll soon be making Firefox the target browser I design this site for. Users of IE and older versions of Mozilla will find some pieces of content missing or duplicated, but it’s time to leave the old browsers in the history books.

Especially for anyone in any of the design industries.