Windows Metafile
The Windows Metafile (WMF) is a vector and bitmap graphics file format developed by Microsoft for storing images in a device-independent manner within Windows operating systems, consisting of a header followed by an array of variable-length records that encode drawing commands and graphics objects.[1] Introduced in the early versions of Windows to support 16-bit applications, WMF enables the recording and playback of graphical output from the Windows Graphics Device Interface (GDI), facilitating tasks such as clipboard transfers, printing, and document portability.[2] WMF files are structured as a sequence of metafile records, each representing GDI function calls like line drawing, shape filling, text rendering, and bitmap handling, which collectively define the image content without embedding pixel data directly.[3] The format includes an optional placeable header for additional metadata, such as bounding rectangle coordinates and checksums, but lacks comprehensive details on device resolution, palettes, or text descriptions compared to later formats.[2] Due to its origins in 16-bit environments, WMF is device- and application-dependent, with playback influenced by mapping modes and resolutions, and it does not support advanced features like curves, paths, or transformations.[2] To address WMF's limitations, Microsoft introduced the Enhanced Metafile (EMF) format in the 32-bit era, which extends WMF with improved device independence, scalable records, and support for modern GDI functions; WMF files can be converted to EMF using API calls likeSetWinMetaFileBits.[2] Despite its age, WMF remains relevant for backward compatibility in Windows applications, legacy document processing, and interoperability with tools that handle vector graphics for plotting or archiving.[1] The specification has undergone multiple revisions, with the latest documented version (18.0) updated as of April 2024, ensuring ongoing support for core functionality in contemporary systems.[1]
Overview
Definition and Purpose
The Windows Metafile (WMF) is a binary file format developed by Microsoft for storing graphical images as a sequence of variable-length records containing Graphics Device Interface (GDI) drawing commands.[1] These records capture instructions for rendering vector elements, such as lines, polygons, and basic shapes, alongside support for embedded raster bitmaps, aiming for scalable output in a device-independent format, though playback can be influenced by device resolution and mapping modes.[4] In essence, a WMF functions as a digital recording of an image, which can be played back to reproduce the original graphics on compatible devices.[3] The primary purpose of the Windows Metafile format is to facilitate device-independent graphics rendering in Windows environments, particularly for output to printers and displays, by allowing applications to record and spool drawing operations without embedding hardware-specific details.[4] This portability ensures that the same set of GDI commands can be executed consistently across varied output contexts, simplifying the transfer of graphical content between applications and systems.[5] Metafiles emerged as a key solution to portability challenges in early GDI-based graphics APIs, where direct device calls risked incompatibility and limited reuse of visual data.[4] The original WMF uses the .wmf file extension, while the enhanced version employs .emf; the standard MIME type for WMF files is image/x-wmf. Over time, the format has evolved into Enhanced Metafile (EMF) and further extensions to enhance device independence and feature support.[6]Key Formats and Evolution
The Windows Metafile (WMF) format, introduced in 1987 with Windows 2.0, serves as the original 16-bit vector graphics format designed for storing sequences of Graphics Device Interface (GDI) commands in a device-independent manner.[1] It employs 16-bit signed integer coordinates, which restrict the drawable area to a range of -32,768 to 32,767 units, potentially limiting precision and scalability for larger or more detailed images.[3] This format was pivotal in early Windows applications for clipboard operations and printing but suffered from device dependencies and limited color support. To address these shortcomings, Microsoft developed the Enhanced Metafile (EMF) format in the early 1990s, debuting with Windows NT 3.1 in 1993 and Windows 3.1 via Win32s extensions.[7] EMF upgrades to a 32-bit structure, utilizing signed 32-bit integer coordinates for vastly improved precision and a larger addressable space, enabling better scalability across devices. It also incorporates enhanced device independence through bounding rectangles and reference device contexts, while supporting Unicode text via records like EMR_EXTTEXTOUTW, facilitating international character handling.[6] Building further on EMF, the Enhanced Metafile Plus (EMF+) format emerged in 2001 with the introduction of GDI+ in Windows XP, extending the EMF spool to embed GDI+ API calls for richer graphics capabilities.[8] EMF+ introduces support for alpha channels in bitmaps and brushes, allowing transparency and compositing effects, as well as gradient fills, texture brushes, and path-based rendering that emulate advanced features akin to those in modern graphics APIs.[9] Available in EMF+ Only mode for GDI+-exclusive content or Dual mode for backward compatibility with standard EMF records, it enables high-fidelity playback on systems supporting GDI+.[8] This progression reflects the evolution of Windows graphics: from the rudimentary WMF in the 1980s, constrained by 16-bit architecture; to EMF in the 1990s, prioritizing 32-bit scalability and portability; and culminating in EMF+ during the 2000s, which integrates sophisticated rendering for contemporary applications while maintaining interoperability.[5][6][8]History
Development of Original WMF
The original Windows Metafile (WMF) format appeared with the release of Windows 2.0 on December 9, 1987, as a core component of Microsoft's 16-bit Windows operating systems.[10] Developed during the mid-1980s, it formed an integral part of the Graphics Device Interface (GDI), Microsoft's foundational API for handling graphics output.[3] The primary design goals centered on enabling device-independent graphics operations, particularly for printing and clipboard transfers, by capturing graphical content in a portable manner that minimized information loss during scaling or device changes.[11] At its core, the WMF format was engineered by Microsoft to record sequences of GDI function calls, such as line drawing, shape filling, and text rendering, into a compact binary structure for later replay on any compatible output device.[1] This approach allowed applications to store vector-based images and bitmaps in a single file, supporting scalability without pixelation and facilitating interoperability across Windows environments.[11] The format used the METAFILEPICT structure for clipboard integration, enabling seamless copy-paste operations of graphics between programs while preserving editability through GDI playback. An extension known as the placeable metafile header, developed by Aldus Corporation around 1988 for use in PageMaker, added metadata like bounding rectangles and became widely adopted for improved portability.[10] Despite its innovations, the original WMF suffered from key limitations inherent to its 16-bit architecture, including the use of 16-bit integer coordinates that restricted image dimensions to a maximum of 16,383 units in each direction, leading to precision loss and distortion when scaling to high-resolution displays or printers.[12] Additionally, the initial version (METAVERSION100) lacked support for device-independent bitmaps (DIBs) and advanced font technologies, such as TrueType fonts—which were not introduced until 1991—resulting in reliance on device-specific rasterization for text and limited portability across font environments.[11] These constraints made WMF suitable primarily for simple 2D graphics but inadequate for complex or high-fidelity applications, prompting later enhancements like the Enhanced Metafile (EMF) to address such shortcomings. With Windows 3.0 in 1990, the format was updated to METAVERSION300, adding DIB support for better device independence.[11] Early adoption of WMF was driven by its native integration into Windows applications, particularly Microsoft's productivity tools, where it served as a standard format for embedding and exchanging vector graphics in documents. This widespread use in early Windows ecosystems solidified WMF's role, despite its technical constraints.[1]Introduction of Enhanced Formats
The Enhanced Metafile (EMF) format was introduced in 1993 as part of the Win32 API with the release of Windows NT 3.1, serving as a 32-bit successor to the original Windows Metafile (WMF) to overcome its 16-bit limitations in coordinate precision and device independence. EMF employs 32-bit fixed-point coordinates for improved accuracy in rendering scalable graphics across diverse display resolutions and devices, while also supporting long filenames through its enhanced file structure.[6] This format played a central role in the Win32 Graphics Device Interface (GDI), enabling developers to create portable, device-independent pictures that could be played back consistently via functions like CreateEnhMetaFile.[13] Building on EMF, the Enhanced Metafile Plus (EMF+) format emerged in 2001 alongside the GDI+ library in Windows XP, extending the EMF structure to incorporate advanced graphics features not feasible in the base format. EMF+ introduced support for cubic Bézier curves through records like EmfPlusDrawBeziers, enabling smoother vector path rendering, along with variable transparency (alpha blending) for more realistic compositions and optional compression of records to reduce file sizes and improve efficiency.[14] These enhancements addressed WMF's scalability challenges, such as imprecise rendering on high-DPI displays, by leveraging EMF's foundation for better vector fidelity and extensibility.[7] EMF+ achieved deeper integration with the .NET Framework by embedding GDI+ commands as private data within EMF comment records (e.g., EMR_COMMENT_EMFPLUS), allowing seamless playback in managed code environments without disrupting legacy EMF compatibility.[9] This milestone facilitated the transition to modern graphics programming in Windows applications, prioritizing device independence and performance for evolving display technologies.[15]Technical Structure
WMF Format Details
The original Windows Metafile (WMF) format is a binary file structure consisting of a fixed header followed by a sequence of variable-length records that encode graphics commands and objects. The core header, known as the META_HEADER record, spans 9 words (18 bytes) and provides essential metadata about the file. This header begins immediately after any optional placeable extension and is always the first required record in the metafile.[16] The META_HEADER structure is defined as follows:| Field | Size (bytes) | Type | Description |
|---|---|---|---|
| Type | 2 | WORD (16-bit unsigned) | Specifies the metafile type; value 0x0001 indicates a standard WMF.[16] |
| HeaderSize | 2 | WORD (16-bit unsigned) | Number of words in the header; always 9 for standard WMFs.[16] |
| Version | 2 | WORD (16-bit unsigned) | Metafile version; for example, 0x0300 corresponds to the Windows 3.0 implementation.[16] |
| SizeLow | 2 | WORD (16-bit unsigned) | Low-order word of the total file size in words.[16] |
| SizeHigh | 2 | WORD (16-bit unsigned) | High-order word of the total file size in words (combined with SizeLow to form a 32-bit value).[16] |
| NumberOfObjects | 2 | WORD (16-bit unsigned) | Number of graphics objects (such as brushes or pens) defined in the metafile.[16] |
| MaxRecord | 4 | DWORD (32-bit unsigned) | Size of the largest record in the file, measured in words.[16] |
| NumberOfMembers | 2 | WORD (16-bit unsigned) | Reserved field; must be 0x0000 and is unused.[16] |
EMF Format Details
The Enhanced Metafile (EMF) format represents a significant advancement over its predecessor, the Windows Metafile (WMF), by adopting a 32-bit architecture that enables greater precision and portability in graphical representations.[7] Unlike the 16-bit WMF, EMF records utilize 32-bit integer coordinates for logical units, supporting larger canvases and finer detail without device-specific dependencies.[6] This structure facilitates device-independent rendering, making EMF suitable for applications ranging from screen display to high-resolution printing. The EMF file commences with the EMR_HEADER record (type 1), which establishes the metafile's foundational parameters in a structured binary format. The record begins with an 8-byte prefix common to all EMF records: a 32-bit unsigned integer for the type (EMR_HEADER = 0x00000001) and a 32-bit unsigned integer for the total record size in bytes.[18] Following this prefix, the core header includes the rclBounds field (a RECTL structure specifying the smallest rectangle enclosing the image in logical units, inclusive-inclusive coordinates) and the rclFrame field (a RECTL structure specifying the reference device frame in 0.01 mm units, inclusive-inclusive coordinates), the device frame dimensions via the szlDevice field (a SIZEL structure in pixels), the millimeter units via the szlMillimeters field (a SIZEL structure also in 0.01 mm units, equivalent to 100 units per millimeter), and the RecordSignature field (a 32-bit value, ENHMETA_SIGNATURE = 0x464D4520 for standard EMF files).[19] This initial segment culminates at the file offset where the ASCII signature " EMF" (with leading space) appears, confirming the format. The full EMR_HEADER record extends beyond this core with additional fixed fields (such as metafile version, total bytes, and record count) and optional variable-length elements like a description string, totaling up to 108 bytes for the fixed ENHMETAHEADER plus extensions.[18]| Field | Type | Size (bytes) | Description |
|---|---|---|---|
| Type | ULONG | 4 | Record type identifier (1 for EMR_HEADER).[18] |
| Size | ULONG | 4 | Total size of the EMR_HEADER record in bytes.[18] |
| rclBounds (image bounds) | RECTL | 16 | Smallest rectangle enclosing the metafile picture, in logical units (inclusive-inclusive coordinates).[19] |
| rclFrame (reference frame) | RECTL | 16 | Reference device frame enclosing the metafile picture, in 0.01 mm units (inclusive-inclusive coordinates).[19] |
| szlDevice (device frame) | SIZEL | 8 | Dimensions of the reference device in pixels (width and height).[19] |
| szlMillimeters | SIZEL | 8 | Dimensions of the reference device in 0.01 mm units (width and height, providing 100 units per millimeter for metric scaling).[19] |
| RecordSignature | ULONG | 4 | Signature identifying the format (e.g., 0x464D4520).[19] |
EMF+ Format Details
EMF+ metafiles maintain compatibility with the EMF format by beginning with a standard EMF header record, immediately followed by an EMR_COMMENT_EMFPLUS record that signals the presence of embedded EMF+ data.[9][21] This comment record uses the identifier 0x2B464D45, representing the ASCII string "EMF+" in little-endian format, to identify the subsequent data as EMF+ private content.[21] The EMF+ private records reside within the CommentRecordBuffer of the EMR_COMMENT_EMFPLUS record, starting directly after the 4-byte CommentIdentifier and typically beginning at an offset of 40 bytes from the end of the EMF header in practice due to the fixed structure of initial fields.[21][22] The first such record is the EmfPlusHeader, which defines key metadata for the EMF+ section, including the version (an EmfPlusGraphicsVersion value such as 0xDBC01002, corresponding to GraphicsVersion1_1 for GDI+ version 1.1), EmfPlusFlags (for example, 0x00000001 indicating no color correction or video display reference), and the total size of the EMF+ data in bytes.[22][23] The EMF+ portion optionally employs compression for its data payload, often via embedded structures like the EMR_COMMENT_EMFPLUSHEADER mechanism, which allows compact representation while supporting native 32-bit floating-point coordinates for precise positioning and transformations in drawing operations.[24] Subsequent EMF+ records are enumerated in a sequential description table within the private data buffer, where each entry specifies the record type, offsets from the buffer start, data sizes, and processing flags to enable selective rendering—such as skipping unsupported records based on size fields or processing only essential EMF fallback commands.[9][22] Overall, EMF+ integrates with EMF by encapsulating GDI+ commands and objects within these comment records, enabling enhanced graphics features like alpha blending and gradients while providing a complete EMF subset for fallback rendering on systems lacking GDI+ support.[9][15]Records and Operations
Bitmap and Drawing Records
In Windows Metafile (WMF) format, bitmap records such as BITMAP16 (record function number 0x000B) enable the loading and definition of device-independent bitmaps (DIBs) using 16-bit parameters, including fields for bitmap type, width, height, planes, bits per pixel, and raw pixel data, which can also create pattern brushes for subsequent drawing operations.[11] In contrast, the Enhanced Metafile (EMF) format uses records like EMR_STRETCHDIBITS (type 0x00000051) to transfer and scale DIB pixels to a destination rectangle, supporting optional stretching, compression, and integration with brush patterns for more precise raster output.[25] These bitmap records in both formats incorporate raster operations to combine source data with the destination surface, such as SRCCOPY (0x00CC0020), which directly copies the source bitmap, and PATCOPY (0x00F00021), which applies the current brush pattern, often with clipping to the current device context bounds.[26] Drawing records in WMF and EMF handle vector primitives by rendering lines, polylines, and arcs using the current pen for outlines, with fills implicitly applied via the selected brush where applicable, such as in closed shapes. In WMF, the LINETO record (0x0079) draws a straight line from the current position to specified 16-bit coordinates using the current pen, updating the position accordingly.[11] The POLYLINE record (0x0325) extends this to multiple connected segments defined by a count of points and their 16-bit X-Y coordinates, again relying on the pen for rendering without filling.[11] For curves, the ARC record (0x0817) draws an elliptical arc within a bounding rectangle specified by 16-bit coordinates, using start and end radial points to define the sweep angle in device units, with the pen for the outline and brush for any chord or pie fill if selected.[11] EMF improves precision in these operations with 32-bit integer coordinates and floating-point support for angles. The EMR_LINETO record (type 0x00000036) performs a similar line draw to its WMF counterpart but uses a single 32-bit point for the endpoint.[27] EMR_POLYLINE (type 0x00000024) renders connected lines from an array of 32-bit points, maintaining compatibility with WMF while enhancing scalability for higher resolutions.[28] Likewise, EMR_ARC (type 0x0000002D) defines arcs via a 32-bit bounding rectangle and start/end angles in logical units, applying the current pen for the curve and supporting brush fills for enclosed regions like sectors.[29] Across both formats, these records assume prior selection of pen and brush states, ensuring that line styles, widths, colors, and fill patterns are applied consistently during playback without explicit recreation in the primitive itself.[3][20]Object, State, and Escape Records
In Windows Metafile (WMF) and its enhanced variants, object records manage the creation and selection of graphics resources such as brushes, pens, and fonts, which are stored in an object table for reuse during playback. The CREATEBRUSHINDIRECT record in WMF, identified by function number 0x02FC, creates a logical brush defined by a LogBrush structure specifying the brush style (e.g., solid, hatched), color reference, and optional hatch pattern.[11] This record includes a fixed-size header with the record size and function identifier, followed by the LogBrush data, enabling device-independent brush definitions.[11] In the Enhanced Metafile (EMF) format, the equivalent is the EMR_CREATEBRUSHINDIRECT record (type 0x00000027), which uses a LogBrushEx structure to support additional attributes like texture bitmaps and gamma correction for more precise rendering.[30] Selection of these objects into the active device context is handled by the SELECTOBJECT record, common to both formats with function/type 0x012E in WMF and type 0x00000025 in EMF. This record specifies an object index from the metafile's object table or a stock object identifier (e.g., NULL_BRUSH), activating it for subsequent drawing operations without recreating resources.[11][31] The ihObject field in EMF provides a 32-bit index, supporting up to 64K objects, while WMF uses a 16-bit handle for efficiency in older systems.[31][11] State records preserve and restore the device context configuration, allowing complex drawing sequences to revert changes without reapplying all prior settings. In WMF, the SAVE_DC record (0x001E) pushes the current state onto a stack limited to 16 levels, capturing attributes like transformation matrices and clipping regions.[11] The corresponding RESTORE_DC record (0x0127) pops states from this stack using a signed 16-bit offset (nSavedDC), where negative values indicate relative restoration and positive ones absolute levels.[11] EMF mirrors this with EMR_SAVEDC (type 0x00000021), which has no parameters and appends the state to an unbounded array, and EMR_RESTOREDC (type 0x00000022), which uses a 32-bit integer for the saved state index to enable deeper nesting.[32] Mapping modes, which define how logical coordinates map to device coordinates, are set via dedicated state records to support anisotropic scaling and orientation. The WMF SETMAPMODE record (0x0103) accepts a 16-bit mode value, such as MM_ANISOTROPIC for arbitrary X/Y scaling or MM_ISOTROPIC for equal units, influencing subsequent coordinate interpretations.[11] EMF's EMR_SETMAPMODE (type 0x00000011) uses the same enumeration but integrates with floating-point world transformations for higher precision in modern graphics pipelines.[32] Escape records provide a mechanism for vendor-specific or device-dependent extensions, bypassing standard GDI operations. In WMF, the ESCAPE record (0x0626) includes a 16-bit escape function code (e.g., NEWFRAME for page ejection) followed by a byte count and variable data payload, allowing printer-specific commands like aborting jobs.[11] EMF extends this with EMR_EXTESCAPE (type 0x0000006A), supporting enhanced functions such as EXTTEXTOUT for advanced text output, where the EscapeFunction field identifies the operation and cbEscData specifies the data length.[33] Resource management is completed by deletion records to prevent memory leaks during playback. The WMF DELETEOBJECT record (0x01F0) removes a specified object from the table using its 16-bit handle, freeing associated resources like bitmap memory.[11] In EMF, EMR_DELETEOBJECT (type 0x00000028) uses a 32-bit index for the same purpose, ensuring compatibility with larger object tables and supporting selective cleanup in nested contexts.[30]| Record Category | WMF Record (Function) | EMF Record (Type) | Key Purpose |
|---|---|---|---|
| Object Creation | CREATEBRUSHINDIRECT (0x02FC) | EMR_CREATEBRUSHINDIRECT (0x00000027) | Define brushes with style, color, and patterns |
| Object Selection | SELECTOBJECT (0x012E) | EMR_SELECTOBJECT (0x00000025) | Activate object in device context |
| State Save/Restore | SAVE_DC (0x001E) / RESTORE_DC (0x0127) | EMR_SAVEDC (0x00000021) / EMR_RESTOREDC (0x00000022) | Stack-based context preservation |
| Mapping Mode | SETMAPMODE (0x0103) | EMR_SETMAPMODE (0x00000011) | Set coordinate transformation mode |
| Escape | ESCAPE (0x0626) | EMR_EXTESCAPE (0x0000006A) | Device-specific extensions |
| Object Deletion | DELETEOBJECT (0x01F0) | EMR_DELETEOBJECT (0x00000028) | Free graphics resources |