From looking at it it appears to be:
x //word
y //word
count //word
flags //word
rect // only if CLIPPED or OPAQUE???
text
But, wingdi.h has:
typedef struct tagEMREXTTEXTOUTA
{
EMR emr;
RECTL rclBounds; // Inclusive-inclusive bounds in device units
DWORD iGraphicsMode; // Current graphics mode
FLOAT exScale; // X and Y scales from Page units to .01mm
units
FLOAT eyScale; // if graphics mode is GM_COMPATIBLE.
EMRTEXT emrtext; // This is followed by the string and spacing
// array
} EMREXTTEXTOUTA, *PEMREXTTEXTOUTA,
and the msdn docs have:
BOOL ExtTextOut(
HDC hdc, // handle to DC
int X, // x-coordinate of reference point
int Y, // y-coordinate of reference point
UINT fuOptions, // text-output options
CONST RECT* lprc, // optional dimensions
LPCTSTR lpString, // string
UINT cbCount, // number of characters in string
CONST INT* lpDx // array of spacing values
);
So, anyplace where it lists what this is for sure? And when will the
bounding rectangle be included?
--
thanks - dave
Based on my understanding, you think that EMREXTTEXTOUT structure is not
complete and lacks some necessary information (for example:bounding
rectangle) . If I misunderstood you, please feel free to let know.
The EMREXTTEXTOUTA and EMREXTTEXTOUTW structures contain members for the
ExtTextOut, TextOut, or DrawText enhanced metafile records. If we looked
into this structure, we will find it provides sufficient information to
make metafile drawn. I will list all relevant member of this structure as
follows,
typedef struct tagEMREXTTEXTOUTA
{
EMR emr;
RECTL rclBounds; // Inclusive-inclusive bounds in device
units
DWORD iGraphicsMode; // Current graphics mode
FLOAT exScale; // X and Y scales from Page units to .01mm
units
FLOAT eyScale; // if graphics mode is GM_COMPATIBLE.
EMRTEXT emrtext; // This is followed by the string and
spacing
// array
} EMREXTTEXTOUTA, *PEMREXTTEXTOUTA,
EMREXTTEXTOUTW, *PEMREXTTEXTOUTW;
// Base record type for the enhanced metafile.
typedef struct tagEMR
{
DWORD iType; // Enhanced metafile record type
DWORD nSize; // Length of the record in bytes.
// This must be a multiple of 4.
} EMR, *PEMR;
typedef struct _RECTL /* rcl */
{
LONG left;
LONG top;
LONG right;
LONG bottom;
} RECTL, *PRECTL, *LPRECTL;
typedef struct tagEMRTEXT
{
POINTL ptlReference;
DWORD nChars;
DWORD offString; // Offset to the string
DWORD fOptions;
RECTL rcl;
DWORD offDx; // Offset to the inter-character spacing
array.
// This is always given.
} EMRTEXT, *PEMRTEXT;
According to the definition of EMREXTTEXTOUT, we will find bounding
rectangle is included in EMRTEXT structure (member: RECTL rcl) and an
EMRTEXT member in EMREXTTEXTOUT structure (member: EMRTEXT emrtext). So I
think there is sufficient information in EMREXTTEXTOUT structure to render
ExtTextOut, TextOut, or DrawText metafile records.
If you have any questions or concerns, please don't hesitate to let me
know. Thanks! : )
Best Regards,
Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
My question is not is there all data needed in those structures, it's that
the data in a WMF for an EXTTEXTOUT doesn't match the structures. For an
EXTTEXTOUT the data comes as:
y //word
x //word
count //word
flags //word
//optional rect
test //byte[]
The above is based on code in two open source wmf readers as well as viewing
this record in my code in the debugger. But this does not match
EMREXTTEXTOUTA or EMRTEXT.
So what is going on here? I don't think I am wrong on the struct above as it
is giving me the values in the metafile - but it doesn't match the
documentation.
--
thanks - dave
I viewed the record of EXTTEXTOUT in the Debugger and found the parameter's
order in memory doesn't match the order of ExtTextOut API parameters. In a
word, the order of parameters isn't 1:1 from record data in memory to
ExtTextOut API. Although the order in memory doesn't match ExtTextOut's,
the data in memory is sufficient to make ExtTextOut invoked successfully
(GDI know how to arrange parameters for ExtTextOut API from memory).
If you have any questions or concerns, please feel free to let me know.
Thanks! : )
Best Regards,
Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)
--------------------
>Thread-Topic: Metafile EXTTEXTOUT record structure?
>thread-index: AcXa+vUbCPUh6nSGRfSfcHda6r07Jw==
>X-WBNR-Posting-Host: 199.45.247.98
>From: "=?Utf-8?B?RGF2aWQgVGhpZWxlbg==?=" <thi...@nospam.nospam>
>References: <D340F4AC-F942-4C00...@microsoft.com>
<cpMDGbt2...@TK2MSFTNGXA01.phx.gbl>
>Subject: RE: Metafile EXTTEXTOUT record structure?
>Date: Thu, 27 Oct 2005 06:33:03 -0700
>Lines: 101
>Message-ID: <9DFB31A2-8BE7-452C...@microsoft.com>
>MIME-Version: 1.0
>Content-Type: text/plain;
> charset="Utf-8"
>Content-Transfer-Encoding: 7bit
>X-Newsreader: Microsoft CDO for Windows 2000
>Content-Class: urn:content-classes:message
>Importance: normal
>Priority: normal
>X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
>Newsgroups: microsoft.public.win32.programmer.gdi
>NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.2.250
>Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGXA03.phx.gbl
>Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.win32.programmer.gdi:7216
>X-Tomcat-NG: microsoft.public.win32.programmer.gdi
Yes, but I need to know what the order is in memory too. I am accessing this
file from java so I cannot use the GDI calls to access it. And some of the
code samples I have seen show that sometimes there is a clip rectangle in the
middle of the structure - so I need to know when and where that is placed.
--
Vipin Aravind
MVP [Windows - Printing/Imaging]
"David Thielen" <thi...@nospam.nospam> wrote in message
news:2A3FDF41-1E4E-44D6...@microsoft.com...
Our product may stradle the java/Windows world in a weirder way than any
other. We have a reporting package, http://www.windwardreports.com that is a
pure java solution. And we have customers running it on solaris, linux, AIX,
AS/400, some mainframes, as well as Windows. So the engine must be pure java.
The report templates are created in Word. So we have to parse rtf and xml
(WordML) files - totally in java. The wmf/emf comes in to play in three
places.
First, all images in a rtf file have a \nonship copy of the image that is a
wmz file. And WordPad needs that part to display an image. So we have to
create wmz images for any bitmap be it bmp, jpg, png, etc.
Second, a wmf or emf can be inserted in a document. But the final report
coud be in the html format. So in that case we have to convert the wmf/emf
into png for the output. And pdf can handle wmf, but not emf or wmz/emz so
again we need to parse the metafile in that case.
Third, when there is an embedded OLE object, a picture of the object output
is stored in a wmf (rtf)/wmz (xml) format. This allows us to display the OLE
object in the output document as a png image.
Does it all make sense now?
--
thanks - dave
have you ever thought of just playing the metafile into a DC and saving it
as a bitmap then converting it to a PNG directly? This would alleviate the
issue of having to enumerate / parse the metafiles altogether....
Best Regards,
Rene Pilon.
But we have customers that run this on non Windows boxes so we have no
access to the Windows API. Many of these customers don't have any windows
servers at all.
--
thanks - dave
Hopefully we can help you more in the future to get it all up and running.
Best Regards,
Rene Pilon
--
thanks - dave