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

Re: [ gnuplot-Patches-992149 ] String variables revisited

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

On Sunday 18 July 2004 07:03 am, Hans-Bernhard Broeker wrote:
> > 3) user-defined string-valued functions.
>
> Users will almost certainly want to be able to do something like this:
>
> 	filename(i)=sprintf("foobar%d.ps", i)
>
> 	i=15
>
> 	# in a loaded file:
> 	set output filename(i)
> 	plot something
> 	i=i+1
> 	reread

But that example does not require a user-defined function.
That is the behaviour you would get anyway, courtesy of
the automagic string evaluation code already written.

filename = 'sprintf("foobar%d.ps",i)'
set output filename
i = 15
replot
i = 16
replot

What it does require (and your user-defined function would
also require) is that term.c:term_set_output() and a few other 
places in the actual drivers be modified similarly to what I did for
write_multiline(). They would need to check that the string is
not really a constant, but instead holds a sprintf() command. 

'set output <bar>' is messy because <foo> is used for something
other than being printed. Most of the other 'set <foo> "string const"'
require no special modification, since the fancy stuff happens inside
the eventual print routine. 


-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Hans-Bernhard B. <br...@ph...>]

On Sat, 17 Jul 2004, Ethan A Merritt wrote:

> Anyhow, adding additional string-valued functions would be very easy.
> Let's discuss which ones might be desirable.
> 
> 1) gprintf("format",mantissa,exponent)
>     Is that the form it should take?

No.  It should be gprintf("format", number).  The crucial difference
is that C's sprintf() supports multiple % formats and uses up exactly
one argument per format specifier, whereas gprintf() only ever has one
argument, but may use more than one format specifier with it.  The
syntax of my stop-gap extension to 'set lable' looks the way it does for
a reason:

	set label 'a = %l * 10^{%L}', a, ', length = %s %cm', length \
	    at 2,3

> 2) Some way to do arithmetic using numerical values stored in 
>     a string.   E.g.
>     a = "1.2"
>     b = 3.4
>     c = a+b
>     It would be straightforward, although tedious, to modify every
>     existing atomic evaluation routine in internal.c so that it 
>     recognizes string-values during arithmetic.  They would be
>     converted to (double) using atof(). But is this at all necessary?

I don't think so.  I think we should follow a Java-like approach:
adding a number to a string converts the number to a string and 
concatenates.  The only way to get a number back from a string
would be by explicit function call.  

> 3) user-defined string-valued functions.
>     I don't see at the moment how to implement these, although
>     I think it would be possible.  Are they needed?

I think they are.  Users will almost certainly want to be able to
do something like this:

	filename(i)=sprintf("foobar%d.ps", i)
	
	i=15

	# in a loaded file:
	set output filename(i)
	plot something
	i=i+1
	reread	

> 4) Do we want any string operations besides concatenation?
>     Substrings?  String comparison?  

Yes, yes, and possibly, in that order.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [ gnuplot-Patches-992149 ] String variables revisited

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

On Saturday 17 July 2004 10:00 am, Hans-Bernhard Broeker wrote:
>
> The problem is that %l/%L and similar formats must always be used in
> pairs, and the code needs to know which the pairs are: the rounding on the
> %l part affects what the right result on %L is.  The number 9.999 can come
> out as 9.999*10^0 or 10.0*10^^1.
>
> The two of them could be called gprintf and sprintf or similar.

I have posted a 2nd patch, stringvars-2, to SourceForge.
stringvars-1 and stringvars-2 are to be applied sequentially.

This one adds run-time evaluation of all quoted strings beginning
"sprintf... that are printed via write_multiline().   It turned out to be
amazingly easy. I am very impressed with the existing implementation
of expression evaluation; slotting in evaluation of string-valued functions
"just worked".

Here's a neat example that demonstrates plot-time evaluation:

	set title 'sprintf("Plotted at %s",`date`)'
	plot <something>
	pause 3  "Should show new time"
	replot
	pause 3  "Should show new time"
	replot

NB: The specific placement of single and double quotes is critical
for this to work.  See my recent bug report about gnuplot losing the
single-quoted-ness of strings after their initial evaluation.  This
example currently works by accident, but I think we should
re-examine how quoted strings are stored in general.

	
Anyhow, adding additional string-valued functions would be very easy.
Let's discuss which ones might be desirable.

1) gprintf("format",mantissa,exponent)
    Is that the form it should take?

2) Some way to do arithmetic using numerical values stored in 
    a string.   E.g.
    a = "1.2"
    b = 3.4
    c = a+b
    It would be straightforward, although tedious, to modify every
    existing atomic evaluation routine in internal.c so that it 
    recognizes string-values during arithmetic.  They would be
    converted to (double) using atof(). But is this at all necessary?
    Maybe it is sufficient to simply provide a built-in atof()
    function.   Or maybe we don't even need that.

3) user-defined string-valued functions.
    I don't see at the moment how to implement these, although
    I think it would be possible.  Are they needed?

4) Do we want any string operations besides concatenation?
    Substrings?  String comparison?  

-- 
Ethan A Merritt
Department of Biochemistry & Biomolecular Structure Center
University of Washington, Seattle

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Hans-Bernhard B. <br...@ph...>]

On Sat, 17 Jul 2004, Harald Harders wrote:

> provide the format specifiers the gnuplot users are used to than to
> provide C specifiers. If you are able to write "%l \267 10^{%L}" in tic
> formats, you also should be able to do this in string variable
> definitions.

I fully agree there.  Which means we'll need two functions, eventually.
The problem is that %l/%L and similar formats must always be used in
pairs, and the code needs to know which the pairs are: the rounding on the
%l part affects what the right result on %L is.  The number 9.999 can come
out as 9.999*10^0 or 10.0*10^^1.

The two of them could be called gprintf and sprintf or similar.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [ gnuplot-Patches-982765 ] Patch for AI (Adobe Illustrator) term

[Harald H. <h.h...@tu...>]

On Fri, 16 Jul 2004, Ethan Merritt wrote:

> > or using it for definition of a new function
> >
> >   /NewPatternFill {
> >   ...
> >   } def
> >
> > the file can be loaded. May be the pattern fill code can test if
> > NewPatternFill has already been used (by setting a boolean) and then call
> > it once if needed.
>
> That is a very interesting idea, but I am not sure that we have
> a mechanism in place to allow it.

I have applied some changes to a sample file.

Here is the gnuplot file:
# ------ pattern-test.gpl ------------------------------------
set terminal postscript eps 'Times-Roman' 22
set output 'pattern-test.eps'
set style fill pattern 1 border 1
plot x*x notitle with filledcurves y1=5
set output
# ------ /pattern-test.gpl ------------------------------------

And here is the diff:

# ------ pattern-test.diff ------------------------------------
--- pattern-test.original.eps   Sat Jul 17 15:52:20 2004
+++ pattern-test2.eps   Sat Jul 17 16:16:49 2004
@@ -287,6 +287,12 @@
 /Tile8x8 {/PaintType 2 /PatternType 1 /TilingType 1 /BBox [0 0 8 8]
/XStep 8 /Y
Step 8}
           bind def
 /KeepColor {currentrgbcolor [/Pattern /DeviceRGB] setcolorspace} bind
def
+/PatternsUndefined true def
+/DefinePatterns {
+  PatternsUndefined
+  {
+    gsave
+    20 20 scale % reciprocal of 0.050 0.050: should be solved
differently
 << Tile8x8
  /PaintProc { 0.5 setlinewidth  pop 0 0 M 8 8 L 0 8 M 8 0 L stroke }
 >> matrix makepattern
@@ -331,13 +337,17 @@
               -4 0 M 12 8 L -4 4 M 8 10 L stroke }
 >> matrix makepattern
 /Pat9 exch def
-/Pattern1 {KeepColor Pat1 setpattern} bind def
-/Pattern2 {KeepColor Pat2 setpattern} bind def
-/Pattern3 {KeepColor Pat3 setpattern} bind def
-/Pattern4 {KeepColor Landscape { Pat5 } { Pat4 } ifelse setpattern} bind
def
-/Pattern5 {KeepColor Landscape { Pat4 } { Pat5 } ifelse setpattern} bind
def
-/Pattern6 {KeepColor Landscape { Pat9 } { Pat6 } ifelse setpattern} bind
def
-/Pattern7 {KeepColor Landscape { Pat8 } { Pat7 } ifelse setpattern} bind
def
+    grestore
+    /PatternsUndefined false def
+  } if
+} def
+/Pattern1 {DefinePatterns KeepColor Pat1 setpattern} def
+/Pattern2 {DefinePatterns KeepColor Pat2 setpattern} def
+/Pattern3 {DefinePatterns KeepColor Pat3 setpattern} def
+/Pattern4 {DefinePatterns KeepColor Landscape { Pat5 } { Pat4 } ifelse
setpatte
rn} def
+/Pattern5 {DefinePatterns KeepColor Landscape { Pat4 } { Pat5 } ifelse
setpatte
rn} def
+/Pattern6 {DefinePatterns KeepColor Landscape { Pat9 } { Pat6 } ifelse
setpatte
rn} def
+/Pattern7 {DefinePatterns KeepColor Landscape { Pat8 } { Pat7 } ifelse
setpatte
rn} def
 %
 %End of PostScript Level 2 code
 %
# ------ /pattern-test.diff ------------------------------------

> I suppose this would need to
> go into the term->graphics() routine, which is called to start a new
> plot. Is there some way for a  'plot' command to pass any information
> about requirements to a terminal driver at this point?

With this patch, only the Postscript header is changed. But there is one
problem: The original code defines the patterns before setting
"0.050 0.050 scale" while the new code does it afterwards. Thus, I have
included "gsave 20 20 scale" ... "grestore" to get the original scaling.
Thus should be solved differently because somebody may want to change the
0.050 0.050 (as I do sometimes).

> You may have meant that the test for initialization could be
> made in the PostScript code itself, at the point where a call to
> one of the Pattern<n> operators would first occur.
> But so far my experimentation shows this does not work.
> It does work to initialize at the start of a new %Page in
> the document, however.

See above: The problem was the global scaling of the document.

> > Then, eps files that do not use patterns can be loaded
> > while the ones the use them fail to be loaded by Illustrator 7. The
> > Computer that runs Illustrator 11 is off, already. But Illustrator 11 has
> > been able to load all eps files until now.

Illustrator CS 11 can load the original and the new code including the
patterns but it unfortunately shows the borders of the tiles (shall I send
a screen shot?).

Illustrator 7 now understands the patched files when not using one of the
commands Pattern1, Pattern2, etc.

Ghostscript 8.14 and 6.53 do understand the files including patterns.

Unfortunately gv 3.5.8 ignores the patterns and shows an empty plot. But
this may be a bug. It is a pity that gv is not developed anymore.

-- 
Harald Harders                           Langer Kamp 8
Technische Universitaet Braunschweig     D-38106 Braunschweig
Institut fuer Werkstoffe                 Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Harald H. <h.h...@tu...>]

On Sat, 17 Jul 2004, Hans-Bernhard Broeker wrote:

> On Fri, 16 Jul 2004, Harald Harders wrote:
>
> > I would prefer one function that does everything.
>
> I don't think that's an option.  Too many of gnuplot's special
> formatting specifier already collide with C printf formats for that to
> work:  %s, %c, %p, %l.

Mmh, you are right here. Nevertheless I think it is more important to
provide the format specifiers the gnuplot users are used to than to
provide C specifiers. If you are able to write "%l \267 10^{%L}" in tic
formats, you also should be able to do this in string variable
definitions.

Yours
Harald

--
Harald Harders                           Langer Kamp 8
Technische Universitaet Braunschweig     D-38106 Braunschweig
Institut fuer Werkstoffe                 Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Hans-Bernhard B. <br...@ph...>]

On Fri, 16 Jul 2004, Harald Harders wrote:

> I would prefer one function that does everything. 

I don't think that's an option.  Too many of gnuplot's special
formatting specifier already collide with C printf formats for that to
work:  %s, %c, %p, %l.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: [ gnuplot-Patches-982765 ] Patch for AI (Adobe Illustrator) term

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

> or using it for definition of a new function
> 
>   /NewPatternFill {
>   ...
>   } def
> 
> the file can be loaded. May be the pattern fill code can test if
> NewPatternFill has already been used (by setting a boolean) and then call
> it once if needed.

That is a very interesting idea, but I am not sure that we have
a mechanism in place to allow it.   I suppose this would need to
go into the term->graphics() routine, which is called to start a new
plot. Is there some way for a  'plot' command to pass any information
about requirements to a terminal driver at this point?

Harald:

You may have meant that the test for initialization could be
made in the PostScript code itself, at the point where a call to
one of the Pattern<n> operators would first occur.
But so far my experimentation shows this does not work.
It does work to initialize at the start of a new %Page in 
the document, however.





> Then, eps files that do not use patterns can be loaded 
> while the ones the use them fail to be loaded by Illustrator 7. The
> Computer that runs Illustrator 11 is off, already. But Illustrator 11 has
> been able to load all eps files until now.

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

Re: [ gnuplot-Patches-982765 ] Patch for AI (Adobe Illustrator) term

[Harald H. <h.h...@tu...>]

On Fri, 16 Jul 2004, Ethan Merritt wrote:

> > From version 4.1 on, no file can be loaded by Illustrator
> > 7.0. The load process is terminated immediately. This means
> > the incompatibility between the gnuplot output and
> > Illustrator 7.0 seems to be at the top of the files. And it
> > seems to be because of a change between 4.0 and 4.1.
>
> The only change of significance is the inclusion of
> a set of PostScript Level 2 macros for pattern definitions.
> You seem to have more versions of Illustrator to test on than
> I do.  Could you try that experiment?  I.e. generate a *.eps
> plot in 4.1 that uses no pattern fill, confirm that Illustrator
> doesn't like it, then edit out those 60 lines of preamble and
> see if this makes Illustrator happy again?
>
> If omitting these 60 lines of preamble code is sufficient,
> then it should be easy enough to add a terminal option
> =09-noLevel2

I have used following code:

set terminal postscript eps 'Times-Roman' 24
set output 'illu7test-with-pattern.eps'
plot sin(x)
set output

With the pattern code, Illustrator 7 cannot load the file. When
surrouding the code by

  false {
  ...
  } if

or using it for definition of a new function

  /NewPatternFill {
  ...
  } def

the file can be loaded. May be the pattern fill code can test if
NewPatternFill has already been used (by setting a boolean) and then call
it once if needed. Then, eps files that do not use patterns can be loaded
while the ones the use them fail to be loaded by Illustrator 7. The
Computer that runs Illustrator 11 is off, already. But Illustrator 11 has
been able to load all eps files until now.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Patch #991819: relative coordinates

[Harald H. <h.h...@tu...>]

Could somebody please have a look at patch #991819 which fixes the
inconsistency of relative coordinates (arrow rto) when using logarithmic
axes. It also enables to mix screen coordinates with the other types in 3d
plots. If this patch will be accepted I can go on and programme offsets
for different types of texts.

Thank you
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-982765 ] Patch for AI (Adobe Illustrator) term

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

On Friday 16 July 2004, Harald Harders <h.h...@tu...> wrote:

> Until gnuplot version 4.0 (including), both Illustrator
> versions can read most gnuplot eps files.
> 
> From version 4.1 on, no file can be loaded by Illustrator
> 7.0. The load process is terminated immediately. This means
> the incompatibility between the gnuplot output and
> Illustrator 7.0 seems to be at the top of the files. And it
> seems to be because of a change between 4.0 and 4.1.

The only change of significance is the inclusion of
a set of PostScript Level 2 macros for pattern definitions.
These lines of code start with the comment:

%
% PostScript level 2 pattern fill definitions
% Ethan A Merritt April 2004
%

You seem to have more versions of Illustrator to test on than
I do.  Could you try that experiment?  I.e. generate a *.eps
plot in 4.1 that uses no pattern fill, confirm that Illustrator 
doesn't like it, then edit out those 60 lines of preamble and
see if this makes Illustrator happy again? 

If omitting these 60 lines of preamble code is sufficient, 
then it should be easy enough to add a terminal option
	-noLevel2

I'll have to dummy up some alternative code to be generated
instead so that attempts to use pattern-fill still produce legal
PostScript (probably substitute grey-scale intensity for pattern
fill in this case).


Related note:

It is in principle possible to write conditional code in the
PostScript file itself that tests for Level 2 support, but I have
not had much luck getting it to work right on old printers so
I am dubious about that being a workable solution to the
general case of missing Level 2 support..

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

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Harald H. <h.h...@tu...>]

On Fri, 16 Jul 2004, Petr Mikulik wrote:

> > > I will prefer sprintf(). That's compatible to all our famous programm=
ing
> > > languages and does not require user to search / think "what kind of c=
ommand
> > > has gnuplot for sprintf?".
> >
> > But then, we have to rename `print', too. Or, at least introduce a new
> > command `printf' which uses the same syntax as sprintf and prints to th=
e
> > shell (as `print' does with a different syntax).
>
> I don't see a problem. sprintf() is a function which creates a string, wh=
ile
> print is a command to print something on screen.

While you want to name sprintf according to C names, print does not refer
to it at all. I really do not see any command in gnuplot (expect the
format specifiers) that is named similar to C functions.

But I really think if a command (let it be named sprintf or string) exists
with the syntax described by Ethan that prints its result into a string a
command should exist that uses the same syntax and prints onto screen. For
example, the print command should understand sprintf syntax if its
argument starts with a (.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-992149 ] String variables revisited

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

> > I will prefer sprintf(). That's compatible to all our famous programming
> > languages and does not require user to search / think "what kind of command
> > has gnuplot for sprintf?".
>
> But then, we have to rename `print', too. Or, at least introduce a new
> command `printf' which uses the same syntax as sprintf and prints to the
> shell (as `print' does with a different syntax).

I don't see a problem. sprintf() is a function which creates a string, while
print is a command to print something on screen.

---
PM

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Harald H. <h.h...@tu...>]

On Fri, 16 Jul 2004, Petr Mikulik wrote:

> > > I was not clear enough.  This *is* the C language
> > > sprintf routine [*].  The gnuplot code just collects the
> > > variables and the format and passes them along to
> > > the C library. The documentation will refer users to
> > > "man sprintf" or to any C language manual.
> > >
> > > > set xlabel string(" %d %d %d", 1,2,3)
>
>
> I will prefer sprintf(). That's compatible to all our famous programming
> languages and does not require user to search / think "what kind of comma=
nd
> has gnuplot for sprintf?".

But then, we have to rename `print', too. Or, at least introduce a new
command `printf' which uses the same syntax as sprintf and prints to the
shell (as `print' does with a different syntax).

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-992149 ] String variables revisited

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

> > I was not clear enough.  This *is* the C language
> > sprintf routine [*].  The gnuplot code just collects the
> > variables and the format and passes them along to
> > the C library. The documentation will refer users to
> > "man sprintf" or to any C language manual.
> >
> > > set xlabel string(" %d %d %d", 1,2,3)


I will prefer sprintf(). That's compatible to all our famous programming
languages and does not require user to search / think "what kind of command
has gnuplot for sprintf?".

---
Petr Mikulik

Re: [ gnuplot-Patches-992149 ] String variables revisited

[Harald H. <h.h...@tu...>]

On Fri, 16 Jul 2004, Ethan Merritt wrote:

> > internal.c internal.h
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > 1) Define a new internal function f_sprintf().

[...]

> > I think this patch looks like a good thing, but I really
> > don't like the name `sprintf'. It really sounds like a c
> > programmer had no good idea how to call it.
>
> I was not clear enough.  This *is* the C language
> sprintf routine [*].  The gnuplot code just collects the
> variables and the format and passes them along to
> the C library. The documentation will refer users to
> "man sprintf" or to any C language manual.
>
> > set xlabel string(" %d %d %d", 1,2,3)
> >
> > The sprintf (or string) command should really understand all
> > gnuplot formats (%t, %T, %l, %L, etc.).
>
> For me, part of the rationale for this work is that the gnuplot
> formats are limiting.  If there is some particular format that
> you cannot produce using a C language printf() variant, then
> we can provide a separate routine for that.  Or there could
> be a second formatting function that specifically uses only
> the non-C gnuplot format conversion specifiers.
>
>     mystring =3D string("Format using %T %L etc", var1, var2)
>     set title sprint("C Format with embedded %s", mystring)

I would prefer one function that does everything. Maybe, it could parse
the string for gnuplot format specifiers (%t, %T, ...), first. All formats
that are not known by gnuplot can then be parsed to the C function
snprintf(). When deviding it into two function you really have to know too
much about internel things of the implementation. When using one function
the documentation may say something like

The `string` function understands all gnuplot format specifiers (see
format specifiers) and all C specifiers (see Kerninham/Ritchie).

Of course programming of a string command is much more work than passing
the arguments to snprintf(). But I think it is worth it.

Yours
Harald

--=20
Harald Harders                           Langer Kamp 8
Technische Universit=E4t Braunschweig      D-38106 Braunschweig
Institut f=FCr Werkstoffe                  Germany
E-Mail: h.h...@tu...               Tel: +49 (5 31) 3 91-3062
WWW   : http://www.ifw.tu-bs.de          Fax: +49 (5 31) 3 91-3058

Re: [ gnuplot-Patches-992149 ] String variables revisited

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

I'm moving this to the mailing list, because I hate the format
of Email sent via the SourceForge patch site.

On Friday 16 July 2004 02:22 am, Harald Harders wrote:
> Ethan Merritt wrote in the summary for patchset #992149
>
> internal.c internal.h
> =================
> 1) Define a new internal function f_sprintf(). This is
> visible to the user as a new built-in function
> sprintf("fmt",...), which is the first, and so far the
> only, function in gnuplot that accepts string variables
> as arguments.

> I think this patch looks like a good thing, but I really
> don't like the name `sprintf'. It really sounds like a c
> programmer had no good idea how to call it.

I was not clear enough.  This *is* the C language
sprintf routine [*].  The gnuplot code just collects the 
variables and the format and passes them along to
the C library. The documentation will refer users to
"man sprintf" or to any C language manual. 

> set xlabel string(" %d %d %d", 1,2,3)
> 
> The sprintf (or string) command should really understand all
> gnuplot formats (%t, %T, %l, %L, etc.).

For me, part of the rationale for this work is that the gnuplot
formats are limiting.  If there is some particular format that
you cannot produce using a C language printf() variant, then
we can provide a separate routine for that.  Or there could
be a second formatting function that specifically uses only
the non-C gnuplot format conversion specifiers.

    mystring = string("Format using %T %L etc", var1, var2)
    set title sprint("C Format with embedded %s", mystring)


[*] Actually, it's snprintf() because otherwise there is little
hope of preventing all buffer overflows.  As I recall, there is
an issue with some platforms not providing snprint().  My
inclination is to say that string variables are not supported
on such platforms.

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

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Hans-Bernhard B. <br...@ph...>]

On Thu, 15 Jul 2004, Ethan Merritt wrote:

> My conclusion from trying many combinations of PostScript maco
> options on pm3d.dem is that the following change is the minimal one
> sufficient to work around this ghostscript/gv bug:

> > /h {rlineto rlineto rlineto fill} bind def
> 
> Minimal revised version
> -----------------------------
> 
>     /h {rlineto rlineto rlineto gsave fill grestore} bind def

Hmmm.... let me try my understanding of PostScript on this.  What this
change does is to cause a copy of the patch constructed by the 'N' (-->
newpath moveto) and the three rlinetos alive to still be sitting on the
stack after the 'fill'.  And the 'g' operator of the *next* quadrangle
will then stroke this path.  

Yes, that figures.  IIRC, the PostScript drawing model explicitly says
that the fill operator *only* fills the interior of the path, leaving its
outline alone.  This will indeed cause hairline fractures between adjacent
rectangles: each fill will leave the shared edge itself alone, so it stays
white.  The change pastes over the cracks using the stroke operator.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Hans-Bernhard B. <br...@ph...>]

On Thu, 15 Jul 2004, Ethan Merritt wrote:

> The bug is in the gv viewer, or rather the ghostscript conversion
> to X11, not in the PostScript file.

I'm seriously doubtful it is all this simple.  For one thing, this
explanation completely fails to explain why the changes from 4.0.2 to 4.1
made the problem go away.

> If you convert to pdf and use a different viewer then you bypass
> the bug entirely.

Not necessarily.  It seems to depend on the way used to do the conversion.

And there's still not the first step towards an explanation of the Moir'e
pattern in the colorbox in sight.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

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

> > just an lucky side-effect of Ethan's changes to support pattern fills for
> > term->polygon().

Indeed it was a lucky side-effect.

> > Looking at the generated postscript, it seems as if the only significant
> > difference between 4.0.2 and 4.1 is the order of output points, and, of
> > course, the PostScript macro being used:

My conclusion from trying many combinations of PostScript maco
options on pm3d.dem is that the following change is the minimal one
sufficient to work around this ghostscript/gv bug:
> >
> > ---------4.0: ---------------
> > .3293 g 5148 927 N 0 -114 114 0 0 114 h
> > .3148 g 5033 927 N 0 -114 115 0 0 114 h
> > .2934 g 4918 927 N 0 -114 115 0 0 114 h
> >
> > /h {rlineto rlineto rlineto fill} bind def

Minimal revised version
-----------------------------

    /h {rlineto rlineto rlineto gsave fill grestore} bind def

Please check on your machines and on other test cases.
I was able to reproduce the problem with plot 7 of pm3d.dem,
but not the original problem reported on the newsgroup.

Are you OK with that as a fix for version 4.0, Petr?

As to version 4.1, I can try to trap filled quadrangles belonging to
the pm3d surface plots as a special case in the 4.1 code, 
and emit the same PostScript code that version 4.0 did.
This may send us into a period of bug-reporting when it
turns out the special-case code is either triggered or not
triggered correctly in all cases.

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

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:

>On Thursday 15 July 2004 11:08 am, Daniel J Sebald wrote:
>  
>
>>The example with the lines, i.e., "maps" could in some cases be done 
>>using the trm->image() routine to get rid of the white lines, and reduce 
>>the size of files.  Oddly, when doing ps2pdf on the postscript output, 
>>the white lines aren't visible in Acroread.  (In some cases 'though I 
>>see strange little blips at the corners of pm3d elements.)
>>    
>>
>
>What is so odd about that?
>The bug is in the gv viewer, or rather the ghostscript conversion
>to X11, not in the PostScript file.
>If you convert to pdf and use a different viewer then you bypass
>the bug entirely.
>

Yeah.  I'm not so sure this is a gnuplot problem.

Dan

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

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

On Thursday 15 July 2004 11:08 am, Daniel J Sebald wrote:
> The example with the lines, i.e., "maps" could in some cases be done 
> using the trm->image() routine to get rid of the white lines, and reduce 
> the size of files.  Oddly, when doing ps2pdf on the postscript output, 
> the white lines aren't visible in Acroread.  (In some cases 'though I 
> see strange little blips at the corners of pm3d elements.)

What is so odd about that?
The bug is in the gv viewer, or rather the ghostscript conversion
to X11, not in the PostScript file.
If you convert to pdf and use a different viewer then you bypass
the bug entirely.

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

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Daniel J S. <dan...@ie...>]

The example with the lines, i.e., "maps" could in some cases be done 
using the trm->image() routine to get rid of the white lines, and reduce 
the size of files.  Oddly, when doing ps2pdf on the postscript output, 
the white lines aren't visible in Acroread.  (In some cases 'though I 
see strange little blips at the corners of pm3d elements.)

Dan

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

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

On Thursday 15 July 2004 06:37 am, Petr Mikulik wrote:
> 
> > just an lucky side-effect of Ethan's changes to support pattern fills for
> > term->polygon().
> >
> > Looking at the generated postscript, it seems as if the only significant
> > difference between 4.0.2 and 4.1 is the order of output points, and, of
> > course, the PostScript macro being used:
> >
> > ---------4.0: ---------------
> > .3293 g 5148 927 N 0 -114 114 0 0 114 h
> > .3148 g 5033 927 N 0 -114 115 0 0 114 h
> > .2934 g 4918 927 N 0 -114 115 0 0 114 h
> >
> > /h {rlineto rlineto rlineto fill} bind def
> >
> > ---------4.1: ---------------
> > .3293 g 5148 927 N 0 114 V 114 0 V 0 -114 V 1.0 PolyFill
> > .3148 g 5033 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
> > .2934 g 4918 927 N 0 114 V 115 0 V 0 -114 V 1.0 PolyFill
> 
> 
> That's the new postscript code in 4.1?! I don't like it, sorry! It breaks
> compatibility with all those pm3dConvert* scripts, and puts a lot of
> "useless characters" into maps. I'm against this change!


Sorry, I don't understand.  What do you mean by "useless characters"?
Is it such a major problem to require updated scripts to go with updated
code in 4.1?  I'm sure there will be more things than this that change as
we develop 4.1.

Would it suffice to re-introduce "h" as a macro for "1.0 PolyFill"?
  
> > I.e., "pm3d map" should not be interfered by PolyFill. Why did this happen?

Because the PolyFill routine is more general than the older code.
I saw no reason to keep a separate, less-capable, routine when
instead boxfill() could just pass the request along to filled_polygon().

But feel free to go ahead and convince me otherwise.

> The syntax
>    .3293 g 5148 927 N 0 -114 114 0 0 114 h
> 
> is intended to produce line as short as possible and I insists it stays like
> that. 

Should we not first determine if the newer version is less buggy
in additional to being more general?

> (My demo example of a non-grid reciprocal space reflectivity maps 
> using "pm3d map" contains 40000 points and I don't wish to have any increase
> of the postscript file size.)

We can certainly look at making the current PolyFill macro more compact,
if you feel that is a major issue. But your script is going to crunch this down 
further anyhow, isn't it?  How much difference in size would there be after
running the [modified] script?

> (Anyway, why to write "1.0 PolyFill" and not "1 PolyFill"? Please keep
> postscript file as short as possible.)

Because that parameter is the fill density, on a scale from 0.0 to 1.0.
But yes, we could treat 1.0 as a very common special case and drop
the decimal point.  I can make that change immediately.

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

Re: PM3D postscript microgaps vanished from 4.0 to 4.1...

[Hans-Bernhard B. <br...@ph...>]

On Thu, 15 Jul 2004, Petr Mikulik wrote:

> > a newsgroup poster just found out a problem with (at least) post.trm pm3d
> > output exposed by turning on antialiasing (type 'a' in gv or ghostview)
> > --- there's a Moir'e pattern of very thin (single-pixel) white lines
> > exposed at the border between neighboring rectangles of pm3d plots.
> 
> It was always like that -- happens if you set option "Graphics Alpha" to 4
> bits (in gsview, I don't know how to change it in gv).

That just means it was always buggy, then.  (and yes, turning 
on 'Antialising' in gv does exactly that --- it sets the device to 
x11alpha, which in turn is described like this:

This is the x11 device, but with antialiasing. It is equivalent to
invoking the x11 device with the options -dGraphicsAlphaBits=4
-dTextAlphaBits=4 -dMaxBitmap=50000000


> That's the new postscript code in 4.1?! I don't like it, sorry! It breaks
> compatibility with all those pm3dConvert* scripts, and puts a lot of
> "useless characters" into maps. I'm against this change!

I'll leave it to you and Ethan to sort this out among yourselves...

> I.e., "pm3d map" should not be interfered by PolyFill. Why did this happen?

The goal would have been to get 'with filledcurves' to support pattern
filling.  Why it also triggers changes for plain 'with pm3d' plots
I don't know.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.