EazyDraw Store Support Contact SiteMap
Newest Version File Format LinkBack UTI Lost License Feature Request Download Public Beta Discussions
Universal Type Identifier
UTI: com.dekorra.eazydraw - - - Creator Code: 'dkra':
UTI: com.dekorra.eazydraw.graphic - - - File Type: 'ezdw'
com.dekorra.eazydraw.binary - - - File Type: 'ezdt'
com.dekorra.eazydraw.libtext - - - File Type: 'ezlt'/td>
com.dekorra.eazydraw.libbinary - - - File Type: 'ezlb'
File Typing, a Brief History

File typing has been a problem for software developers and users since the first box of punch cards had a job name with processing codes scribbled across its top. The Classic Mac OS used two 32-bit integers, usually expressed as four-character codes to identify a type and creator code. While this naming space or set of addresses filled up over a decade or so, other operating systems used a less defined convention of identifying a type with a dot and three letter extension. In 2001 Apple took a "Next Step" and changed from type and creator to dot/extension with the expansion from 3 letters to unlimited number of letters. The transition necessitated by co-existence of the Classic OS 9 and OS X as well as Carbon, Cocoa, and even Unix heritage applications caused a great deal of confusion for developers and users. This prevented a smooth and uniform adoption of extended extension typing. The primary reason for adopting file name extensions as stated by Mr Jobs at the 2001 developer's conference was because the other operating systems used the approach. That apparently didn't work out.

Over this same period a system called MIME types have been used primarily for MIME-encapsulate or tagged data for Safari and Mail. This system is partially supported by OS X and info.plist for application bundles. But extended MIME attributes were needed to properly use this convention for typing and application bundles did not support the information. MIME is really a non-starter for file format typing and was not really adopted in the OS X environment.

Now, with a little less fan-fare, Apple OS X is moving to a more "thought out" typing solution, called Uniform Type Identifiers (UTI - but don't google just UTI as that will take you to your Urologist's home page). As of OS X version 10.4 UTI's seem to take preference for most Finder decisions and they are core to the Spotlight technology. This page is EazyDraw's developer's (and power user's) reference for the Universal Type Identifiers used by EazyDraw.

Uniform Type Identifiers

The broad definition of a UTI is a system to "uniquely identify a class of entities considered to have a type". This is the "broad" definition. We are interested primarily in file formats or data on the OS X file system and pasteboard. As technology evolves this system will likely expand to other identifiably typed entities such as disk volumes, folders, and symbolic links.

UTIs are designed to go beyond the limitations of name extensions and type / creator codes. They are unique, using a simple system based on registered internet domain names. UTIs have no restriction on length, lifting confusion of 3 letter conflicts and if desired they can be human readable and translated to provide readable clarity in several languages. They are Extensible, a well defined system is provided for adding new types and extending or collapsing a definition scope. A clear hierarchy can be used to define new types as sub-types of other defined types. And all this can be accomplished safely with or without the blessing or registration of an organizing body or controlling corporate interests such as the Adobe domain over the PDF format.

Ground Rules

A UTI is a text string that can contain numbers, letters, hyphens, and periods, plus any Unicode characters above the ASCII range. Standard types have a "public." prefix. In our world only Apple can define the "public." identifiers. Some that they have specified are: "public.data" (top/root of the tree), "public.text", "public.image" etc. See the diagram above to better understand the relationships.

A unique name for a file type is constructed by reversing a registered domain name. For EazyDraw this involves our historic corporate identity "Dekorra Optics, LLC" which leads to the designation "com.dekorra.eazydraw.xxxx" for EazyDraw file types. We have four formats. Two are human readable formats which are based on Apple pList and two are more compact binary formats base on Cocoa data archiver. This leads to the UTI's which we define: "com.dekorra.eazydraw.graphic", "com.dekorra.eazydraw.binary", "com.dekorra.eazydraw.libtext", and "com.dekorra.eazydraw.libbinary". The first two are the plist and binary formats for EazyDraw drawing files. The last two are the plist and binary formats for EazyDraw drawing element libraries. These four types are registered with OS X and the Finder by appropriate entries in the EazyDraw application bundle, info.plist file. The diagram at the top of this page shows this information in graphic form.

Continuing Saga

As of this update (November 2007), Apple is again registering Creator Codes. Previously OS X developers were instructed to use file extensions, and not to rely on Creator and Type codes. There was still "back door" access to these codes on the OS X file system and EazyDraw has used the Creator Code 'dkra' since 2001 on OS X version 10.2 to provide continued to support Creator and File Type codes - "just in case...". With Apple's new registration policy, 'drka' is not a legal Creator Code as the Apple web site will not accept all lower case ASCII characters as a legal Creator Code. We have therefore registered 'DKRA' as the registered Creator Code for EazyDraw. EazyDraw will not attempt to switch from 'dkra' to 'DKRA' unless we see actual issues with future versions of OS X.

With this note we repeat the opening comment. File typing has been a problem for software developers and users since the first box of punch cards had a job name with processing codes scribbled across its top.


The Leopard release with Quick Look, Cover Flow, and Spotlight all seem to key from the UTI registration information with fall back to Creator Codes. We have test all of these functions on virgin OS X installations and the current EazyDraw pList is found to provide the right linkage for file opening, icon presentation, and the Quick Look drivers.

The EazyDraw application provides icons and assignment information for MacDrawII, MacDrawPro, ClarisDraw drawings, ClarisDraw libraries, AppleWorks *.cwk files and the AutoCad *.dxf files. The icon files for these drawing types are identified to OS X in our pList file and the icons (*.icns) are bundled with the application. This means that these file types, which are identified by OS X by Creator Codes, will show in the Leopard Finder even if these creator application has never been installed on the system.

Other Creator Codes:

The EazyDraw application identifies these additional creator codes for the benefit of the full OS X installation. The file types are identified and corresponding uti records are provided to enable Cover Flow and Quick Look to display the correct classic icon. TThis linkage allows the Finder to automatically identify EazyDraw as a valid reader of these file. The information provided by EazyDraw should not prevent a user from identifying another application as the primary supporter for a particular file type.

MacDraw II: drw2.
MacDrawPro: drw6.
ClarisDraw: dDrw.
ClarisDraw - Japanese version: dDrJ.
ClarisDraw library file: iLib.
MacDrawPro: dDoc.
and AppleWorks: BOBO.

This web page designed, created and published entirely with BBEdit and EazyDraw.
EazyDraw, a Dekorra Optics LLC enterprise
Contact: ph +1 608 444 5245 fax: +1 608 635 2124 mail: N5040 Beach Garden Road, Poynette, WI USA.
Copyright 2011, All rights reserved.