|
Site Index - Feedback - Impressum |
| |||||||||
|
![[Forum]](../../../images.os2.org/de/forum.gif){kind=small} |
|
![[Forum]](../../../images.os2.org/de/forum2.gif){kind=small} |
| ( Archiv ) | ( Neues Thema ) |
| ( Zeige die Threadübersicht ) | ( Zur Startübersicht ) |
| 27.07.2000 |
| WMF-Dateien (von: Traudel, 22:11:56) | ^ |
| Kennt jemand ein Programm mit dem man Bilder im WMF-Format betrachten kann?
[ Leser: 139 ] |
| 28.07.2000 |
| Re: WMF-Dateien (von: Jan Arne Petersen, 00:30:24) | |
| StarOffice |
| WMF Dateien nach BMP, TII u.a. konvertieren.. (von: GA, 11:57:10) | |
| kann man mit KVEC(http://www.vobis.de/bbs/firmen/pconline/os2).
Dort oder anderswo: kvec_os2.zip |
| Re: WMF Dateien (von: Klaus Staedtler, 17:19:05) | |
| Lotus Smartsuite ebenso :-), man kann also bedenkenlos Staroffice deinstallieren wenn man ueber Sun veraergert ist ;-) |
| 29.07.2000 |
| Re: WMF Dateien (von: Andreas Schnellbacher, 20:50:53) | |
| Moin,
Vermutlich gibt es deshalb so wenig Viewer dafuer, weil es 'ne Besteckmarke ist! --- Mir fallen aber auch nur die Office-Programme ein, von denen auch Windoze-Versionen existieren. Nicht mal PMView kennt WMF. Zur Not musst Du doch 'n 3.1-Programm nehmen. |
| 01.08.2000 |
| Irfan View mit ODIN (von: Christian/2, 22:53:30) | |
| Als "Notlösung" wäre da noch Irfan View für win... . Unter Odin läuft die Version 3.02 schon ziemlich stabil. Zum Ansehen und Diashow reichts allemal. |
| 02.08.2000 |
| Re: WMF Dateien -> Lohnendes Programmier-Projekt! (von: Cornelis Bockemühl, 08:58:07) | |
| Besteckmarke ist gut... ;-)
Ein Grund warum PMView das nicht lesen kann ist aber leicht zu sehen: WMF ist ein *Vektor*-Format und PMView ist ein *Bitmap*-Viewer! ("Bitmap" jetzt im allgemeinen Sinn, nicht als spezielles BMP-Format, natürlich...). Für Windosen-Programmierer ist WMF leicht zu handhaben, da es von den API-Funktionen direkt "verarbeitet" wird, so wie unter OS/2 das MET-Format (welches aber leider eher ein Mauerblümchen-Dasein fristet...). Das ist auch der Grund warum Papyrus unter WinXX das WMF-Format unterstützt, unter OS/2 aber das MET-Format - eine lästige Sache für Leute, die Papyrus wegen der ansonsten so exakten Masshaltigkeit schätzen (z.B. ganz im Gegensatz zu MS-Word...)! Es gibt von MS eine Dokumentation über das WMF-Format. Darüber hinaus gibt es auch Ansätze zu Dokumentationen, die wirklich halbwegs komplett sind... Wie exakt und vollständig die IBM-Dokumentation über das MET-Format sind weiss ich nicht. Kurz: Es ist nicht ganz trivial. Aber dennoch: Angesichts der Verbreitung des WMF-Formats und des leichten Handlings von MET-Dateien in vielen OS/2-Programmen wäre ein allgemeiner WMF<->MET-Konverter sicher ein lohnendes Programmier-Projekt - für manchen vielleicht sogar noch nützlicher als ODIN? (Sorry: Nichts gegen ODIN! Ich wollte nur sagen: Ein solcher Konverter könnte SEHR nützlich sein... ;-) ) Ich glaube, es gibt sogar schon zumindest Ansätze zu WMF-Readern im Open-Source-Bereich - müsste man suchen... Hat jemand Lust? |
| WMF-Format (von: Andreas Schnellbacher, 14:06:42) | |
| Das WMF-Format beinhaltet 2 Formate: Vektor und Bitmap. Es ist das Format fuer die Windos-Zwischenablage. Nur die wenigsten W-Progs beherrschen uebrigens auch das Vektorformat, so dass es beim Kopieren ueber die Z. hiermit immer wieder Verfaelschungen gibt.
Sicherlich meint Traudel hier aber das Bitmap-Format. W-Programm-Autoren koennen natuerlich einfach die Funktionen des "OS" nehmen, so dass eigentlich keine eigenen Filter geschrieben werden muessen. Deshalb hat dieses Format (zum Glueck) auch nur unter W Verbreitung. Als Datenaustauschformat ist deshalb WMF auch voellig ungeeignet. Das nuetzt einem leider nicht viel, wenn man z.B. eine Cliparts-CD eines WSchrott-Progs betrachten will. Dies duerfte aber der Einzelfall sein, so dass es voellig ausreichend ist einen der empfohlenen Viewer zu benutzen. Viel wichtiger waere es das geniale netpbma-Paket so zu erweitern, dass es JPEG bearbeiten kann. Auch koennte man lieber das MMOS2-Subsystem dahingehend erweitern, dass es mit mehr JPEG- und GIF-Formaten klarkommt. |
| Souce Deck für Konvereter WMF --> GIF ... (von: GA, 14:44:26) | |
| findet man hier:http://www.csn.ul.ie/~caolan/publink/libwmf/ |
| Online Konvereter WMF --> GIF ... (von: GA, 14:46:14) | |
| findet man hier:http://www.csn.ul.ie/~caolan/docs/libwmf-Demo.html |
| Zum Windows Meta File (von: GA, 14:52:49) | |
| .WMF Metafile Format
A metafile for the Microsoft Windows operating system consists of a collection of graphics device interface (GDI) functions that describe an image. Because metafiles take up less space and are more device-independent than bitmaps, they provide convenient storage for images that appear repeatedly in an application or need to be moved from one application to another. To generate a metafile, a Windows application creates a special device context that sends GDI commands to a file or memory for storage. The application can later play back the metafile and display the image. During playback, Windows breaks the metafile down into records and identifies each object with an index to a handle table. When a META_DELETEOBJECT record is encountered during playback, the associated object is deleted from the handle table. The entry is then reused by the next object that the metafile creates. To ensure compatibility, an application that explicitly manipulates records or builds its own metafile should manage the handle table in the same way. For more information on the format of the handle table, see the HANDLETABLE structure. In some cases, there are two variants of a metafile record, one representing the record created by Windows versions before 3.0 and the second representing the record created by Windows versions 3.0 and later. Windows versions 3.0 and later play all metafile versions but store only 3.0 and later versions. Windows versions earlier than 3.0 do not play metafiles recorded by Windows versions 3.0 and later. A metafile consists of two parts: a header and a list of records. The header and records are described in the remainder of this topic. For a list of function-specific records, see Metafile Records. Metafile Header The metafile header contains a description of the size of the metafile and the number of drawing objects it uses. The drawing objects can be pens, brushes, bitmaps, or fonts. The metafile header has the following form: typedef struct tagMETAHEADER { WORD mtType; WORD mtHeaderSize; WORD mtVersion; DWORD mtSize; WORD mtNoObjects; DWORD mtMaxRecord; WORD mtNoParameters; } METAHEADER; Following are the members in the metafile header: mtType Specifies whether the metafile is stored in memory or recorded in a file. This member has one of the following values: Value Meaning 0 Metafile is in memory. 1 Metafile is in a file. mtHeaderSize Specifies the size, in words, of the metafile header. mtVersion Specifies the Windows version number. The version number for Windows version 3.0 and later is 0x300. mtSize Specifies the size, in words, of the file. mtNoObjects Specifies the maximum number of objects that can exist in the metafile at the same time. mtMaxRecord Specifies the size, in words, of the largest record in the metafile. mtNoParameters Not used. Typical Metafile Record The graphics device interface stores most of the GDI functions that an application can use to create metafiles in typical records. A typical metafile record has the following form: struct { DWORD rdSize; WORD rdFunction; WORD rdParm[]; } Following are the members in a typical metafile record: rdSize Specifies the size, in words, of the record. rdFunction Specifies the function number. This value may be the number of any function in the table at the end of this section. rdParm Identifies an array of words containing the function parameters (listed in the reverse order in which they are passed to the function). Following are the GDI functions found in typical records, along with their hexadecimal values: GDI function Value Arc 0x0817 Chord 0x0830 Ellipse 0x0418 ExcludeClipRect 0x0415 FloodFill 0x0419 IntersectClipRect 0x0416 LineTo 0x0213 MoveTo 0x0214 OffsetClipRgn 0x0220 OffsetViewportOrg 0x0211 OffsetWindowOrg 0x020F PatBlt 0x061D Pie 0x081A RealizePalette (3.0 and later) 0x0035 Rectangle 0x041B ResizePalette (3.0 and later) 0x0139 RestoreDC 0x0127 RoundRect 0x061C SaveDC 0x001E ScaleViewportExt 0x0412 ScaleWindowExt 0x0400 SetBkColor 0x0201 SetBkMode 0x0102 SetMapMode 0x0103 SetMapperFlags 0x0231 SetPixel 0x041F SetPolyFillMode 0x0106 SetROP2 0x0104 SetStretchBltMode 0x0107 SetTextAlign 0x012E SetTextCharacterExtra 0x0108 SetTextColor 0x0209 SetTextJustification 0x020A SetViewportExt 0x020E SetViewportOrg 0x020D SetWindowExt 0x020C SetWindowOrg 0x020B Placeable Windows Metafiles A placeable Windows metafile is a standard Windows metafile that has an additional 22-byte header. The header contains information about the aspect ratio and original size of the metafile, permitting applications to display the metafile in its intended form. The header for a placeable Windows metafile has the following form: typedef struct { DWORD key; HANDLE hmf; RECT bbox; WORD inch; DWORD reserved; WORD checksum; } METAFILEHEADER; Following are the members of a placeable metafile header: key Specifies the binary key that uniquely identifies this file type. This member must be set to 0x9AC6CDD7L. hmf Unused; must be zero. bbox Specifies the coordinates of the smallest rectangle that encloses the picture. The coordinates are in metafile units as defined by the inch member. inch Specifies the number of metafile units to the inch. To avoid numeric overflow, this value should be less than 1440. Most applications use 576 or 1000. reserved Unused; must be zero. checksum Specifies the checksum. It is the sum (using the XOR operator) of the first 10 words of the header. The actual content of the Windows metafile immediately follows the header. The format for this content is identical to that for standard Windows metafiles. For some applications, a placeable Windows metafile must not exceed 64K. Note: Placeable Windows metafiles are not compatible with the GetMetaFile function. Applications that intend to use the metafile functions to read and play placeable Windows metafiles must read the file by using an input function (such as _lread), strip the 22-byte header, and create a standard Windows metafile by using the remaining bytes and the SetMetaFileBits function. Guidelines for Windows Metafiles To ensure that metafiles can be transported between different computers and applications, any application that creates a metafile should make sure the metafile is device-independent and sizable. The following guidelines ensure that every metafile can be accepted and manipulated by other applications: Set a mapping mode as one of the first records. Many applications, including OLE applications, only accept metafiles that are in MM_ANISOTROPIC mode. Call the SetWindowOrg and SetWindowExt functions. Do not call the SetViewportExt or SetViewportOrg functions if the user will be able to resize or change the dimensions of the object. Use the MFCOMMENT printer escape to add comments to the metafile. Rely primarily on the functions listed in Typical Metafile Record. Observe the following limitations on the functions you use: Do not use functions that retrieve data (for example, GetActiveWindow or EnumFontFamilies). Do not use any of the region functions (because they are device dependent). Use StretchBlt or StretchDIB instead of BitBlt. Sample of Metafile Program Output This section describes a sample program and the metafile that it creates. The sample program creates a small metafile that draws a purple rectangle with a green border and writes the words "Hello People" in the rectangle. MakeAMetaFile(hDC) HDC hDC; { HPEN hMetaGreenPen; HBRUSH hMetaVioletBrush; HDC hDCMeta; HANDLE hMeta; /* Create the metafile with output going to the disk. */ hDCMeta = CreateMetaFile( (LPSTR) "sample.met"); hMetaGreenPen = CreatePen(0, 0, (DWORD) 0x0000FF00); SelectObject(hDCMeta, hMetaGreenPen); hMetaVioletBrush = CreateSolidBrush((DWORD) 0x00FF00FF); SelectObject(hDCMeta, hMetaVioletBrush); Rectangle(hDCMeta, 0, 0, 150, 70); TextOut(hDCMeta, 10, 10, (LPSTR) "Hello People", 12); /* We are done with the metafile. */ hMeta = CloseMetaFile(hDCMeta); /* Play the metafile that we just created. */ PlayMetaFile(hDC, hMeta); } The resulting metafile, SAMPLE.MET, consists of a metafile header and six records. It has the following binary form: 0001 mtType... disk metafile 0009 mtSize... 0300 mtVersion 0000 0036 mtSize 0002 mtNoObjects 0000 000C mtMaxRecord 0000 mtNoParameters 0000 0008 rdSize 02FA rdFunction (CreatePenIndirect function) 0000 0000 0000 0000 FF00 rdParm (LOGPEN structure defining pen) 0000 0004 rdSize 012D rdFunction (SelectObject) 0000 rdParm (index to object #0... the above pen) 0000 0007 rdSize 02FC rdFunction (CreateBrushIndirect) 0000 00FF 00FF 0000 rdParm (LOGBRUSH structure defining the brush) 0000 0004 rdSize 012D rdFunction (SelectObject) 0001 rdParm (index to object #1... the brush) 0000 0007 rdSize 041B rdFunction (Rectangle) 0046 0096 0000 0000 rdParm (parameters sent to Rectangle... in reverse order) 0000 000C rdSize 0521 rdFunction (TextOut) rdParm 000C count string 48 65 6C 6C 6F 20 50 65 6F 70 6C 65 "Hello People" 000A y-value 000A x-value |
| Zu Windows Meta File: 4 verschieden Typen (von: GA, 15:03:33) | |
| File Organization
A metafile is comprised of one or two information headers and an array of variable-length records that store the GDI function call information. There are four flavors of Windows metafiles: standard, placeable, clipboard, and enhanced. A standard metafile contains an 18-byte WMF header followed by one or more records of GDI commands. A placeable metafile contains a 22-byte header followed by the standard 18-byte WMF header and GDI command records. Clipboard metafiles contains a 8-byte (Win16) or 16-byte (Win32) header that precedes the standard metafile header. Enhanced metafiles contain only EMF records, with the first record storing the header information. EMF files are not compatible in design with the other types of WMF metafiles. Windows Metafiles (Figure Microsoft Windows Metafile-1) contain a header, followed by one or more records of data. The header contains a description of the record data stored in the metafile. Each record is a binary-encoded Microsoft Windows Graphics Device Interface (GDI) function call. The GDI is used by Windows to perform all output to a window, printer, or other output device. When the metafile data is rendered (or played back, in Microsoft terminology), the data from each record is used to perform the appropriate GDI function call to render each object stored in the file. The last record in the file contains information indicating that the end of the record data has been reached. Placeable metafiles (Figure Microsoft Windows Metafile-2) are WMF files with an 18-byte header prepended. This preheader contain information used to describe the position of the metafile drawing on the printed page (something that the original WMF file designers did not think of). Clipboard metafiles (Figure Microsoft Windows Metafile-3) are similar to placeable metafiles in that that also contain an extra header prepended to a WMF file. The Clipboard preheader contains information used to describe the position of the metafile on the Windows Clipboard and the mapping mode used to playback the data. Enhanced metafiles (Figure Microsoft Windows Metafile-4) have the same basic format of WMF files: a header followed by one or more records of drawing objects stored as GDI commands. Unlike WMF, the header is also stored in a record which appears as the first record in each EMF file. The EMF header now contains additional information, including the position and mapping information stored in the placeable and clipboard metafile preheaders. EMF also adds the features of a file description string and a programmable color palette to the metafile format. File Details The standard Windows metafile header is 18 bytes in length and is structured as follows: typedef struct _WindowsMetaHeader { WORD FileType; /* Type of metafile (0=memory, 1=disk) */ WORD HeaderSize; /* Size of header in WORDS (always 9) */ WORD Version; /* Version of Microsoft Windows used */ DWORD FileSize; /* Total size of the metafile in WORDs */ WORD NumOfObjects; /* Number of objects in the file */ DWORD MaxRecordSize; /* The size of largest record in WORDs */ WORD NumOfParams; /* Not Used (always 0) */ } WMFHEAD; FileType contains a value which indicates the location of the metafile data. A value of 0 indicates that the metafile is stored in memory, while a 1 indicates that it is stored on disk. HeaderSize contains the size of the metafile header in 16-bit WORDs. This value is always 9. Version stores the version number of Microsoft Windows that created the metafile. This value is always read in hexadecimal format. For example, in a metafile created by Windows 3.0 and 3.1, this item would have the value 0x0300. FileSize specifies the total size of the metafile in 16-bit WORDs. NumOfObjects specifies the number of objects that are in the metafile. MaxRecordSize specifies the size of the largest record in the metafile in WORDs. |
| Zu Windows Meta File: 4 verschieden Typen (von: GA, 15:09:15) | |
| File Organization
A metafile is comprised of one or two information headers and an array of variable-length records that store the GDI function call information. There are four flavors of Windows metafiles: standard, placeable, clipboard, and enhanced. A standard metafile contains an 18-byte WMF header followed by one or more records of GDI commands. A placeable metafile contains a 22-byte header followed by the standard 18-byte WMF header and GDI command records. Clipboard metafiles contains a 8-byte (Win16) or 16-byte (Win32) header that precedes the standard metafile header. Enhanced metafiles contain only EMF records, with the first record storing the header information. EMF files are not compatible in design with the other types of WMF metafiles. Windows Metafiles (Figure Microsoft Windows Metafile-1) contain a header, followed by one or more records of data. The header contains a description of the record data stored in the metafile. Each record is a binary-encoded Microsoft Windows Graphics Device Interface (GDI) function call. The GDI is used by Windows to perform all output to a window, printer, or other output device. When the metafile data is rendered (or played back, in Microsoft terminology), the data from each record is used to perform the appropriate GDI function call to render each object stored in the file. The last record in the file contains information indicating that the end of the record data has been reached. Placeable metafiles (Figure Microsoft Windows Metafile-2) are WMF files with an 18-byte header prepended. This preheader contain information used to describe the position of the metafile drawing on the printed page (something that the original WMF file designers did not think of). Clipboard metafiles (Figure Microsoft Windows Metafile-3) are similar to placeable metafiles in that that also contain an extra header prepended to a WMF file. The Clipboard preheader contains information used to describe the position of the metafile on the Windows Clipboard and the mapping mode used to playback the data. Enhanced metafiles (Figure Microsoft Windows Metafile-4) have the same basic format of WMF files: a header followed by one or more records of drawing objects stored as GDI commands. Unlike WMF, the header is also stored in a record which appears as the first record in each EMF file. The EMF header now contains additional information, including the position and mapping information stored in the placeable and clipboard metafile preheaders. EMF also adds the features of a file description string and a programmable color palette to the metafile format. File Details The standard Windows metafile header is 18 bytes in length and is structured as follows: typedef struct _WindowsMetaHeader { WORD FileType; /* Type of metafile (0=memory, 1=disk) */ WORD HeaderSize; /* Size of header in WORDS (always 9) */ WORD Version; /* Version of Microsoft Windows used */ DWORD FileSize; /* Total size of the metafile in WORDs */ WORD NumOfObjects; /* Number of objects in the file */ DWORD MaxRecordSize; /* The size of largest record in WORDs */ WORD NumOfParams; /* Not Used (always 0) */ } WMFHEAD; FileType contains a value which indicates the location of the metafile data. A value of 0 indicates that the metafile is stored in memory, while a 1 indicates that it is stored on disk. HeaderSize contains the size of the metafile header in 16-bit WORDs. This value is always 9. Version stores the version number of Microsoft Windows that created the metafile. This value is always read in hexadecimal format. For example, in a metafile created by Windows 3.0 and 3.1, this item would have the value 0x0300. FileSize specifies the total size of the metafile in 16-bit WORDs. NumOfObjects specifies the number of objects that are in the metafile. MaxRecordSize specifies the size of the largest record in the metafile in WORDs. |
| MMOS/2 Erweiterungen leider ohne WMF (von: Klaus Staedtler, 21:33:16) | |
| passt zwar nicht 100% aber hier gibts einige Erweiterungen zu MMOS/2 u.a. auch Bildformate
http://www7.big.or.jp/~os2warp/download/INDEX-E.HTM (ist in englisch, keine Angst japanisch muss nicht zuvor gelernt werden). einiges ist Free, das meiste Shareware |
| 03.08.2000 |
| Re: Zum Windows Meta File (von: Cornelis Bockemühl, 10:41:04) | |
| Danke für die Angaben!
Du zitierst hier explizit was ich meinte: WMF ist ein HORROR von einem Dateiformat, und wie es scheint, sind viele der offiziellen Angaben auch noch entweder ungenau oder nicht komplett... Da ist die Behandlung eines Bitmaps in jedem Fall ein Kinderspiel im Vergleich! Ein Konverter WMF<->MET ist in jedem Fall nicht ein Job für einen Tag... Und doch: WMF ist für Windows was MET für OS/2 ist: eine Art 1:1-Abbild der Grafik-API-Aufrufe die das Bild auf dem betreffenden System erzeugen: Sollte gelegentlich dank ODIN vermehrt auch Win32-Software auf OS/2-Systemen eingesetzt werden, dann wird die Konvertierung zwischen WMF und MET ein immer aktuelleres Thema, auch beide als Datenaustausch-Formate ihre deutlichen Grenzen haben, z.B. wenn Fonts ins Spiel kommen. Um *Grafiken* (mit scharfen Linien, Flächen, Schriften, etc.) exakt (und platzsparend!) zu speichern ist ein Bitmap einfach völlig ungeeignet - und WMF ist ein in diesem Bereich zumindest oft unterstütztes Format, wenn die Sache von WinXX kommt! Und wenn dann jemand das Ding gerne in Papyrus einlesen will, stösst er auf ein Problem... PS: Ich weiss, EPS wäre vielleicht eine "sauberere" Lösung. Das Problem ist nur, dass man das zwar mit vielen Programman *erzeugen* kann (und sei es durch Ausdrucken auf PS-Drucker in eine Datei), aber nur SEHR selten dann wieder *einlesen* und weiter verarbeiten: Postscript ist ja nun auch nicht gerade sehr einfach zum schnell mal so lesen "konvertieren" (es sei den in ein Bitmap mit Hilfe von Ghostscript - aber wie gesagt: Bitmaps sind einfach nicht das Wahre für viele Darstellungen...). Dies nur noch zur Erläuterung des Hintergrunds meiner Überlegung! |
| ( Zeige die Threadübersicht ) | [ Version zum Drucken ] | ( Zur Startübersicht ) |
| |||
| Mit * markierte Felder müssen ausgefüllt werden ! |
|
