why i can not convert gmf file to eps file

[Don Hooper]

Matthias,

I don't know if "AFAIK Linux's gcc compiler uses 4 bytes" (for shorts) is true.
Here's the ouptut from "gcc --version" on my Linux box:
gcc (GCC) 3.4.5 20051201 (Red Hat 3.4.5-2)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

And here is the output from running the binary it generated for enquire.c:
Produced by enquire version 5.0, CWI, Amsterdam
Compiler claims to be ANSI C level 1

Compiler names are at least 64 chars long
Preprocessor names are at least 64 long

SIZES
char = 8 bits, signed
short=16 int=32 long=32 float=32 double=64 bits
long double=96 bits
char*=32 bits
int* =32 bits
func*=32 bits
Type size_t is unsigned int/long
Type wchar_t is signed int/long

ALIGNMENTS
char=1 short=2 int=4 long=4
float=4 double=4
long double=4
char*=4 int*=4 func*=4

CHARACTER ORDER
short: BA
int:   DCBA
long:  DCBA

PROPERTIES OF POINTERS
Char and int pointer formats seem identical
Char and function pointer formats seem identical
Strings are shared
Type ptrdiff_t is signed int/long
Dereferencing NULL causes a trap

PROPERTIES OF INTEGRAL TYPES
Overflow of a short does not generate a trap
Maximum short = 32767 (= 2**15-1)
Minimum short = -32768
Overflow of an int does not generate a trap
Maximum int = 2147483647 (= 2**31-1)
Minimum int = -2147483648
Overflow of a long does not generate a trap
Maximum long = 2147483647 (= 2**31-1)
Minimum long = -2147483648
Maximum unsigned short = 65535
Maximum unsigned int = 4294967295
Maximum unsigned long = 4294967295

PROMOTIONS
unsigned short promotes to signed int/long
long+unsigned gives unsigned int/long

PROPERTIES OF FLOAT
Base = 2
Significant base digits = 24 (= at least 6 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -24
Smallest x such that 1.0-x != 1.0 = 2.98023259e-08
Smallest x such that 1.0+base**x != 1.0 = -23
Smallest x such that 1.0+x != 1.0 = 5.96046519e-08
(Above number + 1.0) - 1.0 = 1.19209290e-07
Number of bits used for exponent = 8
Minimum normalised exponent = -126
Minimum normalised positive number = 1.17549435e-38
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 1.40129846e-45
Maximum exponent = 128
Maximum number = 3.40282347e+38
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Arithmetic uses a hidden bit
It looks like single length IEEE format

PROPERTIES OF DOUBLE
Base = 2
Significant base digits = 53 (= at least 15 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -53
Smallest x such that 1.0-x != 1.0 = 5.5538256285569977e-17
Smallest x such that 1.0+base**x != 1.0 = -52
Smallest x such that 1.0+x != 1.0 = 1.1107651257113995e-16
(Above number + 1.0) - 1.0 = 2.2204460492503131e-16
Number of bits used for exponent = 11
Minimum normalised exponent = -1022
Minimum normalised positive number = 2.2250738585072014e-308
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 4.9406564584124654e-324
Maximum exponent = 1024
Maximum number = 1.7976931348623157e+308
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap
Arithmetic uses a hidden bit
It looks like double length IEEE format

PROPERTIES OF LONG DOUBLE
Base = 2
Significant base digits = 64 (= at least 18 decimal digits)
Arithmetic rounds towards nearest
   Tie breaking rounds to even
Smallest x such that 1.0-base**x != 1.0 = -64
Smallest x such that 1.0-x != 1.0 = 2.71050543121376108531e-20
Smallest x such that 1.0+base**x != 1.0 = -63
Smallest x such that 1.0+x != 1.0 = 5.42101086242752217063e-20
(Above number + 1.0) - 1.0 = 1.08420217248550443401e-19
Number of bits used for exponent = 15
Minimum normalised exponent = -16382
Minimum normalised positive number = 3.36210314311209350626e-4932
The smallest numbers are not kept normalised
Smallest unnormalised positive number = 3.64519953188247460253e-4951
Maximum exponent = 16384
Maximum number = 1.18973149535723176502e+4932
Overflow doesn't seem to generate a trap
There is an 'infinite' value
Divide by zero doesn't generate a trap

*** Something fishy here!
    Exponent size + significand size doesn't match with the size of a long double!

It doesn't look like IEEE format

Float expressions are evaluated in long double precision
Double expressions are evaluated in long double precision
Long double expressions are evaluated in long double precision
Memory mallocatable ~= 2999 Mbytes

The output from "uname -a" ends in:  i686 athlon i386 GNU/Linux

-Hoop
> From owner-gradsusr at LIST.CINECA.IT  Mon May  1 19:15:25 2006
> From: Matthias Munnich <munnich at ATMOS.UCLA.EDU>
>
> Most likely the Windows compiler for grads uses 2 bytes for short
> integers (AFAIK Linux's gcc compiler uses 4 bytes) in the metafiles
> making the formats  incompatible.  Use   PC-GRADS's gxeps to convert
> to EPS.
>
> ... Matt
>
> PS: Don't attach metafiles.  Probably only a handful of people on this
> list can make sense of them.  If necessary these people will ask you
> to email them.
>
> chengs wrote:
>
> > Hi everyone,
> >
> > I now meet a problem about gxeps command.
> >
> > The attached file is generated by PC-GRADS 1.8. Now I want to
> > convert the file from gmf format to eps format. When I use "gxeps"
> > command to convert the file on Linux OS, it says:
> >
> > Fatal error: Invalid command "-1025" found in
> > metafile"figure6.gmf". Is "figure6.gmf" really a GrADS (v1.5 or
> > higher) metafile?
> >
> > Does anybody have any idea about this?
> >
> > Thanks in advance. ************************************** Guangshan
> > Chen Center for Climatic Research University of Wisconsin-Madison
> > 1225 W.Dayton Street Madison, WI 53706 USA
> >
> > phone : 608/890-0907 fax : 608/263-4190 email :
> > gchen9 at wisc.edu