Re: emf woes

[Ethan M. <merritt@u.washington.edu>]

In article <c64t60$2c5k$1...@f1...> Allin Cottrell writes:
>
>Yes, that would be nice!  As for bugs in gnuplot's EMF files, a quick
>check suggests there may be some.  I looked at a sample EMF generated
>on Windows, and the byte size written in the EMF header did not agree
>with the actual size of the file; also one field of the current EMF
>header structure is missing (I'm not sure how important that is).

Can you tell me where you found a copy of the current EMF spec?
The copy I have is probably out of date (it claims version 1.0),
since it actually describes 3 fewer records in the header than
gnuplot puts there currently.

But the emf files I generate under linux have the correct file size in
the header.  Can you reproduce the plot commands that generated a
mis-match so that I can try them here also?

I do see a few other minor discrepancies with the copy of the
version 1.0 spec:
- The version string doesn't match (probably correct)
- EMF_HANDLE_MAX is stored, but the standard says this
  field should always be 0 for disk files
- There is no Unicode description string. This identifier was
  optional in version 1.0 but it may now be required. The comment in
  the spec is that providing such a string in a particular format
  "guarantees that standard information may be obtained from an EMF
   file".

Back to your original query about alternatives -
I spent some time leading up to Version 4  making sure that output
from the SVG terminal was compatible with the various browsers
and viewers I could test.  I don't know what the state of support is
for SVG under Windows, however.  Is that maybe a possible alternative
for you? 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195