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

Re: error message from doc2texi

[Juergen W. <wie...@fr...>]

Reiner Steib wrote:
> > $ emacs --version
> > GNU Emacs 21.2.1
>
> Emacs loads AUCTeX's style file `/path/to/style/texinfo.el'
> instead of `emacs/<version>/lisp/textmodes/texinfo.el'
>
> "touch /path/to/style/.nosearch" should fix the problem.  If so,
> could you please tell me which version of AUCTeX shows this
> problem (see the variable `AUCTeX-version' or `AUC-TeX-version')?
>  If the AUCTeX packages is bundled with a GNU/Linux distribution,
> which distribution and version?

Yes, it fixes the problem. I have:

  AUC-TeX-version's value is "11.11"

  $ rpm -qa |grep auc
  emacs-auctex-11.11-158

and

  SuSE Professional 8.2


Yours,
Juergen

Re: error message from doc2texi

[Reiner S. <rei...@im...>]

On Wed, Sep 22 2004, Juergen Wieferink wrote:

> Creating texinfo
> Inserting help for terminals ...
> Analyzing doc file ...
> Converting to texinfo ...
> Menus, nodes, xrefs ...
> Loading texinfo (source)...
> Symbol's function definition is void: TeX-add-style-hook
> make[2]: *** [../../gnuplot-cvs/docs/gnuplot.texi] Fehler 255
>
> $ emacs --version
> GNU Emacs 21.2.1

Emacs loads AUCTeX's style file `/path/to/style/texinfo.el' instead of 
`emacs/<version>/lisp/textmodes/texinfo.el'

"touch /path/to/style/.nosearch" should fix the problem.  If so, could
you please tell me which version of AUCTeX shows this problem (see the
variable `AUCTeX-version' or `AUC-TeX-version')?  If the AUCTeX
packages is bundled with a GNU/Linux distribution, which distribution
and version?

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: how to build gnuplot with emf'2003 support

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

On Thu, 23 Sep 2004, Andrius Kurtinaitis wrote:

> Dear Gnuplotters,
> i need a version of gnuplot which can produce EMF files usable on 
> Office2003 programs. 

Office2003 and "emf'2003" are red herrings in this context.  The actual
change is in Windows (a security patch by MS dated May 2004), and it 
affects Office only by proxy.

And it's not the format that changed, but the tolerance to violations of
that format.  I.e. Windows used to accept gnuplot's previous way of
writing EMF files, but no longer accepts it now, so gnuplot had to change.

> would like to use most stable version that has the EMF workaround.
> Hence the question: should I get the CVS HEAD, or is the EMF workaround 
> available in the stable branch? If so, what is the name of the branch 
> and how do i get it.

The name of the branch is 
	
	branch-4-0-stable

And yes, that's what you should get.  The EMF patch is in place.

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

Re: error message from doc2texi

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

On Wed, 22 Sep 2004, Juergen Wieferink wrote:

[...]
> Loading texinfo (source)...
> Symbol's function definition is void: TeX-add-style-hook
> make[2]: *** [../../gnuplot-cvs/docs/gnuplot.texi] Fehler 255

FYI: I usually have to switch to xemacs to get around this...

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

how to build gnuplot with emf'2003 support

[Andrius K. <and...@ma...>]

Dear Gnuplotters,
i need a version of gnuplot which can produce EMF files usable on 
Office2003 programs. Currently i use the 4.0 binary from gnuplot.sf.net, 
which apparantly generates EMF files which can not be imported to 
Office2003. I read in the ml archives, that the workaround is already in 
CVS. Also, i remember some talk about branching the stable version. I 
would like to use most stable version that has the EMF workaround.
Hence the question: should I get the CVS HEAD, or is the EMF workaround 
available in the stable branch? If so, what is the name of the branch 
and how do i get it.
Thank you.
Andrius Kurtinaitis

Re: error message from doc2texi

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

The latest CVS works for me.  I've got emacs version

GNU Emacs 20.7.1
Copyright (C) 1999 Free Software Foundation, Inc.

The line giving you problems appears to be

  (load-library "texinfo") ;; now do the hard stuff with texinfo-mode

in the file 'doc2texi.el'.  Perhaps something in this library is 
different on your system.  Also, one other thing I notice different from 
your log is that on my system there is a second line "Loading psgml-init 
(source)...".  Maybe that's important.

Creating texinfo
Loading psgml-init (source)...
Inserting help for terminals ...
Analyzing doc file ...
Converting to texinfo ...
Menus, nodes, xrefs ...
Loading texinfo...
Making texinfo nodes ...
<etc.>

Dan



Juergen Wieferink wrote:

>Hi,
>
>building the current CVS version, I get:
>
>Creating texinfo
>Inserting help for terminals ...
>Analyzing doc file ...
>Converting to texinfo ...
>Menus, nodes, xrefs ...
>Loading texinfo (source)...
>Symbol's function definition is void: TeX-add-style-hook
>make[2]: *** [../../gnuplot-cvs/docs/gnuplot.texi] Fehler 255
>
>
>$ emacs --version
>GNU Emacs 21.2.1
>Copyright (C) 2001 Free Software Foundation, Inc.
>GNU Emacs comes with ABSOLUTELY NO WARRANTY.
>You may redistribute copies of Emacs
>under the terms of the GNU General Public License.
>For more information about these matters, see the file named 
>COPYING.
>
>
>It's not fatal, but what goes wrong?
>
>
>Juergen
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
>Project Admins to receive an Apple iPod Mini FREE for your judgement on
>who ports your project to Linux PPC the best. Sponsored by IBM.
>Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>  
>

-- 

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/

error message from doc2texi

[Juergen W. <wie...@fr...>]

Hi,

building the current CVS version, I get:

Creating texinfo
Inserting help for terminals ...
Analyzing doc file ...
Converting to texinfo ...
Menus, nodes, xrefs ...
Loading texinfo (source)...
Symbol's function definition is void: TeX-add-style-hook
make[2]: *** [../../gnuplot-cvs/docs/gnuplot.texi] Fehler 255


$ emacs --version
GNU Emacs 21.2.1
Copyright (C) 2001 Free Software Foundation, Inc.
GNU Emacs comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of Emacs
under the terms of the GNU General Public License.
For more information about these matters, see the file named 
COPYING.


It's not fatal, but what goes wrong?


Juergen

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>Yes, every x11 windows should have its own copy of the palette. When there
>is a new (re)plot, x11 should copy the current gnuplot palette into palette
>of the active window, and use that.
>
>Can you please implement this?
>

Petr, I'll take a look this weekend.

I don't like hacking stuff, and this may take some consideration.  I'm 
wondering how this should be structured, and whether we should be 
conservative with palette usage in order to not consume too much memory. 
 Are palettes memory consumers?  If so, it might be wise to not save a 
color map with every plot.  That is, say there is a fairly large 
palette, and then someone creates twenty plots.  If all those plots have 
a similar palette, it may be an inefficient use of memory.

Rather, it might be wise to have a linked-list of palettes.  Whenever a 
new palette is created, it is put in the linked list.  Then, when a 
palette is changed at the gnuplot command line, gplt_x11.c will search 
through the plot list and see if any of the plots is using the old 
palette.  If not, that color map can be discarded from the list.

It sounds unnecessarily tedious, but it really does seem like the thing 
to do, and it actually might simplify the various uses of XAllocColor 
and XFreeColors.

Dan

Re: maximing/resizing multiple x11: change of palette

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

> So, say two plots are created and by default they are both set to
> "plot->cmap = cmap".  Then whenever PaletteMake() is run on the colormap
> for one of the plots, it is effectively changing the color map for the
> other.  So, that is why I'm saying that somewhere along the way upon the
> creation of a plots color map, it must *duplicate* the default palette,
> i.e., malloc an equal amount of memory as "cmap" and then use memcpy().
>  That is, if one wants color maps to be preserved in plots.  I assume
> that when the palette is changed at gnuplot's command line, that change
> is supposed to apply to the default palette as well as the current
> plot's palette.

Yes, every x11 windows should have its own copy of the palette. When there
is a new (re)plot, x11 should copy the current gnuplot palette into palette
of the active window, and use that.

Can you please implement this?

---
PM

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>But that's completely different from the patch you have sent:
>                XFreePixmap(dpy, plot->pixmap);
>                plot->pixmap = None;
>            }
>+           if (plot != current_plot)
>+               RecolorWindow(plot);
>            display(plot);
>+           if (plot != current_plot)
>+               RecolorWindow(current_plot);
>        }
>     }
>
>Thus, what's the patch?
>

Oh, that one at first escaped me.  But looking back in the emails, I 
think that was the first attempt to make the link list contain 
information about palettes.  But soon after that I realized that such 
code already exists.  So the above patch you are referring to was 
jettisoned.

>>That fixes the problem of keeping track of the color map, but it also
>>results in an incorrect color map. It looks like a tricky bit of code
>>because it is recursive. I'm not exactly sure why it is recursive, as
>>opposed to calling a subroutine twice. In fact, I'm looking at some code
>>there and wondering what in fact it does. Here is the code in question:
>>
>>Notice that the second portion of the if/else statement alters two local
>>variables, previous and unique_colors, and that is all. That's a useless
>>bit of code, as I see it. I wish there were a short note explaining why
>>this is recursive, i.e., on the second time through, what portion of the
>>code is important?
>>    
>>
>
>I remember from the old times when Johannes was coding "Make Palette"
>function for X11 (term->makepalette(NULL)), that number of available colors
>is not known under some visual modes. Then, you have to try to allocate
>color palette several times until you find the limit. Can this explain the
>recursion?
>
>However, I wonder why this happens -- once the palette is constructed
>(according to t_sm_palette) and copied into plot->cmap, it should be used in
>every replot of that window.
>

If I recall, I think I tracked down the flaw in program flow.  Let me 
look for that... here's a portion of what I wrote before:

=====
I think that is the problem.  The first time in, the min_colors will be 
2 or 10 in one of the examples Petr gives.  However, the default cmap, 
what plot->cmap points to by default has more than 10 allocated values. 
Hence, that test never passes and the code which dynamically allocates 
the cmap never gets called.
=====

Regardless of whether that is correct or not, I think I'm getting a 
better view of the big picture here.  The real flaw may not necessarily 
be in PaletteMake(), although I think PaletteMake() needs a good going 
over to weed out cruft.  Well, I shouldn't say that, because I think 
this problem could be fixed in multiple ways.

The problem may be the following.  When a plot window is first created, 
its "plot->cmap" is set equal to the default "cmap".  I propose that 
rather than just pointing to the default colormap, the colomap should be 
*duplicated* in memory.  The reason is that PaletteMake() doesn't 
necessarily create a new version of color map unless those strange 
conditions (which I don't fully understand) are met, i.e.,

    if (plot->cmap->allocated < min_colors && !recursion) {
      ReleaseColormap(plot);
      /* create a private colormap. */
      fprintf(stderr, "switching to private colormap\n");
      plot->cmap = (cmap_t *) malloc(sizeof(cmap_t));
      assert(plot->cmap);
      CmapClear(plot->cmap);
      plot->cmap->colormap = XCreateColormap(dpy, root, vis, AllocNone);
      assert(plot->cmap->colormap);
      pr_color(plot->cmap);    /* set default colors for lines */
      RecolorWindow(plot);
      recursion = 1;
      PaletteMake(plot, (t_sm_palette *) tpal);
    } else {

The above is the only place in PaletteMake() that plot->cmap is 
malloced.  That means that if that condition above is not met, which is 
almost certain to be the case, then the rest of PaletteMake() must act 
upon the "plot->cmap".

So, say two plots are created and by default they are both set to 
"plot->cmap = cmap".  Then whenever PaletteMake() is run on the colormap 
for one of the plots, it is effectively changing the color map for the 
other.  So, that is why I'm saying that somewhere along the way upon the 
creation of a plots color map, it must *duplicate* the default palette, 
i.e., malloc an equal amount of memory as "cmap" and then use memcpy(). 
 That is, if one wants color maps to be preserved in plots.  I assume 
that when the palette is changed at gnuplot's command line, that change 
is supposed to apply to the default palette as well as the current 
plot's palette.

Dan

Re: multiplot doc spelling errors

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

Petr Mikulik wrote:

>>Attached is a patch to fix spelling errors in the mulitplot documentation.
>>    
>>
>
>I will commit it, with yet another fix to "will a produce".
>

Yes, another typo.

>However, I have one more major point there:
>Docs says:
> This grid is filled rows first or columns first depending whether
> `rowmajor` or `columnmajor` is given by the subsequent option of the
> multiplot command. Default is `columnmajor`.
>
>That's confusing: either words in the above are opposite, or "major" does
>not mean "the slower scan in filling". Currently, it works this way:
>"rowmajor" fills columns first, "columnmajor" fills rows first. It should be
>said explicitly e.g.
>

Oh yeah.  Something does seem to be backward.  The behavior I'm seeing 
does look like row major, not column major.

>
> This grid is filled rows first or columns first depending whether
> `columnmajor` or `rowmajor` is given by the subsequent option of the
> multiplot command, respectively.
>
>Or should the keywords be renamed to e.g. "rowsfirst" and "columnsfirst"?
>

Although "rowsfirst" does seem less ambiguous, I think column major and 
row major are fairly well used terminology.  So, maybe stick with that 
terminology and just change the documentation so that it says `rowmajor` 
is the default.  (Octave types out a little diagram in its "help 
subplot" text.)

>And yet another observation:
>If a wrong option is given, e.g.
>       set multiplot layout 3,2 blacolumnmajor
>produces error message:
>    did not expect anythig here
>Firstly, there should be "anything". Secondly, the message is not
>very well descriptive. What about "wrong option" instead?
>

Yeah, not a good comment, because obviously gnuplot does expect that 
something could follow.  "Unrecognized option" or "Invalid option" 
perhaps.  "wrong" sounds too much like it could be a valid keyword, but 
just used out of context.

Dan

Re: multiplot doc spelling errors

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

> Attached is a patch to fix spelling errors in the mulitplot documentation.

I will commit it, with yet another fix to "will a produce".

However, I have one more major point there:
Docs says:
 This grid is filled rows first or columns first depending whether
 `rowmajor` or `columnmajor` is given by the subsequent option of the
 multiplot command. Default is `columnmajor`.

That's confusing: either words in the above are opposite, or "major" does
not mean "the slower scan in filling". Currently, it works this way:
"rowmajor" fills columns first, "columnmajor" fills rows first. It should be
said explicitly e.g.

 This grid is filled rows first or columns first depending whether
 `columnmajor` or `rowmajor` is given by the subsequent option of the
 multiplot command, respectively.

Or should the keywords be renamed to e.g. "rowsfirst" and "columnsfirst"?


And yet another observation:
If a wrong option is given, e.g.
       set multiplot layout 3,2 blacolumnmajor
produces error message:
    did not expect anythig here
Firstly, there should be "anything". Secondly, the message is not
very well descriptive. What about "wrong option" instead?

Petr

Re: maximing/resizing multiple x11: change of palette

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

> >I have just tried the patch, but it was rejected. Don't you have an
> >up-to-date version?
>
> Why would that patch be rejected? I don't think anyone has altered that
> bit of code in CVS...

In the cvs current version, there is no that piece of code to be patched.
Haven't you use some old gplt_x11.c?


>     if (plot->cmap->allocated < min_colors && !recursion) {
> and replace it with the following
>     if (!recursion) {

But that's completely different from the patch you have sent:
                XFreePixmap(dpy, plot->pixmap);
                plot->pixmap = None;
            }
+           if (plot != current_plot)
+               RecolorWindow(plot);
            display(plot);
+           if (plot != current_plot)
+               RecolorWindow(current_plot);
        }
     }

Thus, what's the patch?


> That fixes the problem of keeping track of the color map, but it also
> results in an incorrect color map. It looks like a tricky bit of code
> because it is recursive. I'm not exactly sure why it is recursive, as
> opposed to calling a subroutine twice. In fact, I'm looking at some code
> there and wondering what in fact it does. Here is the code in question:
>
> Notice that the second portion of the if/else statement alters two local
> variables, previous and unique_colors, and that is all. That's a useless
> bit of code, as I see it. I wish there were a short note explaining why
> this is recursive, i.e., on the second time through, what portion of the
> code is important?

I remember from the old times when Johannes was coding "Make Palette"
function for X11 (term->makepalette(NULL)), that number of available colors
is not known under some visual modes. Then, you have to try to allocate
color palette several times until you find the limit. Can this explain the
recursion?

However, I wonder why this happens -- once the palette is constructed
(according to t_sm_palette) and copied into plot->cmap, it should be used in
every replot of that window.

Petr

Re: Third small fix

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

On Friday 17 September 2004 06:20 am, Harald Harders wrote:
> In postscript terminal, also Rounded is adjustable by the user and should
> be in the list of changeable options:
> 
> And here is another fix (sorry for two single mails):

All three of your fixes are now in CVS.

	Ethan

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

multiplot doc spelling errors

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

Attached is a patch to fix spelling errors in the mulitplot documentation.

Also, I notice in this documentation that

?nomultiplot

is a means to access this text.  Perhaps all the cases of

?no<keyword>

that appear in gnuplot.doc can be moved under the same heading

?nomultiplot
?noarrow
etc.

Deprecated syntax.  Use `unset <keyword>` instead.

Re: maximing/resizing multiple x11: change of palette

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

Petr Mikulik wrote:

>>The complete color map needs to be stored as part of the structure.
>> That is, plot->cmap needs to point at something that is dynamically
>>allocated independent of the current color map.  I'll work on that fix,
>>but if this doesn't sound correct, let me know.  Also, maybe think if
>>what I've added in this patch is adequate to fix the problem when I have
>>the plot->cmap problem fixed.  That is, are there any other details
>>about the GC that also must be updated?
>>    
>>
>
>I have just tried the patch, but it was rejected. Don't you have an
>up-to-date version?
>

Why would that patch be rejected? I don't think anyone has altered that 
bit of code in CVS... Anyway, that patch was just a lame alteration to 
illustrate where the problem lies. Basically, search for this line of 
code in gplt_x11.c

    if (plot->cmap->allocated < min_colors && !recursion) {


and replace it with the following

    if (!recursion) {


That fixes the problem of keeping track of the color map, but it also 
results in an incorrect color map. It looks like a tricky bit of code 
because it is recursive. I'm not exactly sure why it is recursive, as 
opposed to calling a subroutine twice. In fact, I'm looking at some code 
there and wondering what in fact it does. Here is the code in question:

if (plot->cmap->allocated < min_colors && !recursion) {
ReleaseColormap(plot);
/* create a private colormap. */
fprintf(stderr, "switching to private colormap\n");
plot->cmap = (cmap_t *) malloc(sizeof(cmap_t));
assert(plot->cmap);
CmapClear(plot->cmap);
plot->cmap->colormap = XCreateColormap(dpy, root, vis, AllocNone);
assert(plot->cmap->colormap);
pr_color(plot->cmap); /* set default colors for lines */
RecolorWindow(plot);
recursion = 1;
PaletteMake(plot, (t_sm_palette *) 0);
} else {
/* this is just for calculating the number of unique colors */
int i;
unsigned long previous = plot->cmap->allocated ? plot->cmap->pixels[0] : 0;
int unique_colors = 1;
for (i = 0; i < plot->cmap->allocated; i++) {
if (plot->cmap->pixels[i] != previous) {
previous = plot->cmap->pixels[i];
unique_colors++;
}
}
}

Notice that the second portion of the if/else statement alters two local 
variables, previous and unique_colors, and that is all. That's a useless 
bit of code, as I see it. I wish there were a short note explaining why 
this is recursive, i.e., on the second time through, what portion of the 
code is important?

Dan

Third small fix

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

In postscript terminal, also Rounded is adjustable by the user and should
be in the list of changeable options:

diff -uNr orig/term/post.trm fixes3/term/post.trm
--- orig/term/post.trm=09Thu Sep 16 23:22:28 2004
+++ fixes3/term/post.trm=09Fri Sep 17 15:05:07 2004
@@ -1397,7 +1397,7 @@
 %%%%EndComments\n\
 /gnudict 256 dict def\ngnudict begin\n\
 %%\n\
-%% The following 5 true/false flags may be edited by hand if required\n\
+%% The following 6 true/false flags may be edited by hand if required\n\
 %% The unit line width may also be changed\n\
 %%\n\
 /Color %s def\n\
@@ -1405,6 +1405,7 @@
 /Solid %s def\n\
 /Landscape %s def\n\
 /Level1 %s def\n\
+/Rounded %s def\n\
 /gnulinewidth %.3f def\n\
 /userlinewidth gnulinewidth def\n\
 %%\n\
@@ -1413,8 +1414,7 @@
 /hpt_ %.1f def\n\
 /vpt_ %.1f def\n\
 /hpt hpt_ def\n\
-/vpt vpt_ def\n\
-/Rounded %s def\n";
+/vpt vpt_ def\n";

     static const char GPFAR * GPFAR PS_iso_8859_1_encoding[] =3D {
 "/reencodeISO {\n",
@@ -1867,12 +1867,12 @@
 =09    ps_solid ? "true" : "false",
 =09    ps_portrait ? "false" : "true",
 =09    ps_level1 ? "true" : "false",
+=09    ps_rounded ? "true" : "false",
 =09    PS_LW*ps_linewidth_factor,=09/* line width */
 =09    (int)(t->v_char)/(-3),=09/* shift for vertical centring */
 =09    PS_SC*ps_dash_length,=09/* dash length */
 =09    PS_HTIC/2.0,=09=09/* half point width */
-=09    PS_VTIC/2.0,=09=09/* half point height */
-=09    ps_rounded ? "true" : "false");
+=09    PS_VTIC/2.0);=09=09/* half point height */

     /* insert font encoding vector */
     if (uses_fonts) {


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.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: maximing/resizing multiple x11: change of palette

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

> The complete color map needs to be stored as part of the structure.
>  That is, plot->cmap needs to point at something that is dynamically
> allocated independent of the current color map.  I'll work on that fix,
> but if this doesn't sound correct, let me know.  Also, maybe think if
> what I've added in this patch is adequate to fix the problem when I have
> the plot->cmap problem fixed.  That is, are there any other details
> about the GC that also must be updated?

I have just tried the patch, but it was rejected. Don't you have an
up-to-date version?

Petr

Another bug

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

And here is another fix (sorry for two single mails):

diff -uNr orig/term/gd.trm fixes2/term/gd.trm
--- orig/term/gd.trm=09Thu Sep  2 16:52:01 2004
+++ fixes2/term/gd.trm=09Fri Sep 17 14:28:13 2004
@@ -1547,7 +1547,7 @@
 =09=09fprintf(stderr,"gdImageStringFT: %s while printing string %s with fo=
nt %s\n",
 =09    =09    err,enhanced_text,ENHgd_font);

-=09    FPRINTF(("outputstring: %s boundingbox: %d %d %d %d\n",
+=09    FPRINTF((stderr,"outputstring: %s boundingbox: %d %d %d %d\n",
 =09=09=09enhanced_text, brect[6], brect[7], brect[2], brect[3]));
 =09    if (ENHgd_overprint =3D=3D 1) {
 =09=09png_state.x +=3D ((brect[2] - brect[0]))/2;

--=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.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Some small fixes

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

I have found some minor bugs in the terminal README and in the debug
terminal. Here comes the diff:

diff -ru orig/term/README fixes/term/README
--- orig/term/README=09Thu Sep  2 16:52:00 2004
+++ fixes/term/README=09Fri Sep 17 14:22:29 2004
@@ -29,7 +29,7 @@

 Each driver provides all the functions it needs, and a table of
 function pointers and other data to interface to gnuplot.
-The table entry is currently defined as follows in plot.h:
+The table entry is currently defined as follows in term_api.h:

 struct TERMENTRY {

@@ -80,6 +80,13 @@
 #ifdef IMAGE_DRIVER
     void (*image) __PROTO((unsigned, unsigned, coordval *, gpiPoint *, t_i=
magecolor));
 #endif
+
+/* Enhanced text mode driver call-backs */
+    void (*enhanced_open) __PROTO((char * fontname, double fontsize,
+=09=09double base, TBOOLEAN widthflag, TBOOLEAN showflag,
+=09=09int overprint));
+    void (*enhanced_flush) __PROTO((void));
+    void (*enhanced_writec) __PROTO((int c));
 };

 One consequence of (1) is that we would like drivers to be backwards
diff -ru orig/term/debug.trm fixes/term/debug.trm
--- orig/term/debug.trm=09Thu Jul  1 19:10:12 2004
+++ fixes/term/debug.trm=09Fri Sep 17 14:21:10 2004
@@ -227,7 +227,7 @@
 }

 TERM_PUBLIC void
-DEBUG_point((unsigned int x, unsigned int y, int pointstyle)
+DEBUG_point(unsigned int x, unsigned int y, int pointstyle)
 {
     fprintf(gpoutfile, "point at (%ud,%ud), pointstyle %d\n", x, y, points=
tyle);
 }

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.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: Character encodings in PostScript driver

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

On Fri, 17 Sep 2004, Petr Mikulik wrote:

> > The only problem I see are 8.3 filenames. Is there still an operating
> > system that does not work with longer file names?
> 
> DOS is no longer supported in gnuplot beyond 4.0.

Wrong.  32-bit DOS (i.e. DJGPP) is still very much supported, and should
continue to be, if at all possible.  What we dropped in 4.0 was *16-bit*
DOS/Windows support, not DOS support per se.  On platforms that have long
file names and support them for DOS (i.e. everything except raw DOS, and
NT up to version 4), DJGPP-built executables will have access to them.

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

Re: Character encodings in PostScript driver

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

On Fri, 17 Sep 2004, Petr Mikulik wrote:

> > should also understand strings as argument. Then, for example,
> >     set encoding 'privatenc'
> > loads the encoding file `privateenc.enc'.
>
> It should still be "set encoding <encoding>", just the postscript driver
> should load its encoding from a corresponding file. Other terminals work
> differently.

This is true, of course. But I still like the idea to be able to add new
encodings by providing a new encoding file.

> I think that file could be a collection of files like in a2ps/encoding
> directory.
>
> In order to save disk space, it could be a single file gzipped? (Gnuplot
> linked with libz (needed for libgd et al anyway) can read them directly.)

I prefer single files. It is easier to maintain these.

> > The only problem I see are 8.3 filenames. Is there still an operating
> > system that does not work with longer file names?
>
> DOS is no longer supported in gnuplot beyond 4.0.

That makes things easier.

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.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: Character encodings in PostScript driver

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

> should also understand strings as argument. Then, for example,
>     set encoding 'privatenc'
> loads the encoding file `privateenc.enc'.

It should still be "set encoding <encoding>", just the postscript driver
should load its encoding from a corresponding file. Other terminals work
differently.

I think that file could be a collection of files like in a2ps/encoding
directory.

In order to save disk space, it could be a single file gzipped? (Gnuplot
linked with libz (needed for libgd et al anyway) can read them directly.)

> The only problem I see are 8.3 filenames. Is there still an operating
> system that does not work with longer file names?

DOS is no longer supported in gnuplot beyond 4.0.

---
PM

Re: Character encodings in PostScript driver

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

On Fri, 17 Sep 2004, Petr Mikulik wrote:

> > that any substantial fraction of them get hard-coded into gnuplot's
> > PostScript terminal driver.
>
> Fortunately there are only few supported until now.
> That could change if we really want to support all possible encodings.

And it could ease the addition of new encodings, even by users, without
recompiling gnuplot. The only additional requesite is that "set encoding"
should also understand strings as argument. Then, for example,
    set encoding 'privatenc'
loads the encoding file `privateenc.enc'. For the already known encodings,
a compatiblity mode should be preserved, i.e., they should continue to
work without quotation marks.

The only problem I see are 8.3 filenames. Is there still an operating
system that does not work with longer file names?

> I don't like new environmental variable. There is already GNUPLOT_LIB; an=
d
> also "set loadpath". That's enough.
[...]
> But that's simple: that ps header file should be in the same directory as
> gnuplot executable, or in GNUPLOT_LIB, or gnuplot_loadpath.

I fully agree.

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.harald-harders.de     Fax: +49 (5 31) 3 91-3058

Re: Character encodings in PostScript driver

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

> that any substantial fraction of them get hard-coded into gnuplot's
> PostScript terminal driver.

Fortunately there are only few supported until now.
That could change if we really want to support all possible encodings.

> I propose that we back out all of the in-line character encodings
> from post.trm, and instead have a general mechanism of loading
> any requested encoding from an external file.  If you recall, I
> coded up a simple patch to do this in the run-up to version 4
> because it was needed in order to reduce the total size of
> the terminal driver to the point it could be built for 16-bit DOS/Win.

> The chief benefit from this is that new encodings could be
> added without patching or rebuilding gnuplot from source;
> you would just have to place an appropriately named file
> in the path specified by some environmental variable,
> e.g. GNUPLOT_PSFILES.

I don't like new environmental variable. There is already GNUPLOT_LIB; and
also "set loadpath". That's enough.

> As I recall, the only real objection at the time was a fear that
> these external files containing the character encoding info
> would get lost under Windows because there is no standard
> directory in which to put such things.  I don't really have much
> sympathy with limiting gnuplot's options just because Windows
> is poorly designed.

We can also say the opposite: gnuplot is poorly designed because it does not
know where to put its files... That's what the installation program does
(but gnuplot does not have it).

But that's simple: that ps header file should be in the same directory as
gnuplot executable, or in GNUPLOT_LIB, or gnuplot_loadpath.

Thus its search should be that one already implemented for any other OS,
i.e. on Windows, DOS, OS/2 you must replace "/usr/(local/)lib/" by "<dir of
gnuplot exefile>".

---
PM