gnuplot-beta

Greek letters in the EMF terminal

[James R. V. Z. <jr...@co...>]

Ordinarily I use the EMF or CGM terminals to generate plots for
PowerPoint charts.  However now I have a series of charts where the
labels should include Greek letters, and the EMF terminal's support
for "enhanced text" appears to be broken.  Any labels that use
"enhanced" features (superscripts and/or Symbol font) do not appear at
all.

For example, with this version of gnuplot under Linux:

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified March 2009

and these commands:

   set term emf enhanced
   set label "vanilla label"                          at graph .1,.9
   set label "H_2SO_4"                                at graph .1,.7
   set label "{/Symbol s} is the Greek letter sigma"  at graph .1,.5
   set label "e^{i{/Symbol p}}=-1"                    at graph .1,.3
   set label "abcde"                    font "Symbol" at graph .1,.1
   set out "sine.emf"; plot sin(x); set out

only the first and last labels appear.  The Symbol font is available,
since the last label is displayed with Greek letters.

I also tried this version of gnuplot on Windows XP, with the same result:

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified November 2008
        System: MS-Windows 32 bit

Any suggestions for getting the EMF terminal to work?

        - Jim Van Zandt


p.s. I'll probably wind up adding "enhanced text" support to the CGM
terminal.

Re: Greek letters in the EMF terminal

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

On Tuesday 15 September 2009 13:56:19 James R. Van Zandt wrote:
> 
> Ordinarily I use the EMF or CGM terminals to generate plots for
> PowerPoint charts.  However now I have a series of charts where the
> labels should include Greek letters, and the EMF terminal's support
> for "enhanced text" appears to be broken.  Any labels that use
> "enhanced" features (superscripts and/or Symbol font) do not appear at
> all.
> 
> For example, with this version of gnuplot under Linux:
> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified March 2009
> 
> and these commands:
> 
>    set term emf enhanced
>    set label "vanilla label"                          at graph .1,.9
>    set label "H_2SO_4"                                at graph .1,.7
>    set label "{/Symbol s} is the Greek letter sigma"  at graph .1,.5
>    set label "e^{i{/Symbol p}}=-1"                    at graph .1,.3
>    set label "abcde"                    font "Symbol" at graph .1,.1
>    set out "sine.emf"; plot sin(x); set out
> 
> only the first and last labels appear.  The Symbol font is available,
> since the last label is displayed with Greek letters.

Sorry. I can't reproduce this at all.
I attach the emf output from running your script, and also a screenshot
of what the emf file looks like when viewed with the windows utility
program ENHMETA.EXE.    All looks as it should. 

I'll also send you (offline) a powerpoint with the figure embedded in it.
That's not a test that I've made before.

> I also tried this version of gnuplot on Windows XP, with the same result:
> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified November 2008
>         System: MS-Windows 32 bit
> 
> Any suggestions for getting the EMF terminal to work?

So far as I know, the EMF terminal works fine.
The big problem we have is that some [all?] versions of Windows
have difficulty viewing them.   

Here was my acid test:
I borrowed a dual boot machine  (Windows + linux),  and copied to it
a *.emf produced by gnuplot.  I then fired up the same viewer program
executable to display it, once after booting to linux and once after
booting to Windows.  The emf file displayed correctly when booted to linux, 
but not when booted to Windows.  Since the program and the input file are 
identical, My best guess is that this is due to a buggy *.dll in the
Windows installation, but that's only a guess.  

I'd love it if someone could pin down where or what the problem is.
It is quite possible that if we knew where the Windows bug lies, we
could modify the gnuplot output so as not to trigger it.  But this is
something I obviously can't do on my linux machines, since the bug
doesn't trigger when you run Windows programs under wine.

>         - Jim Van Zandt
> 
> 
> p.s. I'll probably wind up adding "enhanced text" support to the CGM
> terminal.

That would be great.  But I'd still like to fix the emf problem!

-- 
Ethan A Merritt

Re: Greek letters in the EMF terminal

[Allin C. <cot...@wf...>]

On Tue, 15 Sep 2009, Ethan Merritt wrote:

> On Tuesday 15 September 2009 13:56:19 James R. Van Zandt wrote:
> >
> > Ordinarily I use the EMF or CGM terminals to generate plots for
> > PowerPoint charts.  However now I have a series of charts where the
> > labels should include Greek letters, and the EMF terminal's support
> > for "enhanced text" appears to be broken.  Any labels that use
> > "enhanced" features (superscripts and/or Symbol font) do not appear at
> > all.
> >
> > For example, with this version of gnuplot under Linux:
> >
> >         G N U P L O T
> >         Version 4.3 patchlevel 0
> >         last modified March 2009
> >
> > and these commands:
> >
> >    set term emf enhanced
> >    set label "vanilla label"                          at graph .1,.9
> >    set label "H_2SO_4"                                at graph .1,.7
> >    set label "{/Symbol s} is the Greek letter sigma"  at graph .1,.5
> >    set label "e^{i{/Symbol p}}=-1"                    at graph .1,.3
> >    set label "abcde"                    font "Symbol" at graph .1,.1
> >    set out "sine.emf"; plot sin(x); set out
> >
> > only the first and last labels appear...
>
> Sorry. I can't reproduce this at all.

Nor here, with

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified August 2009
        System: Linux 2.6.24-24-generic

All the labels display correctly when I view the emf file in
OpenOffice.org 2.4.

Allin Cottrell

Re: Greek letters in the EMF terminal

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Tuesday 15 September 2009 13:56:19 James R. Van Zandt wrote:
>> Ordinarily I use the EMF or CGM terminals to generate plots for
>> PowerPoint charts.  However now I have a series of charts where the
>> labels should include Greek letters, and the EMF terminal's support
>> for "enhanced text" appears to be broken.  Any labels that use
>> "enhanced" features (superscripts and/or Symbol font) do not appear at
>> all.
>>
>> For example, with this version of gnuplot under Linux:
>>
>>         G N U P L O T
>>         Version 4.3 patchlevel 0
>>         last modified March 2009
>>
>> and these commands:
>>
>>    set term emf enhanced
>>    set label "vanilla label"                          at graph .1,.9
>>    set label "H_2SO_4"                                at graph .1,.7
>>    set label "{/Symbol s} is the Greek letter sigma"  at graph .1,.5
>>    set label "e^{i{/Symbol p}}=-1"                    at graph .1,.3
>>    set label "abcde"                    font "Symbol" at graph .1,.1
>>    set out "sine.emf"; plot sin(x); set out
>>
>> only the first and last labels appear.  The Symbol font is available,
>> since the last label is displayed with Greek letters.
> 
> Sorry. I can't reproduce this at all.
> I attach the emf output from running your script, and also a screenshot
> of what the emf file looks like when viewed with the windows utility
> program ENHMETA.EXE.    All looks as it should. 
> 
> I'll also send you (offline) a powerpoint with the figure embedded in it.
> That's not a test that I've made before.
> 
>> I also tried this version of gnuplot on Windows XP, with the same result:
>>
>>         G N U P L O T
>>         Version 4.3 patchlevel 0
>>         last modified November 2008
>>         System: MS-Windows 32 bit
>>
>> Any suggestions for getting the EMF terminal to work?
> 
> So far as I know, the EMF terminal works fine.
> The big problem we have is that some [all?] versions of Windows
> have difficulty viewing them.   
> 
> Here was my acid test:
> I borrowed a dual boot machine  (Windows + linux),  and copied to it
> a *.emf produced by gnuplot.  I then fired up the same viewer program
> executable to display it, once after booting to linux and once after
> booting to Windows.  The emf file displayed correctly when booted to linux, 
> but not when booted to Windows.  Since the program and the input file are 
> identical, My best guess is that this is due to a buggy *.dll in the
> Windows installation, but that's only a guess.  
> 
> I'd love it if someone could pin down where or what the problem is.
> It is quite possible that if we knew where the Windows bug lies, we
> could modify the gnuplot output so as not to trigger it.  But this is
> something I obviously can't do on my linux machines, since the bug
> doesn't trigger when you run Windows programs under wine.

If I do the following change

diff -r 0cb8214be97a term/emf.trm
--- a/term/emf.trm	Wed Aug 26 16:14:37 2009 +0200
+++ b/term/emf.trm	Wed Sep 16 16:26:48 2009 +0200
@@ -1496,7 +1496,7 @@
  	    }
  	    EMF_write_long(strlen(str)); 	/* true number of characters */
  	    EMF_write_long(76);			/* offset to text */
-	    EMF_write_long(ETO_NO_RECT);	/* ExtTextOut options */
+	    EMF_write_long(0);	/* ExtTextOut options */
  	    EMF_write_rectl(0, 0, 0, 0);	/* bounding, never used */
  	    EMF_write_long(0);			/* offset to intercharacter spacing array */
  	    for (i = 0; i < len; i++)

then it suddenly *does* work for me. No idea why, though.

I am using the 2009-08-07 CVS snapshot source, running windows xp sp2 / 
w2k sp4 and use IrfanView as viewer.
Also importing the such generated emf picture in word 2003 works, as it 
does when importing into openoffice 3.0.0 (here also the previous emf 
correctly loads, btw).

benjamin

Re: Greek letters in the EMF terminal

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

On Wednesday 16 September 2009, Benjamin Lindner wrote:
> Ethan Merritt wrote:
> > So far as I know, the EMF terminal works fine.
> > The big problem we have is that some [all?] versions of Windows
> > have difficulty viewing them.   
> > 
> 
> If I do the following change
> 
> diff -r 0cb8214be97a term/emf.trm
> --- a/term/emf.trm	Wed Aug 26 16:14:37 2009 +0200
> +++ b/term/emf.trm	Wed Sep 16 16:26:48 2009 +0200
> @@ -1496,7 +1496,7 @@
>   	    }
>   	    EMF_write_long(strlen(str)); 	/* true number of characters */
>   	    EMF_write_long(76);			/* offset to text */
> -	    EMF_write_long(ETO_NO_RECT);	/* ExtTextOut options */
> +	    EMF_write_long(0);	/* ExtTextOut options */
>   	    EMF_write_rectl(0, 0, 0, 0);	/* bounding, never used */
>   	    EMF_write_long(0);			/* offset to intercharacter spacing array */
>   	    for (i = 0; i < len; i++)
> 
> then it suddenly *does* work for me. No idea why, though.

That's a huge help (though a total mystery).
How did you think of changing that write in particular?

Microsoft Developer Network documentation states:
	ETO_NO_RECT: This bit indicates that the record does not 
	             specify a bounding rectangle for the text output.

And in fact we don't provide one (see 2 lines below "never user").

Re: Greek letters in the EMF terminal

[Benjamin L. <lin...@gm...>]

Ethan Merritt wrote:
> On Wednesday 16 September 2009, Benjamin Lindner wrote:
>> Ethan Merritt wrote:
>>> So far as I know, the EMF terminal works fine.
>>> The big problem we have is that some [all?] versions of Windows
>>> have difficulty viewing them.   
>>>
>> If I do the following change
>>
>> diff -r 0cb8214be97a term/emf.trm
>> --- a/term/emf.trm	Wed Aug 26 16:14:37 2009 +0200
>> +++ b/term/emf.trm	Wed Sep 16 16:26:48 2009 +0200
>> @@ -1496,7 +1496,7 @@
>>   	    }
>>   	    EMF_write_long(strlen(str)); 	/* true number of characters */
>>   	    EMF_write_long(76);			/* offset to text */
>> -	    EMF_write_long(ETO_NO_RECT);	/* ExtTextOut options */
>> +	    EMF_write_long(0);	/* ExtTextOut options */
>>   	    EMF_write_rectl(0, 0, 0, 0);	/* bounding, never used */
>>   	    EMF_write_long(0);			/* offset to intercharacter spacing array */
>>   	    for (i = 0; i < len; i++)
>>
>> then it suddenly *does* work for me. No idea why, though.
> 
> That's a huge help (though a total mystery).
> How did you think of changing that write in particular?

:) I saw that calls to EMF_put_text() succeeded, but calls to 
ENHemf_FLUSH() not. And though the comment in ENHemf_FLUSH() states that 
the particular section is copied from EMF_put_text(), it actually 
differs in this particular write. So I just tried and it worked.

> Microsoft Developer Network documentation states:
> 	ETO_NO_RECT: This bit indicates that the record does not 
> 	             specify a bounding rectangle for the text output.
> 
> And in fact we don't provide one (see 2 lines below "never user").
> 

Yes, I read this, and it got me confused, and I began to wonder if 
"don't provide" and "write a record as all-zeros" is the same.

The reference to the ETO_NO_RECT in 
http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx
states

"If ETO_NO_RECT is set in the fuOptions field, the Bounds field is not 
included in the record."

This sounds more like the Bounds fields is not present, not simply 
specified as all-zero. And indeed 
http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx:

"Bounds (16 bytes): An optional, 128-bit  WMF  RectL object ([MS-WMF] 
section  2.2.2.19) that specifies the bounding rectangle in device 
units." (for the EMR_SMALLTEXTOUT Record) and

http://msdn.microsoft.com/en-us/library/cc230576%28PROT.10%29.aspx:
"Rectangle (16 bytes): An optional WMF  RectL object ([MS-WMF] section 
2.2.2.19) that defines a clipping and/or opaquing rectangle in logical 
units." (for the EMRTEXT Record)

In both cases it's an "optional" Rectangular object. So I wonder whether 
specifying ETO_NO_RECT means that this particular Rectangular clipping 
object is to be omitted from the EMF file.

benjamin

Re: Greek letters in the EMF terminal

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

On Wednesday 16 September 2009 10:26:37 Benjamin Lindner wrote:
> Ethan Merritt wrote:
> > On Wednesday 16 September 2009, Benjamin Lindner wrote:
> >> Ethan Merritt wrote:
> >>> So far as I know, the EMF terminal works fine.
> >>> The big problem we have is that some [all?] versions of Windows
> >>> have difficulty viewing them.   
> >>>
> >> If I do the following change
> >>
> >> diff -r 0cb8214be97a term/emf.trm
> >> --- a/term/emf.trm	Wed Aug 26 16:14:37 2009 +0200
> >> +++ b/term/emf.trm	Wed Sep 16 16:26:48 2009 +0200
> >> @@ -1496,7 +1496,7 @@
> >>   	    }
> >>   	    EMF_write_long(strlen(str)); 	/* true number of characters */
> >>   	    EMF_write_long(76);			/* offset to text */
> >> -	    EMF_write_long(ETO_NO_RECT);	/* ExtTextOut options */
> >> +	    EMF_write_long(0);	/* ExtTextOut options */
> >>   	    EMF_write_rectl(0, 0, 0, 0);	/* bounding, never used */
> >>   	    EMF_write_long(0);			/* offset to intercharacter spacing array */
> >>   	    for (i = 0; i < len; i++)
> >>
> >> then it suddenly *does* work for me. No idea why, though.
> > 
> > That's a huge help (though a total mystery).
> > How did you think of changing that write in particular?
> 
> :) I saw that calls to EMF_put_text() succeeded, but calls to 
> ENHemf_FLUSH() not. And though the comment in ENHemf_FLUSH() states that 
> the particular section is copied from EMF_put_text(), it actually 
> differs in this particular write. So I just tried and it worked.
> 
> > Microsoft Developer Network documentation states:
> > 	ETO_NO_RECT: This bit indicates that the record does not 
> > 	             specify a bounding rectangle for the text output.
> > 
> > And in fact we don't provide one (see 2 lines below "never user").
> > 
> 
> Yes, I read this, and it got me confused, and I began to wonder if 
> "don't provide" and "write a record as all-zeros" is the same.
> 
> The reference to the ETO_NO_RECT in 
> http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx
> states
> 
> "If ETO_NO_RECT is set in the fuOptions field, the Bounds field is not 
> included in the record."
> 
> This sounds more like the Bounds fields is not present, not simply 
> specified as all-zero. And indeed 
> http://msdn.microsoft.com/en-us/library/cc230599%28PROT.13%29.aspx:
> 
> "Bounds (16 bytes): An optional, 128-bit  WMF  RectL object ([MS-WMF] 
> section  2.2.2.19) that specifies the bounding rectangle in device 
> units." (for the EMR_SMALLTEXTOUT Record) and
> 
> http://msdn.microsoft.com/en-us/library/cc230576%28PROT.10%29.aspx:
> "Rectangle (16 bytes): An optional WMF  RectL object ([MS-WMF] section 
> 2.2.2.19) that defines a clipping and/or opaquing rectangle in logical 
> units." (for the EMRTEXT Record)
> 
> In both cases it's an "optional" Rectangular object. So I wonder whether 
> specifying ETO_NO_RECT means that this particular Rectangular clipping 
> object is to be omitted from the EMF file.

If so, it's strange that the current version works in any viewer at all.
I should think that getting the record length wrong would break the
linux and OpenOffice implementations as well as the Windows implementation.
On the other hand, there is an explicit offset field.
Maybe the bug is that the Windows implementation doesn't pay attention to
the offset field, and instead walks through the number of records it expects
to read?  That would fit the observed behavior, I think.

Ah well, an empirical fix is better than no fix at all.
I'll make the change in CVS and hope it gets some testing via the
4.4 release candidate.  



-- 
Ethan A Merritt

Re: Greek letters in the EMF terminal

[James R. V. Z. <jr...@co...>]

Ethan Merritt <merritt@u.washington.edu> wrote:
> On Tuesday 15 September 2009 13:56:19 James R. Van Zandt wrote:
> > 
> > ...the EMF terminal's support for "enhanced text" appears to be
> > broken.  Any labels that use "enhanced" features (superscripts
> > and/or Symbol font) do not appear at all.
>
> Sorry. I can't reproduce this at all.
> I attach the emf output from running your script, and also a screenshot
> of what the emf file looks like when viewed with the windows utility
> program ENHMETA.EXE.    All looks as it should. 
>
> I'll also send you (offline) a powerpoint with the figure embedded in it.
> That's not a test that I've made before.
>
> And here it is.  Looks fine in PowerPoint run under linux, although the
> font is way too small.

When I use PowerPoint 2003 under Windows XP to view your PowerPoint
file, or to import your .emf file, only two of the labels are shown.
That's what I saw using PowerPoint 2007 under XP on a different machine.

However: If I select the figure and navigate to Drawing | Ungroup, it
tells me that isn't a drawing but a picture, and offers to convert it
to a drawing object.  If I do that, the rest of the labels appear.  If
I "ungroup" , then I can select and edit individual characters of the
labels.

I theorize that the .emf file, like an encapsulated PostScript file,
includes not only the vector drawing commands and label characters,
but also a bitmapped preview of the figure.  When PowerPoint 2003
imports the file, it only shows the bitmap.  However, the bitmap
either omits some labels, or includes them in a way PowerPoint misses.
When PowerPoint "converts to a drawing object", it re-renders the
display and all is well.

PowerPoint will only let me zoom to 400 percent.  If I do that before
the "conversion to a drawing object", the characters are starting to
look pixelated, but no more so than for a new label of the same size.
That suggests if the preview is a bitmap, it must be at a fairly high
resolution, like 300 bpi.

Allin Cottrell writes:
> All the labels display correctly when I view the emf file in
> OpenOffice.org 2.4.

And version 3.1.0 shows it correctly here.  I guess oo either
correctly interprets the bitmap, or else re-renders the display from
the vector commands and character codes.  oo does not let me select
individual elements of the figure (lines, labels, or characters) or to
"ungroup".  That suggests it's showing a bitmap.  On the other hand, I
can zoom way in (3000 percent) on a character or a sloping line without
seeing any pixelation, which indicated it's *not* just showing a
bitmap.  I guess oo can render the vector commands but not edit them.


I still think there's an incompatibility between the gnuplot .emf file
and what PowerPoint expects, but now I have a workaround.

           - Jim Van Zandt