gnuplot development

On Sunday 24 April 2005 08:00 am, Petr Mikulik wrote:
> When trying demo/enhancedtext.dem, I've found few bugs:
>
> 1.
> Enhanced text in x11 terminal is ignored for subscripts and
> superscripts:
>
> set term x11 enhanced
> set label 3 "{/Symbol abcd} e^{/Symbol abcd} g_{/Symbol abcd}" at 0,-6
> plot x

Works fine for me.
What symbol font is your X-server finding?

> 2.
> png terminal should ignore cases in font names:
> set term png enha font "arial.ttf"
> set out 'a.png'
> load '/usr/share/doc/packages/gnuplot/demo/enhancedtext.dem'
>
> It prints errors, while one would expect "/Symbol" to be the same as
> "/symbol":

No. These are file names, which are case-sensitive.
"Symbol" is an Adobe font name, "symbol" is a TrueType font name.
On my machine, 'font "Symbol"' will find and use
   /usr/share/fonts/default/Type1/Symbol.pfb
while 'font "symbol"' will find and use
   /home/local/share/ttfonts/symbol.ttf

> 3.
> In "help x11":
>     set title '{\=20 Big} Medium {\=5 Small}'
> => I think those "\" should be "/"

Yes, those are typos. I'll correct it.

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

> > 1.
> > Enhanced text in x11 terminal is ignored for subscripts and
> > superscripts:
> >
> > set term x11 enhanced
> > set label 3 "{/Symbol abcd} e^{/Symbol abcd} g_{/Symbol abcd}" at 0,-6
> > plot x
>
> Works fine for me.
> What symbol font is your X-server finding?

How can I know that?

There is no "Symbol.pfb" on my disk; there is
"/usr/share/htmldoc/fonts/Symbol.pfa".

xlsfonts shows 6 lines starting with"-adobe-symbol".

Should I copy symbol.ttf and Symbol.ttf into
/usr/X11R6/lib/X11/fonts/truetype ?

> > 2.
> > png terminal should ignore cases in font names:
> > set term png enha font "arial.ttf"
> > set out 'a.png'
> > load '/usr/share/doc/packages/gnuplot/demo/enhancedtext.dem'
> >
> > It prints errors, while one would expect "/Symbol" to be the same as
> > "/symbol":
>
> No. These are file names, which are case-sensitive.
> "Symbol" is an Adobe font name, "symbol" is a TrueType font name.
> On my machine, 'font "Symbol"' will find and use
>    /usr/share/fonts/default/Type1/Symbol.pfb
> while 'font "symbol"' will find and use
>    /home/local/share/ttfonts/symbol.ttf

I would expect /Symbol "mean" symbol font for whichever terminal -- maybe it
could retry "symbol.ttf" if "Symbol.ttf" was not found?
Currently I have fixed it by "ln -s symbol.ttf Symbol.ttf" in GDFONTPATH's
dir.

---
PM

On Monday 25 April 2005 06:37 am, Petr Mikulik wrote:
> > > 1.
> > > Enhanced text in x11 terminal is ignored for subscripts and
> > > superscripts:
> > >
> > > set term x11 enhanced
> > > set label 3 "{/Symbol abcd} e^{/Symbol abcd} g_{/Symbol abcd}" at
> > > 0,-6 plot x
> >
> > Works fine for me.
> > What symbol font is your X-server finding?
>
> How can I know that?

The x11 documentation tells you how the full font name template 
is constructed from the requested short name of the font.
If the shorthand is "Symbol" then the template used is
   -*-Symbol-*-r-*-*-<size>-*-*-*-*-*-*-*
Where <size> is the font size requested.  

To find out if your font server is offering such a font,
you can try using this to open a new window.  E.g.
  xterm -fn '-*-Symbol-*-r-*-*-<size>-*-*-*-*-*-*-*'

To find out the complete list of symbol fonts offered by
your current font server configuration
  xlsfonts | grep -i symbol
(Sorry, I see you already knew that).
When an x11 application makes a font request, it will get the
first font in the list that matches the requested template.

X11 font names are *not* case senstive (don't ask me why;
it's always been that way). 

> There is no "Symbol.pfb" on my disk; there is
> "/usr/share/htmldoc/fonts/Symbol.pfa".

That's fine. So if you like, you can add this directory 
to GDFONTPATH so that the png driver uses it.

> Should I copy symbol.ttf and Symbol.ttf into
> /usr/X11R6/lib/X11/fonts/truetype ?

You said that your X-server is already finding
Adobe symbol fonts.  If you would rather have it use a
TrueType symbol font, then you need to re-arrange the list
of font directories used by the font server so that the
TrueType fonts are found before the Adobe fonts.

> I would expect /Symbol "mean" symbol font for whichever terminal --
> maybe it could retry "symbol.ttf" if "Symbol.ttf" was not found?

I suppose so, but then you would not see an error message if you
really *did* want "Symbol.pfa" and for some reason it was not being
found.

> Currently I have fixed it by "ln -s symbol.ttf Symbol.ttf" in
> GDFONTPATH's dir.

Sure. That's a perfectly good solution. General users can make
a private directory of font aliases, e.g. in $HOME/.fonts/, and
fill it with such symlinks and add this private directory to
the front of GDFONTPATH.

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

> To find out the complete list of symbol fonts offered by
> your current font server configuration
>   xlsfonts | grep -i symbol
>
> > There is no "Symbol.pfb" on my disk; there is
> > "/usr/share/htmldoc/fonts/Symbol.pfa".
>
> That's fine. So if you like, you can add this directory
> to GDFONTPATH so that the png driver uses it.
>
> > Should I copy symbol.ttf and Symbol.ttf into
> > /usr/X11R6/lib/X11/fonts/truetype ?

I've solved it by copying "symbol.ttf" into
/usr/X11R6/lib/X11/fonts/truetype. It was missing after fresh install of my
linux box. Thanks for ideas.

Now, the only difference in the image produced by
/usr/share/doc/packages/gnuplot/demo/enhancedtext.dem

into png, ps and x11 is that in x11 the "integral" sign is missing:
set label 11 "{/Symbol=18 \362 ...}

Why, when it is using the same encoding and the same file symbol.ttf?


***

BTW, a small bug here:

t='test.dat'
set term x11 1 title t

=> it writes the title as "t" instead of "test.dat".
Can you please have a look?

---
PM

On Thursday 28 April 2005 09:57 am, Petr Mikulik wrote:
> 
> BTW, a small bug here:
> 
> t='test.dat'
> set term x11 1 title t
> 
> => it writes the title as "t" instead of "test.dat".
> Can you please have a look?

When I modified the core routines in .../src/*.c to use
string variables, I did not go through all the driver code
and change things there also.  Each terminal driver will
have to be audited for options that might reasonably take a
string variable.  But I guess I can take them one at a time,
starting with x11.trm

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

Robert Hart wrote:

> This is because all the terminals are #included into term.c, and
> therefore they are all rebuilt together.

Not "all the drivers" --- only the ones selected by your current term.h.
If you're noticeably bothered by the compile time for time.c, feel free 
to use a cut-down version of term.h for the tests.  There's even a 
precedent you can start off from: see the SHORT_TERMLIST conditional 
section at the start of term.h.

> It seems from the way the .trm files are laid out, it would be a
> simple matter to compile each one separately, and link them together 
> like standard .c files.

That was indeed a major motive behind the re-structuring of all terminal 
drivers performed a *long* time ago.

> Any reason why this hasn't been done?

Because the actual need never arose --- the platform where it would have 
been most important was 16-bit DOS.  It fails to compile for different 
reasons than the size of term.obj, nowadays...

On Thu, 2005-04-28 at 14:03 +0200, Hans-Bernhard Broeker wrote:

> Not "all the drivers" --- only the ones selected by your current term.h.
> If you're noticeably bothered by the compile time for time.c, feel free 
> to use a cut-down version of term.h for the tests.  There's even a 
> precedent you can start off from: see the SHORT_TERMLIST conditional 
> section at the start of term.h.

Yes, I have started using that, although you either need to add the
pslatex or remover the postscript driver, because they are
interdependent.

I'm also starting to realise that the terminal interface isn't the most
consistent of things, presumably due to the way its been extended and
modified over the years.

Is there any documentation about how mouse events are passed back to
gnuplot, and how colours/palettes work for the PM3D thing? The X11
driver seems the most "feature complete", but because it does the
(incredibly complicated) IPC thing, its quite hard to follow as an
example.

Rob

-- 
Robert Hart <enxrah@...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

> Is there any documentation about how mouse events are passed back to
> gnuplot, and how colours/palettes work for the PM3D thing?

Read:
	src/README
	term/README

---
PM

On Thu, 2005-04-28 at 15:51 +0200, Petr Mikulik wrote:
> > Is there any documentation about how mouse events are passed back to
> > gnuplot, and how colours/palettes work for the PM3D thing?
> 
> Read:
> 	src/README
> 	term/README

Ahh! Thanks. I naively thought that all the information I needed to
write a terminal driver would be in term/README. Now I can waste even
more of the time that I should be spending on writing up my PhD!

Rob

-- 
Robert Hart <enxrah@...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

On Thursday 28 April 2005 06:32 am, Robert Hart wrote:
> 
> Yes, I have started using that, although you either need to add the
> pslatex or remover the postscript driver, because they are
> interdependent.

Yes. the pslatex driver got totally revamped recently and I don't
think the configure + build files have entirely caught up.
 
> Is there any documentation about how mouse events are passed back to
> gnuplot, 

Not really. I have come to a gradual understanding of the x11
implementation, but only by exploration of the source code.
So far as I know, the windows and os2 mousing doesn't have much
in common with x11, but I have never worked with them so I don't
know. Feel free to ask questions about how specific things work
in x11, however.

> The X11 driver seems the most "feature complete", but because it does the
> (incredibly complicated) IPC thing, its quite hard to follow as an
> example.

What are you trying to do, exactly?  If you want to write an entirely
new driver, then you don't really need to use x11.trm as a model.
As you say, the x11 implementation is convoluted because of the 
external process and piped commumication.  I'm afraid each new terminal
device is likely to be quite different from existing ones, so you may
need to rethink how interaction is done.

For example, one thing I'd love to see is mousing support for
the svg driver, so that you could use gnuplot to generate interactive
web pages.  But in that case the mousing interaction will happen long
after gnuplot has generated the svg output, so it must be implemented
as some sort of jscript or other module that is wrapped with the
generated svg for later execution.  I can't see that it would share
much of anything with the x11 mousing code.

> and how colours/palettes work for the PM3D thing? 

That really is pretty generic, particularly for a true RGB color
output device.  If a new driver provides the documented entry
routines, then the core code should do the rest.  I'd suggest looking
at pdf.trm as an example, or maybe svg.trm.

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

Daniel J Sebald wrote:
> I'd prefer that if "color" is chosen for the PostScript terminal, the 
> line style would be "solid" by default as opposed to dashed.  Anyone 
> else forget to select "solid" as often as I do?

I'm against it.  Such internal dependencies of command options on each 
other are a FAQ / documentation nightmare waiting to happen.

> > I'd prefer that if "color" is chosen for the PostScript terminal, the
> > line style would be "solid" by default as opposed to dashed.  Anyone
> > else forget to select "solid" as often as I do?
>
> I'm against it.  Such internal dependencies of command options on each
> other are a FAQ / documentation nightmare waiting to happen.

Even it is not convenient, I also prefer to keep "solid color" as a must.

---
PM

Petr Mikulik wrote:
>>>I'd prefer that if "color" is chosen for the PostScript terminal, the
>>>line style would be "solid" by default as opposed to dashed.  Anyone
>>>else forget to select "solid" as often as I do?
>>
>>I'm against it.  Such internal dependencies of command options on each
>>other are a FAQ / documentation nightmare waiting to happen.
> 
> 
> Even it is not convenient, I also prefer to keep "solid color" as a must.

If one has only a few traces and color, why a dotted line?  It seems to me this 
would fall into a "user expectation" sort of thing simply because most color 
plots we see have solid lines.

Dan

On Mon, 2005-04-25 at 00:34 -0500, Daniel J Sebald wrote:

> If one has only a few traces and color, why a dotted line?  It seems to me this 
> would fall into a "user expectation" sort of thing simply because most color 
> plots we see have solid lines.

It makes sense, where possible, for colour figures to be reproducible in
b&w without loss of information. This is often a requirement for journal
papers and the like, so it is a sensible default, and it isn't hard to
change it if you so desire.

Rob

-- 
Robert Hart <enxrah@...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Massimo Canonico wrote:

> In the version 4.1, it seems that this option is not still available.

It's still there.  What made you think it wasn't.  You showed us what 
your code looks like, but forgot to tell what the suspected bug was.

Hans-Bernhard Broeker wrote:

> Massimo Canonico wrote:
>
>> In the version 4.1, it seems that this option is not still available.
>
>
> It's still there.  What made you think it wasn't.  You showed us what 
> your code looks like, but forgot to tell what the suspected bug was.
>

This is the error message:
[mcanonic@... ~]$ ~/sw/gp/bin/gnuplot -persist
Cannot open load file '-persist'
line 0: util.c: No such file or directory

Thanks,
   Massimo






>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime 
> info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Massimo Canonico wrote:
> This is the error message:
> [mcanonic@... ~]$ ~/sw/gp/bin/gnuplot -persist
> Cannot open load file '-persist'
> line 0: util.c: No such file or directory

This is most likely caused by your gnuplot having built without X11 
support.  -persist is a X11 terminal option, not a general gnuplot 
option, so a gnuplot built without the X11 driver will not know this option.

Usual fix: install the X11 development packages of your Linux distro.