Loading AI tools
Windows Metafile (WMF) is an image file format originally designed for Microsoft Windows in the 1990s. The original Windows Metafile format was not device-independent (though could be made more so with placement headers) and may contain both vector graphics and bitmap components. It acts in a similar manner to SVG files. WMF files were later superseded by Enhanced Metafiles (EMF files) which did provide for device-independence. EMF files were then themselves enhanced via EMF+ files.
Essentially, a metafile stores a list of records consisting of drawing commands, property definitions and graphics objects to display an image on screen.[1] The drawing commands used are closely related to the commands of the Graphics Device Interface (GDI) API used for drawing in Microsoft Windows.
There are three major types of metafiles – a WMF is a 16-bit format introduced in Windows 3.0. It is the native vector format for Microsoft Office applications such as Word, PowerPoint, and Publisher. As of 2023[update], revision 17 of the Windows Metafile Format specification is available.[2] EMF files, which replaced WMF files, work on the same principle only it is a 32-bit file format that also allows for the embedding of private data within "comment" records.[3] EMF+ is an extension to EMF files and embedded in these comment records, allowing for images and text using commands, objects and properties that are similar to Windows GDI+.[4]
The original 16 bit WMF file format was fully specified in volume 4 of the 1992 Windows 3.1 SDK documentation[5] (at least if combined with the descriptions of the individual functions and structures in the other volumes), but that specification was vague about a few details. These manuals were published as printed books available in bookstores with no click through EULA or other unusual licensing restrictions (just a general warning that if purchased as part of a software bundle, the software would be subject to one).
Over time the existence of that historic specification was largely forgotten and some alternative implementations resorted to reverse engineering to figure out the file format from existing WMF files, which was difficult and error prone.[6] In September 2006, Microsoft again published the WMF file format specification in a more complete form[7] in the context of the Microsoft Open Specification Promise, promising to not assert patent rights to file format implementors.[8]
Microsoft later deprecated WMF files in favour of 32-bit EMF files as WMF files had real issues with device independence, despite the use of a "placeable" file header which provided basic device independence. Microsoft found that developers who use the format were "[embedding] application, location, or scaling comments in the metafiles... Others added headers to the metafile that provided various application-specific information", causing major compatibility issues.[9] Thus, in 1992 with Windows NT 3.1, Microsoft introduced the Enhanced Metafile format (EMF)[10] — a format which was based on the Win32 API and with which they built-in device independence.[11][9] — these were also known as NT metafiles.[12] With the release of Windows XP and GDI+, the set of records had to be significantly increased and so Microsoft released EMF+ as an extension to the existing EMF file format.[10][13]
WMF, EMF and EMF+ files all consist of a series of records that are played back to produce graphical output. Some records define objects which can specify graphical objects used to determine how graphics should be drawn (e.g. pens specify the color and width of lines). Each of these objects are stored in metafiles and are placed into an object table, which tracks the usage of graphic objects while processing the metafile. The object table is an associative array of indexes to graphical object structures defined within the metafile.
WMF and EMF files handle object processing differently to EMF+ records in EMF files. As a WMF and EMF file is being processed, the records are read into an object table once an object is defined. If an object is deleted then the object is released from the table and the identifier can be reused. Notably an object will not be used until it is specifically selected during record playback.[14][15] This differs for EMF+ files, which also use an associative array via a hashmap which records the object along with an object identifier. However, unlike WMF and EMF files which can delete an object, when a new object is created that has the same index as an existing object, the entry in the table is replaced with the new object. An EMF file also does not need to specifically select an object before it is used.[16]
WMF
| Filename extension |
.wmf |
|---|---|
| Internet media type |
image/wmf[10] |
| Uniform Type Identifier (UTI) | com.microsoft.wmf[10] |
| Type of format | Vector graphics |
| Extended to | EMF |
WMF files were not originally designed to be device independent, meaning that a file could not be played back on output devices that differed from the original device on which the file was recorded. A partial solution to this issue was invented by Aldus Corporation, who added an additional "placeable" header, called the "APM header",[18] which added a bounding rectangle, a metafile version, metafile size, number of objects in the metafile and the size of the largest single record in the metafile.[19][20] This was later incorporated into the WMF format by Microsoft, starting in Windows 2000.[21]
WMF files are structured by a series of records, starting with a number of control records: the header record,[19][22] the aforementioned optional placeable record,[23] and finished by an end of file record.[19][24]
Encapsulated by the control records are the records that make up the image itself. These records work within what is known as the playback device context, which is the collection of properties and objects that make up a device's graphical environment as the metafile is being "played back" onto this output device.[25]
Records other than control records can be largely grouped into bitmap records, drawing records, object records, state records and escape records.
Bitmap records
Bitmap records manage and output bitmap images.
| Name | Description |
|---|---|
| META_BITBLT | Specifies how to do a bit block transfer. These records can specify a bitmap to use as the source, or a region.[26] |
| META_DIBBITBLT | Specifies how to do a bit block transfer of a device-independent bitmap image. These records can specify a bitmap to use as the source, or a region.[27] |
| META_DIBSTRETCHBITBLT | Specifies how to do a bit block transfer of a device-independent bitmap image, but allows for expansion or contraction of the image. These records can specify a bitmap to use as the source, or a region.[28] |
| META_SETDIBTODEV | Specifies color to set a block of pixels in a device-independent bitmap image. These records can specify a bitmap to use as the source, or a region.[29] |
| META_STRETCHBLT | Specifies how to do a bit block transfer, but allows for expansion or contraction of the image.[30] |
| META_STRETCHDIB | Specifies how to do a bit block transfer of a device-independent bitmap image, but allows for expansion or contraction of the image. These records can specify a bitmap to use as the source, or a region.[31] |
Drawing records
Drawing records produce graphics output.
| Name | Description |
|---|---|
| META_ARC | Draws an elliptical arc.[32] |
| META_CHORD | Draws a chord.[33] |
| META_ELLIPSE | Draws an elliptical arc.[34] |
| META_EXTFLOODFILL | Fills an area with a brush.[35] |
| META_EXTTEXTOUT | Draw text with font, background color and text color of the playback device context.[36] |
| META_FILLREGION | Fills a region with a specified brush.[37] |
| META_FLOODFILL | Fills an area with a brush.[38] |
| META_FRAMEREGION | Draws a border around a region of the page with a brush.[39] |
| META_INVERTREGION | Paints a region of the graphic with inverted colors.[40] |
| META_LINETO | Draws a half-open line from the drawing position defined in the playback device context to a specified point.[41] |
| META_PAINTREGION | Paint a region with the current brush specified in the playback device context.[42] |
| META_PATBLT | Paint a region with the current brush specified in the playback device context and then combine the brush color and surface color(s) using a raster operation.[43] |
| META_PIE | Draw a pie-shaped wedge bounded by the intersection of an ellipse and two radials — the line is set via the pen set via the playback device context, and the area bounded by the pie shape is filled in by the current brush of the playback device context.[44] |
| META_POLYLINE | Draws a series of line segnments by connecting the points in a specified array.[45] |
| META_POLYGON | Paints a polygon consisting of two or more vertices connected by straight lines. The polygon is outlined by using the pen and filled by using the brush and polygon fill mode that are defined in the playback device context.[46] |
| META_POLYPOLYGON | Paints a series of closed polygons, which may overlap. Each polygon is outlined by using the pen and filled by using the brush and polygon fill mode that are defined in the playback device context.[47] |
| META_RECTANGLE | Paints a rectangle, which is outlined by using the pen and filled by using the brush and is filled by using the brush that is defined in the playback device context.[48] |
| META_ROUNDRECT | Paints a rectangle with rounded corners. The rectangle is outlined by using the pen and filled by using the brush and is filled by using the brush that is defined in the playback device context.[49] |
| META_SETPIXEL | Sets the pixel at the specified coordinates to the specified color.[50] |
| META_TEXTOUT | Outputs a character string at the specified location by using the font, background color, and text color that are defined in the playback device context.[51] |
Object records
Object records create and manage graphics objects. In WMF files there are two broad categories of objects – graphics objects and structure objects. Structure objects are not explicitly created or deleted in a WMF, they are instead of complex structures. For example, the BitmapCoreHeader contains information about the dimensions and color format of a device-independent bitmap,[52] which is itself part of a DeviceIndependentBitmap object.[53] A graphics object, however, specifies parameters for graphics output and during playback of the WMF it sets up the playback device context.[54]
Graphics objects can be brushes (defines the style, color and pattern of a brush which defines how to paint an area of the graphic), fonts (defines properties that affect how text is displayed), palettes (specifies colors as device-independent values, defined by an application), pens (specifies the graphical attributes of a line), and regions (which specify line and curve segments that define a shape).[54]
| Name | Description |
|---|---|
| META_CREATEBRUSHINDIRECT | Creates a brush object from a LogBrush (logical brush) object.[55] |
| META_CREATEFONTINDIRECT | Creates a brush object from a font object.[56] |
| META_CREATEPALETTE | Creates a palette object. |
| META_CREATEPATTERNBRUSH[57] | Creates a brush object from a LogBrush (logical brush) object.[58] |
| META_CREATEPENINDIRECT | Creates a pen object.[59] |
| META_CREATEREGION | Creates a region object.[60] |
| META_DELETEOBJECT | Delete an object.[61] |
| META_CREATEBRUSHINDIRECT | Creates a brush object from a LogBrush (logical brush) object.[62] |
| META_DIBCREATEPATTERNBRUSH | Creates a brush object from a device-independent bitmap.[63] |
| META_SELECTCLIPREGION | Specifies the region object that will be the current clipping region.[64] |
| META_SELECTOBJECT | Selects the object that will be the current object for the playback device context, which works on all graphics objects except palette objects, which must be set with META_SELECTPALETTE.[65] |
| META_SELECTPALETTE | Selects the logical palette for the playback device context.[66] |
State records
State records manage the graphics properties of the playback device context.[67]
| Name | Description |
|---|---|
| META_ANIMATEPALETTE | Redefines entries in the logical palette that is defined in the playback device context with a specified Palette Object.[68] |
| META_EXCLUDECLIPRECT | Sets the clipping region that is defined in the playback device context to the existing clipping region minus a specified rectangle.[69] |
| META_INTERSECTCLIPRECT | Sets the clipping region that is defined in the playback device context to the intersection of the existing clipping region and a specified rectangle.[70] |
| META_MOVETO | Sets the output position in the playback device context to a specified point.[71] |
| META_OFFSETCLIPRGN | Moves the clipping region that is defined in the playback device context by specified offsets.[72] |
| META_OFFSETVIEWPORTORG | Moves the viewport origin in the playback device context by specified horizontal and vertical offsets.[73] |
| META_OFFSETWINDOWORG | Moves the output window origin in the playback device context by specified horizontal and vertical offsets.[74] |
| META_REALIZEPALETTE | Maps entries from the logical palette that is defined in the playback device context to the system palette.[75] |
| META_RESIZEPALETTE | Redefines the size of the logical palette that is defined in the playback device context.[76] |
| META_RESTOREDC | Restores the playback device context from a previously saved device context.[77] |
| META_SAVEDC | Saves the playback device context for later retrieval.[78] |
| META_SCALEVIEWPORTEXT | Scales the horizontal and vertical extents of the viewport that is defined in the playback device context using the ratios formed by specified multiplicands and divisors.[79] |
| META_SCALEWINDOWEXT | Scales the horizontal and vertical extents of the output window that is defined in the playback device context using the ratios formed by specified multiplicands and divisors.[80] |
| META_SETBKCOLOR | Sets the background color in the playback device context to a specified color.[81] |
| META_SETBKMODE | Sets the background mix mode in the playback device context.[82] |
| META_SETLAYOUT | Defines the layout orientation in the playback device context.[83] |
| META_SETMAPMODE | Defines the mapping mode in the playback device context.[84] |
| META_SETMAPPERFLAGS | Defines the algorithm that the font mapper uses when it maps logical fonts to physical fonts.[85] |
| META_SETPALENTRIES | Defines RGB color values in a range of entries in the logical palette that is defined in the playback device context.[86] |
| META_SETPOLYFILLMODE | Defines polygon fill mode in the playback device context for graphics operations that fill polygons.[87] |
| META_SETRELABS | Unused record.[88] |
| META_SETROP2 | Defines the foreground raster operation mixing mode in the playback device context.[89] |
| META_SETSTRETCHBLTMODE | Defines the bitmap stretching mode in the playback device context.[90] |
| META_SETTEXTALIGN | Defines text-alignment values in the playback device context.[91] |
| META_SETTEXTCHAREXTRA | Defines inter-character spacing for text justification in the playback device context.[92] |
| META_SETTEXTCOLOR | Defines the text foreground color in the playback device context.[93] |
| META_SETTEXTJUSTIFICATION | Defines the amount of space to add to break characters in a string of justified text.[94] |
| META_SETVIEWPORTEXT | Defines the horizontal and vertical extents of the viewport in the playback device context.[95] |
| META_SETVIEWPORTORG | Defines the viewport origin in the playback device context.[96] |
| META_SETWINDOWEXT | Defines the horizontal and vertical extents of the output window in the playback device context.[97] |
| META_SETWINDOWORG | Defines the output window origin in the playback device context.[98] |
Escape records
Escape records are a means to extend metafile functionality via records that are not otherwise defined as a WMF record type. Each escape record contains a record function, an escape function and potentially escape data.
The following escape records make up a WMF file.
| Name | Description |
|---|---|
| ABORTDOC | Stops processing the current document.[99] |
| BEGIN_PATH | Opens a path.[100] |
| CHECK_JPEGFORMAT | Determines whether it can handle the given JPEG image.[101] |
| CHECK_PNGFORMAT | Determines whether it can handle the given PNG image.[102] |
| CLIP_TO_PATH | Applies a function to the current PostScript clipping path.[103] |
| CLOSE_CHANNEL | Same as ENDDOC.[104] |
| DOWNLOAD_FACE | Sets the font face name on the output device.[105] |
| DOWNLOAD_HEADER | Downloads sets of PostScript procedures.[106] |
| DRAW_PATTERNRECT | Draws a rectangle with a defined pattern.[107] |
| ENCAPSULATED_POSTSCRIPT | Sends arbitrary encapsulated PostScript (EPS) data directly to the printer driver.[108] |
| END_PATH | Ends a path.[109] |
| ENDDOC | Notifies the printer driver that a new print job is ending.[110] |
| EPS_PRINTING | Indicates the start and end of EPS printing.[111] |
| EXTTEXTOUT | Draws text using the currently selected font, background color, and text color.[112] |
| GET_COLORTABLE | Gets color table values from the printer driver.[113] |
| GET_DEVICEUNITS | Gets the device units currently configured on the output device.[114] |
| GET_EXTENDED_TEXTMETRICS | Gets the extended text metrics that are currently configured on the printer driver.[115] |
| GET_FACENAME | Gets the font face name currently configured on the output device.[116] |
| GET_PAIRKERNTABLE | Gets the font kern table currently defined on the output device.[117] |
| GET_PHYSPAGESIZE | Retrieves the physical page size currently selected on the output device.[118] |
| GET_PRINTINGOFFSET | Retrieves the offset from the upper-left corner of the physical page where the actual printing or drawing begins.[119] |
| GET_PS_FEATURESETTING | Queries the printer driver for information about PostScript features supported on the output device.[120] |
| GET_SCALINGFACTOR | Retrieves the scaling factors for the x-axis and the y-axis of a printer.[121] |
| META_ESCAPE_ENHANCED_METAFILE | Used to embed an EMF metafile within a WMF metafile.[122] |
| METAFILE_DRIVER | Queries the printer driver about its support for metafiles on the output device.[123] |
| NEWFRAME | Notifies the printer driver that the application has finished writing to a page.[124] |
| NEXTBAND | Notifies the printer driver that the application has finished writing to a band.[125] |
| PASSTHROUGH | Passes through arbitrary data to the printer driver.[126] |
| POSTSCRIPT_DATA | Sends arbitrary PostScript data to the output device.[127] |
| POSTSCRIPT_IDENTIFY | Sets the printer driver to either PostScript-centric or GDI-centric mode.[128] |
| POSTSCRIPT_IGNORE | Notifies the output device to ignore PostScript data.[129] |
| POSTSCRIPT_INJECTION | Inserts a block of raw data into a PostScript stream.[130] |
| POSTSCRIPT_PASSTHROUGH | Sends arbitrary data directly to a printer driver, which is expected to process this data only when in PostScript mode.[131] |
| OPEN_CHANNEL | Acts the same as STARTDOC, with a NULL document and output filename, and data in raw mode.[132] |
| QUERY_DIBSUPPORT | Queries the printer driver about its support for DIBs on the output device.[133] |
| QUERY_ESCSUPPORT | Queries the printer driver to determine whether a specific WMF escape function is supported on the output device.[134] |
| SET_COLORTABLE | Sets color table values.[135] |
| SET_COPYCOUNT | Sets the number of copies.[136] |
| SET_LINECAP | Specifies the line-ending mode to use in drawing to the output device.[137] |
| SET_LINEJOIN | Specifies the line-joining mode to use in drawing to the output device.[138] |
| SET_MITERLIMIT | Sets the limit for the length of miter joins to use in drawing to the output device.[139] |
| SPCLPASSTHROUGH2 | Enables documents to include private procedures and other arbitrary data in documents.[140] |
| STARTDOC | Notifies the printer driver that a new print job is starting.[141] |
There was a major vulnerability found in escape records around the Abort escape record, which stores the abort procedure code within the record itself. This affected Windows systems (see CVE-2005-4560) and the Wine project (see CVE-2006-0106). According to Secunia, "The vulnerability is caused due to an error in the handling of Windows Metafile files ('.wmf') containing specially crafted SETABORTPROC 'Escape' records. Such records allow arbitrary user-defined function to be executed when the rendering of a WMF file fails."[142] According to the Windows 3.1 SDK documentation, the SETABORTPROC escape was obsoleted and replaced by the function of the same name in Windows 3.1, long before the WMF vulnerability was discovered.[143] However the obsoleted escape code was retained for compatibility with 16 bit programs written for (or at least backwards compatible with) Windows 3.0. This change happened at approximately the same time as Microsoft was creating the 32 bit reimplementation of GDI for Windows NT, and it is likely that the vulnerability occurred during this effort.
After Steve Gibson accused Microsoft of deliberately implementing a backdoor into their code,[144][145] Mark Russinovich provided a rebuttal, and stated that:
...things were different when the format was architected. In the Windows 3.1 “large” memory model code is inherently location-independent and Windows was never patched, so both Windows and an application could simply copy an application function into the WMF file and assume it would work when played back by the same application in a later run session. In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures. Also, as Microsoft’s Stephen Toulouse pointed out in Microsoft’s rebuttal to Steve’s claims, the security landscape in the early 1990s was very different than today and all code, including that stored in a WMF file, was inherently trusted.[146]
Peter Ferrie of Symantec Security Response, USA also disagreed with Gibson, noting that:
Gibson claimed that a thread is created to run the SetAbortProc handler. In fact, no thread is created to run the handler – it is a callback, which is called by the parser, and the parser has to wait until the callback returns, otherwise the whole point of the function (to abort the printing) is lost. By his own admission, Gibson did not read the documentation (in fact, he claimed that he couldn’t find it, although it is freely available on Microsoft’s Web site), and he claimed that the device context is not available to the function handler. Of course the device context is available to the function handler — it is one of the two parameters that is passed to it (see above), and it is required in order to abort the printing. Finally, Gibson claimed that the control flow could not return to Windows. It is simply a matter of the function returning and discarding the parameters that were passed on the stack. If the record is well formed, Windows will continue to parse the file, as before. ... Gibson admits that he was guessing about a number of things. Unfortunately, he guessed poorly. I guess we know better now.[147]
EMF
| Filename extension |
.emf |
|---|---|
| Internet media type |
image/emf[10] |
| Uniform Type Identifier (UTI) | com.microsoft.emf[10] |
| Type of format | Vector graphics |
| Extended from | WMF |
| Extended to | EMF+ |
EMF files have three possible versions of headers. The original headers is just a container for images, the second and third version encapsulates the original header and contains a pixel format record and support for OpenGL records, and the third version encapsulates the second header extension and increases EMF accuracy and scalability of EMFs as it adds the ability to measure distances of device surfaces using the metric system.[148]
Each EMF header starts with an EMR_HEADER record, and records the relevant properties of the device on which the metafile image was recorded. The original EMF header has an 80 byte header and an optional variable length description string.[149] Other metafiles contain extension fields, which encapsulate the original header. EmfMetafileHeaderExtension1 is a record that is inserted directly after the original EMF header, specifies whether there is a pixel format descriptor and the offset to the descriptor object within the header, as well as a field that specifies if OpenGL records exist in the metafile.[150] The pixel format descriptor specifies the capabilities of the drawing surface and whether a pixel is encoded in RGBA or is an index into a color table.[151] EmfMetafileHeaderExtension2 is a record that is inserted directly after the EmfMetafileHeaderExtension1 record, and it contains two fields with the X and Y values to measure the device surface in micrometers.[152]
Like WMF files, records can be classified by function, however there are more record types in EMF files than there are in WMF files. Records can be classified as control, bitmap, clipping, comment, drawing, escape, object creation, object manipulation, OpenGL, path bracket, state and transform records.
EMF+
With the release of Windows XP, the Enhanced Metafile Format Plus Extensions (EMF+) format was introduced. EMF+ provides a way to serialize calls to the GDI+ API in the same way that WMF/EMF stores calls to GDI.
There are also compressed versions of Windows Metafiles known as Compressed Windows Metafile (WMZ) and Compressed Windows Enhanced Metafile (EMZ),[153] which are basically gzip compressed WMF and EMF files correspondingly.
The WMF format was designed to be executed by the Windows GDI layer in order to restore the image, but as the WMF binary files contain the definition of the GDI graphic primitives that constitute this image, it is possible to design alternative libraries that render WMF binary files or convert them into other graphic formats.
- PostScript
- Vector Markup Language (VML)
- Scalable Vector Graphics (SVG)
Wikiwand in your browser!
Seamless Wikipedia browsing. On steroids.
Every time you click a link to Wikipedia, Wiktionary or Wikiquote in your browser's search results, it will show the modern Wikiwand interface.
Wikiwand extension is a five stars, simple, with minimum permission required to keep your browsing private, safe and transparent.
