gnuplot-beta — Developers and beta testers of new gnuplot code

Re: More domain name confusion?

[Philipp K. J. <ja...@ie...>]

>
> www.gnuplot.info should *always* be the canonical site!

Sorry, but I'd like to challenge that.

The master site is gnuplot.sourceforge.net.

At least, that's where the master copies of
all files live. It's also the site that the developer
team has access to.

I think it's great that somebody (Clark) has
registered a more informative domain name
(and pays for it). (Thanks, Clark!) But I don't 
understand why that domain name is not either 
an alias or a redirect to the SourceForge site.

I think it is highly confusing that the site that
*appears* to be canonical (at least by its 
domain name) is in fact a merely *mirror*.
(And it is confusing and not widely understood
even by the developer team - as demonstrated 
by the discussion a few weeks ago on this mailing
list.)

It's great that there is a mirror - in case 
SourceForge is down or not accessible. 
But it should be made clearer that it is 
exactly that: a mirror. 

I am also uncomfortable with the idea of 
hosting the "canonical" site for a community
project like gnuplot on a server that only the 
owner has access to. (Single point of failure,
all that.)

What is wrong with having the "canonical"
site be the SourceForge site? (I heard the
argument that Virginia Tech has better 
internet connectivity than SourceForge,
but I find that hard to believe. And even if
true, SourceForge's infrastructure seems
at least sufficient.)

I'd vote for making gnuplot.sourceforge.net
be the "canonical" site (and have gnuplot.info
point to it), and making Clark's site at VT the
"official" mirror.

Best,

		Ph.


>
> --ckg
>
>
> --
> Clark Gaylord
> cga...@vt...
>  ... thumbed on my treo ...
> -----Original Message-----
> From: Allin Cottrell <cot...@wf...>
> Date: Sunday, Sep 20, 2009 8:03 pm
> Subject: Re: More domain name confusion?
> To: "Philipp K. Janert" <ja...@ie...>
> CC: gnu...@li...
>
> >On Sun, 20 Sep 2009, Philipp K. Janert wrote:
> >> The domain
> >
> > 	www.gnuplot.vt.edu
> > has been coming up among the top 10 links
> > on Google for "gnuplot" for a few weeks now.
> >
> >> Nothing there yet.
> >
> >No, and let's hope it goes away altogether Real Soon Now.
> >
> >Allin Cottrell
> >
> >--------------------------------------------------------------------------
> >---- Come build with us! The BlackBerry&reg; Developer Conference in SF,
> > CA is the only developer event you need to attend this year. Jumpstart
> > your developing skills, take BlackBerry mobile applications to market and
> > stay ahead of the curve. Join us from November 9-12, 2009. Register now!
> > http://p.sf.net/sfu/devconf
> >_______________________________________________
> >gnuplot-beta mailing list
> >gnu...@li...
> >https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: More domain name confusion?

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

On Sunday 20 September 2009, Clark Gaylord wrote:
> Sorry -- didn't realize that was getting hits. 
> That site is mirroring but I just don't have the virtual host set up.
> 
> www.gnuplot.info should *always* be the canonical site!

In which case... Any idea why the new, not even set up yet site
has such a high Google page rank?

	Ethan

Re: More domain name confusion?

[Clark G. <cga...@vt...>]

Sorry -- didn't realize that was getting hits. That site is mirroring but I just don't have the virtual host set up.

www.gnuplot.info should *always* be the canonical site!

--ckg


--
Clark Gaylord
cga...@vt...
 ... thumbed on my treo ...
-----Original Message-----
From: Allin Cottrell <cot...@wf...>
Date: Sunday, Sep 20, 2009 8:03 pm
Subject: Re: More domain name confusion?
To: "Philipp K. Janert" <ja...@ie...>
CC: gnu...@li...


>On Sun, 20 Sep 2009, Philipp K. Janert wrote:
>
>> The domain
> 	www.gnuplot.vt.edu
> has been coming up among the top 10 links
> on Google for "gnuplot" for a few weeks now.
>
>> Nothing there yet.
>
>No, and let's hope it goes away altogether Real Soon Now.
>
>Allin Cottrell
>
>------------------------------------------------------------------------------ Come build with us! The BlackBerry&reg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay 
>ahead of the curve. Join us from November 9-12, 2009. Register now!
>http://p.sf.net/sfu/devconf
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: More domain name confusion?

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

On Sun, 20 Sep 2009, Philipp K. Janert wrote:

> The domain
> 	www.gnuplot.vt.edu
> has been coming up among the top 10 links
> on Google for "gnuplot" for a few weeks now.
>
> Nothing there yet.

No, and let's hope it goes away altogether Real Soon Now.

Allin Cottrell

More domain name confusion?

[Philipp K. J. <ja...@ie...>]

The domain 
	www.gnuplot.vt.edu
has been coming up among the top 10 links
on Google for "gnuplot" for a few weeks now.

Nothing there yet.

Best,

		Ph.

console mode gnuplot for windows with wxt doen not work (gnuplot 4.3 / mingw)

[Tatsuro M. <tma...@ya...>]

Hello

I have posted a thread about a problem on console mode gnuplot for windows with wxt.
I am using GCC-4.4.0/Mingw. 

The gnuplot.exe (ver 4.3 ) with does not start.

$ gnuplot

Tatsu@INSPIRON6000 /c/Program Files/Gnuplot4.3wxt
$

Without wxt
$ gnuplot


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

 :
 :

However, 
$ gnuplot -e "plot sin(x); pause 1"
and
$ echo 'plot sin(x) ; pause 1'  | gnuplot

works even on gnuplot with wxt.

I have struggled with gdb and found that

(!isatty(fileno(stdin))) is false for the gnuplot without the wxt but true for one without wxt.
I also found taht stdin, stdout, and stderr does not work.

In short,  gnuplot with wxt built on gcc/mingw does not have standard i/o.

Perhaps this may be a side effect with gnuplot linked with wxWedgets.

Michael Goffioul had built the console mode of gnuplot for windows with wxt by MSVC++.

This problem may be specific to the combination of GCC/mingw and wxt.

Does anyone have ideas on this issue ?

Regards

Tatsuro

Tatsuro  
 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

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

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

[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, 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 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

[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

[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

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 SVG terminal

[Christoph B. <us...@be...>]

Mojca Miklavec schrieb:
> I don't know the specification, but removing the space, that means changing
> 	<tspan>e</tspan>
> 	<tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
> into
> 	<tspan>e</tspan><tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
> helped. I don't know whether this classifies as gnuplot problem or
> viewer problem, but I would expect
>     <text>a
>     b
>     c</text>
> to print out "a b c", not "abc", 


But what we have here, is

<text>a</text>
<text>b</text>
<text>c</text>

and then the spaces outside the tag should not matter.

Christoph

Re: Greek letters in the SVG terminal

[<pl...@pi...>]

Ethan Merritt wrote:
> On Monday 14 September 2009 pl...@pi... wrote:
>> help svg refers the user to read help enhanced, this topic contains
>> several refernces to the use of /Symbol :
>>
>>        set xlabel 'Time (10^6 {/Symbol m}s)'
> 
> Hmm. That's a historical artifact. The enhanced text mode was originally a
> feature of the postscript terminal only, so of course the original
> documentation assumed you were using postscript.  It should be re-written.
> 
> 
> On Monday 14 September 2009 13:41:21 Mojca Miklavec wrote:
> 
>>>>  - The superscripted characters are spaced out
>> I don't know the specification, but removing the space, that means changing
>> 	<tspan>e</tspan>
>> 	<tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
>> into
>> 	<tspan>e</tspan><tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
>> helped. I don't know whether this classifies as gnuplot problem or
>> viewer problem, but I would expect
>>     <text>a
>>     b
>>     c</text>
>> to print out "a b c", not "abc", so without reading exact
>> specification, I would vote for browser's behaviour, not for
>> gnuplot's, and that particular problem should be rather trivial to fix
>> in gnuplot itself.
> 
> The SVG spec allows you to either collapse all whitespace into a single blank, 
>    xml:space="default"
> or preserve the whitespace in the input.
>    xml:space="preserve"
> The broken browsers (at least some of them) interpret that to mean
> "preserve all the whitespace in the input, whether or not it is in a tspan
>  element".  This is a problem.  
> I reported the bug via Bugzilla some while ago.

I don't follow how you relate this to the space in super script of this 
example.

The newline in the input represents whitespace and is hence present in 
the rendition of the page as a space. Since it is just one character the 
question of collapse/preserve does not seem to apply. The fact that the 
newline it is not in a tspan does not mean it should be ignored.


The following html snippet displays in a similar way and would seem to 
be correct. Only c and d a juxtaposed (view source if your email client 
is parsing this and showing "a b cd e f")

<html>
<body>

<span>a</span>
<span>b</span>
<span>c</span><span>d</span>
<span>e
f</span>

</body>
</html>

If the desired output is "abc" rather than "a b c" , it needs to be 
output on the same line to prevent inserting whitespace.

regards, Peter.

> 
>> Just a question (I don't know SVG at all, I just saw an example): wouldn't
>>     <tspan baseline-shift = "super">
>> do the job as well?
> 
> I don't think such an SVG element was available at the time the driver was
> written. Perhaps it could be revisited now.  But I don't think this would
> handle nested super- and sub- scripts, so it would not be a complete solution.
> 
> 	Ethan
> 

Re: Greek letters in the SVG terminal

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

On Monday 14 September 2009 pl...@pi... wrote:
>
> help svg refers the user to read help enhanced, this topic contains
> several refernces to the use of /Symbol :
>
>        set xlabel 'Time (10^6 {/Symbol m}s)'

Hmm. That's a historical artifact. The enhanced text mode was originally a
feature of the postscript terminal only, so of course the original
documentation assumed you were using postscript.  It should be re-written.


On Monday 14 September 2009 13:41:21 Mojca Miklavec wrote:

> >>  - The superscripted characters are spaced out
> 
> I don't know the specification, but removing the space, that means changing
> 	<tspan>e</tspan>
> 	<tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
> into
> 	<tspan>e</tspan><tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
> helped. I don't know whether this classifies as gnuplot problem or
> viewer problem, but I would expect
>     <text>a
>     b
>     c</text>
> to print out "a b c", not "abc", so without reading exact
> specification, I would vote for browser's behaviour, not for
> gnuplot's, and that particular problem should be rather trivial to fix
> in gnuplot itself.

The SVG spec allows you to either collapse all whitespace into a single blank, 
   xml:space="default"
or preserve the whitespace in the input.
   xml:space="preserve"
The broken browsers (at least some of them) interpret that to mean
"preserve all the whitespace in the input, whether or not it is in a tspan
 element".  This is a problem.  
I reported the bug via Bugzilla some while ago.

> Just a question (I don't know SVG at all, I just saw an example): wouldn't
>     <tspan baseline-shift = "super">
> do the job as well?

I don't think such an SVG element was available at the time the driver was
written. Perhaps it could be revisited now.  But I don't think this would
handle nested super- and sub- scripts, so it would not be a complete solution.

	Ethan

Re: Greek letters in the SVG terminal

[<pl...@pi...>]

Ethan Merritt wrote:
> On Monday 14 September 2009 10:47:05 James R. Van Zandt wrote:
>> I'm trying to use the svg terminal in a recent version of gnuplot:
>>
>>         G N U P L O T
>>         Version 4.3 patchlevel 0
>>         last modified March 2009
>>
>> I can generate a sample file like this:
>>
>>   set term svg enhanced
>>   set out "sine.svg"
>>   set label "e^{i{/Symbol p}}=-1" at graph .5,.5
>>   plot sin(x)
>>   set out
>>
>> When I display the output using inkscape 0.46, I see three problems:
>>
>>  - All the lines are missing
>>  - The superscripted characters are spaced out
>>  - The Greek letter pi appears as "p".
>>
>> By googling I came up with workarounds for the first two problems:
>>
>>   perl -p -i -e 's/color:([^;]*); *stroke:[^;]*;/color:$1; stroke:$1;/' sine.svg
>>   perl -p -i -e 's/xml:space=.preserve.//' sine.svg
>>
>> Does anyone have suggestions about the Greek letters?
> 
> (1) Fonts
> SVG is an XML variant, which means it natively uses UTF-8 encoding.
> The "Symbol" font is an Adobe-specific encoding that nobody else uses.
> So it works for PostScript and PDF, but probably nothing else.
> Use UTF-8
> 
help svg refers the user to read help enhanced, this topic contains 
several refernces to the use of /Symbol :

       set xlabel 'Time (10^6 {/Symbol m}s)'

this produces the following svg code:
<tspan style="font-family:Symbol" >m</tspan>

as James noted this does not give the expected results. My guess is the 
system in question does not have a font called Symbol and is falling 
back to a substitute that has little to do with the Adobe font.

This may be useful:
http://www1.tip.nl/~t876506/EntitiesXHTML1.html

> (2) Spacing
> Inkscape is broken.  
> But hey, so are all the other SVG viewers I know of.
> 
> (3) General problems
> We worked with the Sodipodi developers to fix a bunch of problems, 
> but when Sodipodi was forked to Inkscape they seem
> to have forked it from an unfixed version.
> 
> On a similar note, in KDE3 the ksvg viewer was probably the best of
> a bad lot.  But KDE4 switched to something else that doesn't work at all well.
> 
> I've given up on SVG.
> 
> I suggest to use the canvas terminal instead.
> 

I know that Ethan is very down heartened by SVG viewers and probably 
with some justfication having worked on fixing things only see them 
reverted. He has probably gone into some considerable detail in testing 
a broad range of features  but I can say for my usage of embedding plots 
inside  html and having javascript make it interact with machine control 
software on the server there are several viewers that work well.

Firefox3 , very good major improvement on ff 2.x
opera9 (OK over http but displays source on local file open)
ksvg from kde3 . (Have not tested svg on kde4 since the whole of kde 4 
is still work in progress at this time.)

Inkscape was not much use for anything last time I looked and trying to 
help by reporting bugs got me a "fix it yourself if you're not happy" 
attitude :(  So sodipodioffi as far as I'm concerned.


HTH

Re: Greek letters in the SVG terminal

[Mojca M. <moj...@gm...>]

On Mon, Sep 14, 2009 at 19:59, Ethan Merritt wrote:
> On Monday 14 September 2009 10:47:05 James R. Van Zandt wrote:
>>
>> I can generate a sample file like this:
>>
>>   set term svg enhanced
>>   set out "sine.svg"
>>   set label "e^{i{/Symbol p}}=-1" at graph .5,.5
>>   plot sin(x)
>>   set out
>>
>> When I display the output using inkscape 0.46, I see three problems:
>>
>>  - All the lines are missing

I see them in Safari and Firefox, but I'm not sure about Inkscape and
I have no idea about proper SVG syntax.

>>  - The superscripted characters are spaced out

I don't know the specification, but removing the space, that means changing
	<tspan>e</tspan>
	<tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
into
	<tspan>e</tspan><tspan font-size="9.6pt" dy="-6.00pt">iπ</tspan>
helped. I don't know whether this classifies as gnuplot problem or
viewer problem, but I would expect
    <text>a
    b
    c</text>
to print out "a b c", not "abc", so without reading exact
specification, I would vote for browser's behaviour, not for
gnuplot's, and that particular problem should be rather trivial to fix
in gnuplot itself.

Just a question (I don't know SVG at all, I just saw an example): wouldn't
    <tspan baseline-shift = "super">
do the job as well?

>>  - The Greek letter pi appears as "p".
>>
>> By googling I came up with workarounds for the first two problems:
>>
>>   perl -p -i -e 's/color:([^;]*); *stroke:[^;]*;/color:$1; stroke:$1;/' sine.svg
>>   perl -p -i -e 's/xml:space=.preserve.//' sine.svg
>>
>> Does anyone have suggestions about the Greek letters?
>
> (1) Fonts
> SVG is an XML variant, which means it natively uses UTF-8 encoding.
> The "Symbol" font is an Adobe-specific encoding that nobody else uses.
> So it works for PostScript and PDF, but probably nothing else.
> Use UTF-8

I agree. The following line:
    set label "e^{iπ}=-1" at graph .5,.5
works as expected (I don't know if you are able to read it though;
it's an UTF-8 letter pi). The PostScript example in as "ugly hack"
only.

Mojca

Re: Greek letters in the SVG terminal

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

On Monday 14 September 2009 10:47:05 James R. Van Zandt wrote:
> 
> I'm trying to use the svg terminal in a recent version of gnuplot:
> 
>         G N U P L O T
>         Version 4.3 patchlevel 0
>         last modified March 2009
> 
> I can generate a sample file like this:
> 
>   set term svg enhanced
>   set out "sine.svg"
>   set label "e^{i{/Symbol p}}=-1" at graph .5,.5
>   plot sin(x)
>   set out
> 
> When I display the output using inkscape 0.46, I see three problems:
> 
>  - All the lines are missing
>  - The superscripted characters are spaced out
>  - The Greek letter pi appears as "p".
> 
> By googling I came up with workarounds for the first two problems:
> 
>   perl -p -i -e 's/color:([^;]*); *stroke:[^;]*;/color:$1; stroke:$1;/' sine.svg
>   perl -p -i -e 's/xml:space=.preserve.//' sine.svg
> 
> Does anyone have suggestions about the Greek letters?

(1) Fonts
SVG is an XML variant, which means it natively uses UTF-8 encoding.
The "Symbol" font is an Adobe-specific encoding that nobody else uses.
So it works for PostScript and PDF, but probably nothing else.
Use UTF-8

(2) Spacing
Inkscape is broken.  
But hey, so are all the other SVG viewers I know of.

(3) General problems
We worked with the Sodipodi developers to fix a bunch of problems, 
but when Sodipodi was forked to Inkscape they seem
to have forked it from an unfixed version.

On a similar note, in KDE3 the ksvg viewer was probably the best of
a bad lot.  But KDE4 switched to something else that doesn't work at all well.

I've given up on SVG.

I suggest to use the canvas terminal instead.

-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Greek letters in the SVG terminal

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

I'm trying to use the svg terminal in a recent version of gnuplot:

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

I can generate a sample file like this:

  set term svg enhanced
  set out "sine.svg"
  set label "e^{i{/Symbol p}}=-1" at graph .5,.5
  plot sin(x)
  set out

When I display the output using inkscape 0.46, I see three problems:

 - All the lines are missing
 - The superscripted characters are spaced out
 - The Greek letter pi appears as "p".

By googling I came up with workarounds for the first two problems:

  perl -p -i -e 's/color:([^;]*); *stroke:[^;]*;/color:$1; stroke:$1;/' sine.svg
  perl -p -i -e 's/xml:space=.preserve.//' sine.svg

Does anyone have suggestions about the Greek letters?

        - Jim Van Zandt

Re: launch help in pdf or on web

[Tatsuro M. <tma...@ya...>]

Hello

--- Hans-Bernhard Br将モker wrote:

> Same problem here --- and no, none of the proposed fixes I've found 
> work.  The DLLs are as registered as can be; and the RTF file doesn't 
> contain the problems mentioned by helpfulsolutions.com.

I also could not get successful results
> 
> Help workshop does include a command line tool (hhc).  But that will 
> only work  once we have a working HTML Help Workshop project file, and a 
> help sourcefile in HTML, not RTF.
> 
> I'm not convinced it's worth our while trying to use CHM.  If the fate 
> of 32bit Winhelp is any reference, CHM will vanish just as soon as we're 
> fully set up to create it.

Absolutely!!
On next January, 'windows 7' is coming up. HTML Help Workshop came up ten years ago.
What Hans is say is perhaps right.

It is better to wait a while whether Microsoft do the next action on help system for the next
generation.   

The possible way to use HTML Help Workshop to generate compact html style manual.
It reduces the size very well. For this purpose, HTML Help Workshop is not bad.
This chm file need not to be included in official release and I will upload it on my web.
Of course this is temporal treatment.

Regards

Tatsuro



--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: launch help in pdf or on web

[Hans-Bernhard B. <HBB...@t-...>]

Petr Mikulik wrote:

> HTML Help Workshop says it can convert rtf (such as gnuplot.rtf) into CHM. 
> However, it does not work for me -- on WXP or Wine it says that some DLLs 
> are incorrect.

Same problem here --- and no, none of the proposed fixes I've found 
work.  The DLLs are as registered as can be; and the RTF file doesn't 
contain the problems mentioned by helpfulsolutions.com.

> I wonder whether MS HTML Help Workshop is the only tool. Isn't there some 
> other tool, e.g. such that can be operated from a command line as the HCW 
> currently used?

Help workshop does include a command line tool (hhc).  But that will 
only work  once we have a working HTML Help Workshop project file, and a 
help sourcefile in HTML, not RTF.

I'm not convinced it's worth our while trying to use CHM.  If the fate 
of 32bit Winhelp is any reference, CHM will vanish just as soon as we're 
fully set up to create it.

Re: launch help in pdf or on web

[Tatsuro M. <tma...@ya...>]

Hello

Hmmmmm!

--- Tatsuro MATSUOKA wrote:

> Hello
> 

> I have met the same errors.  I googled again and found the page.
> 
> http://www.helpfulsolutions.com/
> 
> HTML Help DLL Registrar - ...........This little program asks you where you installed HTML Help
> Workshop and then registers all of the DLLs it requires..................
> 
> HLP to HTML Help Convertor Fixer - ..... "The DLLs necessary to convert RTF to HTML have not
> been
> installed correctly. Reinstall HTML Help Workshop and try again." is somewhat bogus............

and I tried
http://support.microsoft.com/kb/255123

The error 

The DLLs necessary to convert RTF to HTML have not been installed correctly

could not be solved. :-(

Regards

Tatsuro


--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/

Re: launch help in pdf or on web

[Tatsuro M. <tma...@ya...>]

Hello

--- Petr Mikulik wrote:

> HTML Help Workshop says it can convert rtf (such as gnuplot.rtf) into CHM. 
> However, it does not work for me -- on WXP or Wine it says that some DLLs 
> are incorrect.
> 
> Has somebody succeeded?
I have met the same errors.  I googled again and found the page.

http://www.helpfulsolutions.com/

HTML Help DLL Registrar - ...........This little program asks you where you installed HTML Help
Workshop and then registers all of the DLLs it requires..................

HLP to HTML Help Convertor Fixer - ..... "The DLLs necessary to convert RTF to HTML have not been
installed correctly. Reinstall HTML Help Workshop and try again." is somewhat bogus............


I will try them
> 
> > Now html documents in 'make' are produced by latex2html.
> > I have tried the above. However, my limited ability and time prevents me to go ahead :-( .
> >
> > http://www.geocities.jp/tmgpltwin/Files/Files.html
> > 0022 gnuplot.chm.zip, 376,810 bytes, 2009-09-07, zipped gnuplot.chm file 
> > generated by HTML Help Complier
> >
> > The above file was made by mere translattion of htmldocs of the recent cvs 
> > sources. That is a mere test of HTML Help Complier.
> 
> How have you managed to include Contents and Index?
> 
> 
> I wonder whether MS HTML Help Workshop is the only tool. Isn't there some 
> other tool, e.g. such that can be operated from a command line as the HCW 
> currently used?

That was a mere test so that contents and index were not treated.  To get complete help, of course, we
have to treat the contents an index.  I have not try them yet.

>Isn't there some 
> other tool, e.g. such that can be operated from a command line as the HCW 
> currently used?

I have looking about the help. I cannot find the description of  command line.
Script writing by WSH (Windows script host) might be possible to treat it from command line.

Regards

Tatsuro
 


 

--------------------------------------
Thanks 10 years!  Yahoo! Shopping and Yahoo! Auctions
http://pr.mail.yahoo.co.jp/ec10years/