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

[Fwd: FW: Gnuplot ..]

[Lars H. <lhe...@us...>]

----- Forwarded message from Jonathan Lawson <jon...@bi...> -----

From: Jonathan Lawson <jon...@bi...>
To: lhe...@us...
Subject: FW: Gnuplot  ..
Date: Thu, 11 Oct 2007 13:27:01 +0100

You are a really tricky one to track down ... 

 

  _____  

From: Jonathan Lawson 
Sent: Thursday, October 11, 2007 11:39 AM
To: 'lhe...@nm...'
Subject: Gnuplot ..

 

Hi Lars,

            Trust all remains well with you ... I was trying to plot data
from a CSV file, which I did with the following difficulty:

If there was a blank space following the commas in the file, there was no
problem; however if there are no white spaces following the commas then
gnuplot reports that it contains no valid data. But it does this only on
complex files: A simple file with comma separated data seems to work fine. I
have attached the file in question and the command which I am using to plot
the data is

 

Plot "Filename" u 3

 

Where Filename is either one of the files attached to this email. My version
of Gnuplot is given below

 

        G N U P L O T

        Version 4.2 patchlevel 0

        last modified March 2007

        System: MS-Windows 32 bit

 

        Copyright (C) 1986 - 1993, 1998, 2004, 2007

        Thomas Williams, Colin Kelley and many others

 

        Type `help` to access the on-line reference manual.

        The gnuplot FAQ is available from

                http://www.gnuplot.info/faq/

 

        Send comments and help requests to
<gnu...@li...>

 

        Send bug reports and suggestions to
<gnu...@li...>

 

 

 

Any chance you could help?

 

Regards

 

 

 

Jonathan Lawson

 


BIOQUELL UK Ltd.

Walworth Road, Andover SP10 5AA. UK

 

w: www.bioquell.com


t:  +44 (0) 1264 835 862 

e:  jon...@bi... <mailto:jon...@bi...> 

f:  +44 (0)1264 835 836 

 

 



This message has been scanned for viruses by BlackSpider MailControl - www.blackspider.com


--- StripMime Report -- processed MIME parts ---
multipart/alternative
  text/plain (text body -- kept)
  text/html
---


----- End forwarded message -----

Re: Suggestion for dgrid3d

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

> > The sum runs over all input data points, and the
> > weight function w is essentially an inverse power
> > of the distance between each data point and the
> > current grid point:
> > 	w = 1/dist**p      for some integer p
>
> You underestimate the consequences of that little word "essentially" a
> bit.  The actual formula of course is
>
> 	sum(w_i * data_i) / sum(w_i)
>
> just as it should be for w_i to deserve being called a "weight".

Absolutely. And if you had bothered to look
at the attached code, you would have seen
that this is exactly what is being done. I am
not proposing a change here.

But why a weight function w_i that is 
1) discontinuous
2) grows above all bounds?

If nothing else, numerically this is not 
good (round-off). But it also does not
seem to be right that if a grid point
coincides exactly with a data point, it
gets weight 1, and weight 1/eps >> 1 
if the grid point is shifted by a very small
amount eps << 1 from the grid point.


> There is no such radius, and thus no need to control it.

Well, I disagree. The documentation says
the current algo is basically a "low pass
filter". So I want a way to control the width
of the pass band of the filter.


>
> I don't think there should be any such radius at all, in the typical
> case.  The algorithm should be independent of the x and y range of its
> input, if at all possible.

Exactly. But the current one isn't. If x values
are spaced by 100, and y values spaced by 1
in x and y units, the weight function will behave
differently in both directions. The right way to 
do this is to give users (who know their data
and how noisy it is, etc) the opportunity to scale
the distances themselves - thusly achieving
exactly what you propose.

Re: Suggestion for dgrid3d

[<HBB...@t-...>]

Philipp K. Janert wrote:
> I was just playing with dgrid3d, and had some 
> difficulties getting rather "smooth" input data
> to come out "just right". So I looked into the
> implementation for dgrid3d and wanted to make
> a suggestion.
> 
> Context:
> ======
> dgrid3d evaluates (possibly ungridded) input data
> and calculates a smooth approximation to it on a
> regular grid. The values assigned to each grid point
> are essentially weighted averages:
> 	sum_{all points} w_i * data_i
> The sum runs over all input data points, and the
> weight function w is essentially an inverse power
> of the distance between each data point and the
> current grid point:
> 	w = 1/dist**p      for some integer p

You underestimate the consequences of that little word "essentially" a 
bit.  The actual formula of course is

	sum(w_i * data_i) / sum(w_i)

just as it should be for w_i to deserve being called a "weight".

> Problem:
> ======
> This particular choice of weight function has a few
> disadvantages:
> 1) for dist==0, it is undefined (requiring treatment
> 	as special case)
> 2) for dist > 0 but small, the weight can become
> 	arbitrarily large

As will the sum(w_i), so that levels out.

> 3) for large p, each individual data point totally 
> 	dominates all grid points within dist < 1, but
> 	is irrelevant once dist > 1, with an abrupt
> 	change in behaviour at dist=1 if p gets large.

The normalization by sum(w_i) removes any special role of dist=1.0.

And of course, nobody's being forced to use large p. ;-)

> 4) no way to control the "radius of influence" or
> 	catchment area for data points

There is no such radius, and thus no need to control it.

> I think it would be desirable to have a weight function
> with the following properties:
> 1) bounded

Check, for the actual dgrid3d function, thanks to the sum(w_i) term.

> 2) w( d=0 ) = 1

effectively the case for the actual dgrid3d algorithm (by way of 
special-casing d=0).

> 3) falling smoothly as d -> infty

check.

> 4) have a parameter which smoothly controls the
> 	size of the "catchment radius".

I don't think there should be any such radius at all, in the typical 
case.  The algorithm should be independent of the x and y range of its 
input, if at all possible.

Are you aware of, or have you even tried the alternative dgrid3d 
algorithm, thin plate splines?

Suggestion for dgrid3d

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

I was just playing with dgrid3d, and had some 
difficulties getting rather "smooth" input data
to come out "just right". So I looked into the
implementation for dgrid3d and wanted to make
a suggestion.

Context:
======
dgrid3d evaluates (possibly ungridded) input data
and calculates a smooth approximation to it on a
regular grid. The values assigned to each grid point
are essentially weighted averages:
	sum_{all points} w_i * data_i
The sum runs over all input data points, and the
weight function w is essentially an inverse power
of the distance between each data point and the
current grid point:
	w = 1/dist**p      for some integer p

Problem:
======
This particular choice of weight function has a few
disadvantages:
1) for dist==0, it is undefined (requiring treatment
	as special case)
2) for dist > 0 but small, the weight can become
	arbitrarily large
3) for large p, each individual data point totally 
	dominates all grid points within dist < 1, but
	is irrelevant once dist > 1, with an abrupt
	change in behaviour at dist=1 if p gets large.
4) no way to control the "radius of influence" or
	catchment area for data points

Suggestion:
========
I think it would be desirable to have a weight function
with the following properties:
1) bounded
2) w( d=0 ) = 1
3) falling smoothly as d -> infty
4) have a parameter which smoothly controls the
	size of the "catchment radius".

A Gaussian is the first thing that comes to mind.

I have tried it and quite like the results. I have 
posted some example images comparing Gaussian
weighting vs the power law weighting at:
	www.philipp-janert.com/gnuplot

Optional:
======
I have hijacked the "norm" parameter to 
control the width of the Gaussian. This is
not ideal - a better solution would be to
extend the dgrid3d option in such a way
that it can take two float values (instead
of an int), which can be used to scale the
x- and y-distances independently.

Attached, you will find a patch file (against 
CVS head) containing the changes to use
a Gaussian instead of a power law. They
do not include the "optional" feature 
mentioned above. 

Please let me know what you think. I have 
not prepared a patch to the documentation
yet - I'd like to hear opinions on this 
suggestion first.

Best,

		Ph.

Re: Some way to differentiate (1st order derivative)?

[<HBB...@t-...>]

Levente Novák wrote:
> AFAIK calculating or approximating the 1st order derivative of a
> function or x-y dataset was not (easily?) possible a few years ago from
> within gnuplot, but maybe this has changed since then 

It hasn't.  Numeric differentiation (and integration, and lots of other 
sides) is on the wrong side of the boundary between plotting and data 
processing.

> But afterwards, I need the 1st order
> derivative of the fitted or smoothed curve.

For the fitted curve, that should be reasonably easy.  Derive it 
algebraically (you know --- that thing you do with pencil, paper and 
scratching your skull), then have gnuplot plug in the fitted parameters 
and plot it.

> If not, is it still possible to perform differentiation from within
> gnuplot (even if this means using some awk script or similar), as I
> would like to automate the process and gnuplot is easily driven from
> a shell script or batch file.

Nothing changed in that area, either.

	plot "< myscript datafile"

works just as well as it always did.

Some way to differentiate (1st order derivative)?

[Levente <ln...@dr...>]

AFAIK calculating or approximating the 1st order derivative of a
function or x-y dataset was not (easily?) possible a few years ago from
within gnuplot, but maybe this has changed since then -- I don't follow
closely gnuplot's development anymore.

My problem is the following: from a dataset, I first plot the x-y
values, then either fit a function to them or make a smoothing with
acsplines. So far, no problem. But afterwards, I need the 1st order
derivative of the fitted or smoothed curve. This would be easy if
gnuplot had a way to access data not only from the _actual_ row but also
from the following one in order to calculate Delta y / Delta x = y(row
+1)-y(row)/(x(row+1)-x(row)). This was not possible earlier. Has the
situation changed since then? If not, is it still possible to perform
differentiation from within gnuplot (even if this means using some awk
script or similar), as I would like to automate the process and gnuplot
is easily driven from a shell script or batch file.


Levente

Re: Can we add an error state variable?

[Petr M. <mi...@ph...>]

> > I don't like the name "ERRORNO" very much -- the naming is contrary to what 
> > one would expect -- according to the docs it should be called 
> > GPVAL_ERRORYES.
> 
> Heh.  The problems of abbreviation :-)
> 
> That was supposed to be short for "error number".
> The standard name in C or Unix is "errno".  But gnuplot's variable
> would not take on the same values as C's ERRNO, so I thought a
> slightly different name was appropriate.
>
>> I would vote for just a simple name GPVAL_ERROR.

Aha, GPVAL_ERRNO would be fine, C programmers know this name well. Just not 
GPVAL_ERRORNO.

---
PM

Re: Can we add an error state variable?

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

On Monday 15 October 2007 13:05, Petr Mikulik wrote:
> I don't like the name "ERRORNO" very much -- the naming is contrary to what 
> one would expect -- according to the docs it should be called 
> GPVAL_ERRORYES.

Heh.  The problems of abbreviation :-)

That was supposed to be short for "error number".
The standard name in C or Unix is "errno".  But gnuplot's variable
would not take on the same values as C's ERRNO, so I thought a
slightly different name was appropriate.

Yes, in this patch it acts like a Boolean:   zero/non-zero
But my thought was that in the future we might expand it to have
different levels of severity, or possibly user-set errors.
E.g. things like

 0 - success
-1 - internal error
-2 - eof or other read error
-3 - syntax error
>0 - set [somehow] by user-specified condition

> I would vote for just a simple name GPVAL_ERROR. 
> (Names like GPVAL_ERRORWAS don't look so nice.)

That's OK by me.


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

Re: Can we add an error state variable?

[Petr M. <mi...@ph...>]

> I am wondering if we can and should implement something of the sort
> automatically.  It's easy to have int_error() set an error flag.

I've tested the patch. I see in the docs:

The read-only variable GPVAL_ERRORNO is set to a non-zero value if any 
gnuplot command terminates early due to an error.  The most recent error 
message is stored in the string variable GPVAL_ERRORMSG.  Both GPVAL_ERRORNO 
and GPVAL_ERRORMSG can be cleared using the command `reset errors`.

I don't like the name "ERRORNO" very much -- the naming is contrary to what 
one would expect -- according to the docs it should be called 
GPVAL_ERRORYES. I would vote for just a simple name GPVAL_ERROR.
(Names like GPVAL_ERRORWAS don't look so nice.)

With this change, I propose the patch can go to cvs.

---
PM

Can we add an error state variable?

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

The following query, and my response to it, appeared on the newsgroup:

>>I am already using with success gnuplot and batch mode operation. The
>>problem I am facing is how to understand if a plot was not performed
>>correctly, when run as a batch job.
>>
>>I.e. when I issue this command "plot sin(x" I get a "')' expected"
>>error, or when I give "plot ssin(x)" I get error "undefined function:
>>ssin".
>>
>>Is there a safe way to grab all these errors? Something like a "return
>>value" ?

>No return value, sorry.
>The closest I can think of is illustrated below
>ierr = 1
>plot sin(x     ; ierr=0
>print (ierr == 1) ? "failed" : "success"

I am wondering if we can and should implement something of the sort
automatically.  It's easy to have int_error() set an error flag.
The question is whether there is a single place, or a small number of
places, where such a flag can be guaranteed to be reset before the
next command is executed, yet leaves it available for testing?

Alternatively we could allow the user to define an asynchronous
error-handling function, and call it from int_error() if it exists.
E.g.:

#define error handler routine (must have this name)
user_error_handler(x) = (saw_error = x)

saw_error = 0
[some series of commands]
print (saw_error != 0) ? "some error happened" : "OK"






Any ideas?

-- 
Ethan A Merritt

Re: an important non-FAQ

[<HBB...@t-...>]

Tugrul Hakioglu wrote:
>  I have no answer to the following question of mine. It would desparately 
>  need somebody to provide an answer. problem is basically how to convert a
>  multiplot into an eps or pdf output file. 

You already got an answer elsewhere.  It is that you're asking the 
question the wrong way.  You don't "convert" a plot to another output 
format.  You change the output format, then re-do the entire plot.

>   I use 
> 
>         gnuplot Version 4.0 patchlevel 0
>         last modified Thu Apr 15 14:44:22 CEST 2004
>         System: Linux 2.6.11-6mdksmp

Them maybe you should start by upgrading to 4.2 patchlevel 2.

>   it seems 
>   that standart recipe is not working or, and more probably, I am doing
>   something wrong or missing. 

How is anybody supposed to be able to help with this if you don't tell 
what that "standard recipe" actually is?

Re: [PATCH] Disable PDF docinfo output for EPS

[<lud...@la...>]

Hi,

Ethan Merritt <merritt@u.washington.edu> writes:

> On Tuesday 09 October 2007 01:25, Ludovic Courtès wrote:
>> The problem is not with PDF, but rather with the interpretation of the
>> `pdfmark' operator by "distiller" applications such as ps2pdf
>
> I agree. Therefore I consider it a bug in ps2pdf.

As I said, the "pdfmark Reference" says nothing about such situations,
and ps2pdf is in agreement with Acrobat Distiller (the reference
implementation).

Thus, I'd say it's an *omission* in the specs, not a bug in the
implementations.

> I beg to differ. An equally common path is to convert the individual
> figures from *.eps to *.pdf and then assemble the document using
> pdflatex.  The metadata in the individual *.eps pdfmark sections are
> then attached to the individual figures, and can be used to navigate
> the resulting composite pdf document.  At least, that's the intent.
> If it's broken, let's fix it.

Right (I do not use `pdflatex' myself, thus I did not feel this need).

At any rate, users of PostScript document producers (LaTeX+dvips, Lout,
etc.)  are currently annoyed by a feature that is beneficial only in
fairly specific scenarios.  :-)

> If there is a better mechanism to do so, great.  But I'd rather fix the
> problem by improving the support rather than by removing it altogether.
> The pdfmark Reference you point to below gives a lot of suggestions how
> to create more sophisticated tags; perhaps someone will be inspired to
> modify post.trm to emit more sophisticated pdfmark sections.

There's only one way to create an info dictionary AFAIK.

Besides, "fixing the problem" would mean "augmenting the pdfmark
Reference", which is obviously not possible.

> Finally, I note that the pdfmarkReference also provides a sample code
> chunk to disable pdfmark interpretation by PostScript interpreters.
> Now that gnuplot allows local customization of the PostScript prologue
> files, perhaps the most straightforward immediate solution is for you 
> to add the code fragment to your local prologue file?

Hmm, I'll look into it, but that looks rather inconvenient.  A
terminal-specific "nopdfmark" option (or similar) would be nicer.

Thanks,
Ludovic.

an important non-FAQ

[Tugrul H. <hak...@fe...>]

 Dear FAQ organizer,
 I have no answer to the following question of mine. It would desparately 
 need somebody to provide an answer. problem is basically how to convert a
 multiplot into an eps or pdf output file. 

 regards
 T. Hakioglu








  Hi, 

  I use 

        gnuplot Version 4.0 patchlevel 0
        last modified Thu Apr 15 14:44:22 CEST 2004
        System: Linux 2.6.11-6mdksmp


  to generate colored and grayscale multiplots using pm3d map and splot.
  as the output, I would like to convert these multiplots to pdf. it seems 
  that standart recipe is not working or, and more probably, I am doing
  something wrong or missing. what I get at the end is the pdf version
  of the specific plot in the multiplot which comes last on the screen.
  can anybody tell me how to convert a colored multiplot into a pdf? 


  regards

  Tugrul Hakioglu
  Physics Department
  Bilkent University, 
  Ankara, Turkey
  hak...@fe...

Re: [PATCH] Disable PDF docinfo output for EPS

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

On Tuesday 09 October 2007 01:25, Ludovic Court=E8s wrote:
> The problem is not with PDF, but rather with the interpretation of the
> `pdfmark' operator by "distiller" applications such as ps2pdf

I agree. Therefore I consider it a bug in ps2pdf.

> It turns out that both LaTeX+hyperref and Lout (which is what I use) put
> their Info dictionary marker at the beginning of the PS document; thus,
> that Info dictionary gets overridden by the one present in the
> included GNUplot-generated EPS files.  QED.

Yes, that was the original failure mode reported in an earlier bug report.

> Furthermore, I question the usefulness of `pdfmark' in EPS files.  EPS
> files are meant to be embedded, as the name implies, and probably not
> converted to PDF.  Thus, `pdfmark' instances within EPS appear to be of
> little use; `pdfmark' in *PS* files, OTOH, are admittedly useful, and my
> patch preserves them.

I beg to differ. An equally common path is to convert the individual
figures from *.eps to *.pdf and then assemble the document using
pdflatex.  The metadata in the individual *.eps pdfmark sections are
then attached to the individual figures, and can be used to navigate
the resulting composite pdf document.  At least, that's the intent.
If it's broken, let's fix it.

You may ask "in that case, why use gnuplot to create eps figures rather
than pdf figures"?  Until recently, creating pdf figures directly required
building gnuplot from source and linking against the proprietary PDFlib
library. So this path was not generally available.  In the CVS version of
gnuplot there is now an experimental cairo-based pdf terminal that may
obviate this problem. But until that matures and perhaps a corresponding
"pdflatex" terminal is written, I think it is disirable to continue to
support the inclusion of pdf metadata in *.eps output.  =20

If there is a better mechanism to do so, great.  But I'd rather fix the
problem by improving the support rather than by removing it altogether.
The pdfmark Reference you point to below gives a lot of suggestions how
to create more sophisticated tags; perhaps someone will be inspired to
modify post.trm to emit more sophisticated pdfmark sections.

=46inally, I note that the pdfmarkReference also provides a sample code
chunk to disable pdfmark interpretation by PostScript interpreters.
Now that gnuplot allows local customization of the PostScript prologue
files, perhaps the most straightforward immediate solution is for you=20
to add the code fragment to your local prologue file?  That has the
nice feature that it applies to all existing installations of 4.2;
it doesn't require rebuilding gnuplot.=20

> http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creatio=
n_apis_and_specs/pdfmarkReference.pdf

=2D-=20
Ethan A Merritt

Re: bug in fillstyle in emf.trm

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

On Tuesday 09 October 2007 04:50, Dr. Johannes Zellner wrote:
> Hello,
> 
> The line term/emf.trm. around line 836
> 
>     emf_color = color;
> 
> is wrong and should be removed in my opinion. This line saves a 'line
> color' which was enventually modified by a fill density some lines
> above in the same function.
> 
> Agreed?

I think you are correct.

-- 
Ethan A Merritt

bug in fillstyle in emf.trm

[Dr. J. Z. <joh...@ze...>]

Hello,

The line term/emf.trm. around line 836

    emf_color = color;

is wrong and should be removed in my opinion. This line saves a 'line
color' which was enventually modified by a fill density some lines
above in the same function.

Agreed?

-- 
Dr. Johannes Zellner <joh...@ze...>

Re: [PATCH] Disable PDF docinfo output for EPS

[<lud...@la...>]

Hi,

Ethan Merritt <merritt@u.washington.edu> writes:

> On Friday 05 October 2007 02:36, Ludovic Courtès wrote:
>> Hi,
>> 
>> Just in case you missed it, I recently posted a tiny patch to disable
>> PDF docinfo output for EPS:
>> 
>>   http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316
>
> I consider the current gnuplot behaviour to be correct.
> The pdfmark constuct allows passing metadata through to PDF, and
> Adobe's PDF Reference, Third Edition states (Section 9):

The problem is not with PDF, but rather with the interpretation of the
`pdfmark' operator by "distiller" applications such as ps2pdf: the
"pdfmark Reference Manual" [0] does not specify how multiple instances
of an "Info dictionary pdfmark" should be handled.

Consider the following PostScript file:

  %!PS-Adobe-3.0
  %%DocumentMedia: A4 595 842 0 white ()
  %%PageOrder: Ascend
  %%LanguageLevel: 2
  %%BoundingBox: 0 0 595 842

  [ /Title (First Title)
     /Author (First Author)
     /Subject (First Subject)
     /DOCINFO
  pdfmark

  [ /Title (Second Title)
     /Author (Second Author)
     /Subject (Second Subject)
     /DOCINFO
  pdfmark

With GhostScript's ps2pdf and `pdfinfo' from Xpdf, I get this:

  $ ps2pdf ,,t.ps
  $ pdfinfo ,,t.pdf
  Title:          Second Title
  Subject:        Second Subject
  Author:         Second Author
  Producer:       GPL Ghostscript 8.56
  CreationDate:   Tue Oct  9 07:54:12 2007
  ModDate:        Tue Oct  9 07:54:12 2007
  Tagged:         no
  Pages:          1
  Encrypted:      no
  Page size:      595 x 842 pts (A4)
  File size:      2275 bytes
  Optimized:      no
  PDF version:    1.4

Which means that the second Info dictionary overrode the first.  Same
result with Acrobat Distiller:

  $ pdfinfo ,,t.acrobat-distiller-7.pdf 
  Title:          Second Title
  Subject:        Second Subject
  Author:         Second Author
  Producer:       Acrobat Distiller 7.0.5 pour Macintosh
  CreationDate:   Tue Oct  9 09:56:34 2007
  ModDate:        Tue Oct  9 09:56:34 2007
  Tagged:         no
  Pages:          1
  Encrypted:      no
  Page size:      612 x 792 pts (letter)
  File size:      5057 bytes
  Optimized:      yes
  PDF version:    1.4

Indeed, both PDF files only contain the second Info dictionary.

Including a GNUplot-generated EPS file in a PS file that already
contains its own Info dictionary marker is likely to lead to the same
situation, unless the PS file is arranged such that its Info dictionary
marker appears  after  the embedded EPS file.

It turns out that both LaTeX+hyperref and Lout (which is what I use) put
their Info dictionary marker at the beginning of the PS document; thus,
that Info dictionary gets overridden by the one present in the
included GNUplot-generated EPS files.  QED.


Furthermore, I question the usefulness of `pdfmark' in EPS files.  EPS
files are meant to be embedded, as the name implies, and probably not
converted to PDF.  Thus, `pdfmark' instances within EPS appear to be of
little use; `pdfmark' in *PS* files, OTOH, are admittedly useful, and my
patch preserves them.

Thanks,
Ludovic.

[0] http://partners.adobe.com/public/developer/en/acrobat/sdk/pdf/pdf_creation_apis_and_specs/pdfmarkReference.pdf

Re: [PATCH] Disable PDF docinfo output for EPS

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

On Friday 05 October 2007 02:36, Ludovic Court=C3=A8s wrote:
> Hi,
>=20
> Just in case you missed it, I recently posted a tiny patch to disable
> PDF docinfo output for EPS:
>=20
>   http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316

I consider the current gnuplot behaviour to be correct.
The pdfmark constuct allows passing metadata through to PDF, and
Adobe's PDF Reference, Third Edition states (Section 9):

   Beginning with PDF 1.4, metadata can also be speci=EF=AC=81ed
   for individual components of a document.

where "individual components" explicitly means such things as
embedded figures, exactly the normal use case for *.eps files.

This issue was raised previously with respect to use of
gnuplot *.eps files in TeX documents:
http://groups.google.com/group/comp.graphics.apps.gnuplot/browse_thread/thr=
ead/5938f08fe95b0bdd/469c49b8f2bc57a8

=46rom my perspective, the ability to attach metadata to individual
plots is useful, and is handled correctly by several toolchains.
=46or example, it allows you to search for gnuplot-generated figures
inside a large PDF document.=20

ps2pdf was reported in that thread to mis-handle the metadata
association.  I do not know whether or not a bug report was
subsequently filed against ps2pdf.

On the other hand, the PDF Reference manual also allows an
alternate mechanism for attaching metadata in documnet subcomponents.
If someone wants to explore that and submit a gnuplot patch to use
the alternate mechanism, I would be happy to look at it.=20



=2D-=20
Ethan A Merritt

[PATCH] Disable PDF docinfo output for EPS

[<lud...@la...>]

Hi,

Just in case you missed it, I recently posted a tiny patch to disable
PDF docinfo output for EPS:

  http://article.gmane.org/gmane.comp.graphics.gnuplot.bugs/1316

Thanks,
Ludovic.

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

On Wednesday 03 October 2007 16:28, Tatsuro MATSUOKA wrote:
> --- Ethan A Merritt <merritt@u.washington.edu> wrote:
> I've now fixed this in CVS.
> 
> ***
> Thanks! I have confirmed the fix.
> 
> 
> If the new Syntax is recommended, is the following right ?
> 
>        set terminal cgm {<mode>} {<color>} {<rotation>} {solid | dashed}
>                         {width <plot_width>} {linewidth <line_width>}
>                         {"<font>, <fontsize>"}            


Not exactly.  There should be a keyword "font" in front of the string:

        set terminal cgm {<mode>} {<color>} {<rotation>} {solid | dashed}
                         {width <plot_width>} {linewidth <line_width>}
                         {font "<font>, <fontsize>"}            


-- 
Ethan A Merritt

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

--- Ethan A Merritt <merritt@u.washington.edu> wrote:
I've now fixed this in CVS.

***
Thanks! I have confirmed the fix.

On the other hands,
gnuplot> help set term cgm
 Syntax:
       set terminal cgm {<mode>} {<color>} {<rotation>} {solid | dashed}
                        {width <plot_width>} {linewidth <line_width>}
                        {"<font>"} {<fontsize>}

If the new Syntax is recommended, is the following right ?

       set terminal cgm {<mode>} {<color>} {<rotation>} {solid | dashed}
                        {width <plot_width>} {linewidth <line_width>}
                        {"<font>, <fontsize>"}            

Regards

Tatsuro
       

--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

--- Ethan A Merritt <merritt@u.washington.edu> wrote:

> Both the new and the old syntax work here.
> Tested in 4.2 and in CVS.

Thanks for your reply.
I apologized that I forgot to aet my name for the Mailer.
My name is Tatsuro MATSUOKA.


I found it in the CVS version prepared on the cygwin.
I tried new syntax on CVS.
It worked well.
The CVS gnuplot source was download at yesterday and build it under the cygwin.
I also tested by the cvs wgnuplot which was distributed by Prof. Kakuto.

http://www.ring.gr.jp/pub/text/TeX/ptex-win32/utils/gnuplot-43pl0w32.zip 

The result was the same.
New syntax worked well but old syntax did not work.
CGM file is translated by the Microsoft office 2003 cgm file filter.

For the ver. 4.2.2 of wgnuplot and gnuplot cygwin, the new and old syntaxes worked well.

Anyway new syntax works for both 4.2.2 and cvs, I will use the new syntax.

OH TH,
When the syntax was changed ?

        G N U P L O T
        Version 4.3 patchlevel 0
        last modified June 2007
        System: CYGWIN_NT-5.1 1.5.24(0.156/4/2)

gnuplot> help set term cgm
Syntax:
       set terminal cgm {<mode>} {<color>} {<rotation>} {solid | dashed}
                        {width <plot_width>} {linewidth <line_width>}
                        {"<font>"} {<fontsize>}
                        {<color0> <color1> <color2> ...}

Help seems to remain in old syntax style.....

Regards,

***************************************************************
Dr. Tatsuro MATSUOKA
Associate Professor

Department of Molecular Design and Engineering
Graduate School of Engineering
Nagoya University
Furo-cho, Chikusa-ku, Nagoya, 464-8603, Japan
E-mail mat...@nu...
       tma...@ya...(gnuplot ML specific)
Tel.   +81(Japan)-52-789-3274
FAX    +81(Japan)-52-789-3273
****************************************************************


--------------------------------------
Easy + Joy + Powerful = Yahoo! Bookmarks x Toolbar
http://pr.mail.yahoo.co.jp/toolbar/

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

On Wednesday 03 October 2007 10:44, Hans-Bernhard Br=F6ker wrote:
> CVS current as of today:
>=20
> gnuplot> set term cgm
> Terminal type set to 'cgm'
> Options are 'landscape color rotate dashed  width 432 linewidth 1=20
> "Helvetica Bold" 12'
> gnuplot> set term cgm font "times" 18
> Terminal type set to 'cgm'
> Options are 'landscape color rotate dashed  width 432 linewidth 1=20
> "times" 12'
> gnuplot>
>=20
> Note how the '18' fails to be picked up.

Works here in 4.2.2, so this must be a CVS-only problem.
I'll look at it...

Hmmph.
The problem is not new/old syntax per se.
There was an incomplete switch from quote_str() to try_to_get_string(),
leaving an extra c_token++ at the end of the font name parsing clause.

E.g.

 set term cgm font "Times" 19          fails
 set term cgm font "Times" junk 19     succeeds

I've now fixed this in CVS.

=2D-=20
Ethan A Merritt

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

[<HBB...@t-...>]

Ethan A Merritt wrote:
> On Wednesday 03 October 2007 04:01, Hans-Bernhard Bröker wrote:
>> tma...@ya... wrote:

> Both the new and the old syntax work here.
> Tested in 4.2 and in CVS.
> 
> In what version have you seen a failure?

CVS current as of today:

gnuplot> set term cgm
Terminal type set to 'cgm'
Options are 'landscape color rotate dashed  width 432 linewidth 1 
"Helvetica Bold" 12'
gnuplot> set term cgm font "times" 18
Terminal type set to 'cgm'
Options are 'landscape color rotate dashed  width 432 linewidth 1 
"times" 12'
gnuplot>

Note how the '18' fails to be picked up.

Re: [Gnuplot-bugs] cgm terminal font size for gnuplot 4.3

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

On Wednesday 03 October 2007 04:01, Hans-Bernhard Br=F6ker wrote:
> tma...@ya... wrote:
>=20
> > I changed 'set term cgm mono font 'times' 16'.
>=20
> Looks like the change to the new syntax for font/size specification=20
> meant to be common to all terminals:
>=20
> 	set term cgm mono font 'times,16'
>=20
> has broken parsing of the old-style
>=20
> 	"<font>" <size>
>=20
> syntax in the CGM driver.  I suspect the 'break;' statement in the=20
> default case.

Both the new and the old syntax work here.
Tested in 4.2 and in CVS.

In what version have you seen a failure?


=2D-=20
Ethan A Merritt