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

Re: gnuplot-beta digest, Vol 1 #775 - 11 msgs

[Per P. <per...@ma...>]

Upgrading to AquaTerm 1.0 should solve your problem:
http://aquaterm.sourceforge.net/

Regards,
Per

On Apr 19, 2006, at 05:10, gnu...@li...  
wrote:

> Message: 7
> To: gnu...@li...
> From: Kerstin Bunte <ker...@t-...>
> Subject: Problem with "plot x with points"
> Date: Tue, 18 Apr 2006 00:30:28 +0200
>
> Hi,
>
> I've running gnuplot 4.1on a Mac 10.4.6 with aqua v1.0.b2 Terminal
> type set to 'aqua'.
> Now I've trying to plot some 2D datafile.
>
> This line run's fine
> gnuplot> plot "data.csv" with line
>
>
> but this not
> gnuplot> plot "data.csv" with points
> 2006-04-18 00:24:37.483 gnuplot[431] *** -[AQTAdapter
> setLinestyleSolid]: selector not recognized [self = 0x1503fa0]
> 2006-04-18 00:24:37.485 gnuplot[431] *** Uncaught exception:
> <NSInvalidArgumentException> *** -[AQTAdapter setLinestyleSolid]:
> selector not recognized [self = 0x1503fa0]
> Trace/BPT trap
>
> but I don't find any solution for my problem.
> Thanks for your help
>
> Greetings Kerstin
>

Re: ps and eps not good!

[<br...@ph...>]

Arnaldo Gammal wrote:
> Dear Sirs,
> 
> I departed from data points and generated densitys plots using gnuplot.

How exactly did you generate them, using which version of gnuplot?

> I could well see the picture in the screen. However when I generate the
> eps file it happens that where I have constant density there are extra
> crossing "lines" in the generated eps file. Why is this happenning?  

I'll venture a guess: the lines will go away once you turn off 
antialiasing ('graphics alpha' in the "Media" settings) in your 
GhostScript viewer.  There's a known problem with the interaction of 
some versions of gnuplot, some versions of ghostscript and their 
antialiasing.  This usually shows up as strange patterns in the color 
bar, and "hair fractures" in pm3d map plots, which change position and 
occurence as you zoom in and out.  In a nutshell, it's an aliasing 
artifact brought out by the antialiasing / alpha-blending machinery.

ps and eps not good!

[Arnaldo G. <ga...@if...>]

Dear Sirs,

I departed from data points and generated densitys plots using gnuplot.
I could well see the picture in the screen. However when I generate the
eps file it happens that where I have constant density there are extra
crossing "lines" in the generated eps file. Why is this happenning?  

best regards
Arnaldo Gammal

==============================================================
|| Arnaldo Gammal                                           ||
|| Departamento de Fisica Experimental                      ||
|| Instituto de Fisica                                      ||
|| Universidade de Sao Paulo                                ||
||   P.O. Box 66318                                         ||
||   05315-970   Sao Paulo, SP  BRAZIL                      ||
||   Phone: +55 11 3091-6659 / 3091-6919                    ||
||   Fax:   +55 11 3091-6832                                || 
||   e-mail: ga...@if...                               ||
||   http://www.fep.if.usp.br/~gammal                       || 
==============================================================

Re: wxgnuplot and the screen terminal

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

> Also MOUSE_*    (one of which is a string var)

Most of them are floats.

> But yes, I agree there should be a single prefix reserved,
> or at worst a small number of them.
>
> Shall we say GPVAL_* ?
> Anything is OK with me, really.
>
> I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on,
> although the mouse variables were already in version 4.0 under
> their current names so it could break existing scripts.

I propose to call those accessing gnuplot internals by GPVAL_
Proposals:
   floats:	GPVAL_XMIN, GPVAL_YMIN, ...
   strings:	GPVAL_TERM, GPVAL_TERMOPTIONS

Those MOUSE_ should be kept -- they are results of an action (mouse 
click/hotkey), thus no gnuplot internal settings. And renames are bad 
things, anyway.

---
PM

Re: wxgnuplot and the screen terminal

[<br...@ph...>]

Ethan Merritt wrote:

> But yes, I agree there should be a single prefix reserved,
> or at worst a small number of them.
> 
> Shall we say GPVAL_* ?

One possible problem: for some values, these values will actually 
constitute an alternative to "show <some setting>", for others, it would 
expose data that was never available outside the run time of the 'plot' 
command itself, or via explicit methods (writeback/recall for range 
ends).  I.e. we may have to reserve all prefixes starting with GP to 
have an opportunity to later distinguish between GPSET_* and GPVAL_*

> I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on,
> although the mouse variables were already in version 4.0 under
> their current names so it could break existing scripts.  

So deprecate MOUSE_*, but keep them working for 4.2, or maybe the entire 
4.* series, if we ever make enough releases to form one ;-)

Re: wxgnuplot and the screen terminal

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

On Tuesday 18 April 2006 10:59 am, Hans-Bernhard Br=F6ker wrote:

> > Should it rather be "DEFAULT_TERMINAL" or something like that?
>=20
> And before we go ahead adding such intruders into the udv namespace, I=20
> think we should set a reserved prefix immediately.  So far, we've only=20
> had FIT_* names reserved for extensions to fit (and no string vars among=
=20
> those).

Also MOUSE_*    (one of which is a string var)

But yes, I agree there should be a single prefix reserved,
or at worst a small number of them.

Shall we say GPVAL_* ?
Anything is OK with me, really.

I'm also agreeable to changing MOUSE_X to GPVAL_MOUSE_X and so on,
although the mouse variables were already in version 4.0 under
their current names so it could break existing scripts. =20


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: something within 'make install'

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

On Tuesday 18 April 2006 10:56 am, Hans-Bernhard Br=F6ker wrote:
> Petr Mikulik wrote:
> > When I do "make install", then gnuplot is executing also this:
> >=20
> > Creating texinfo
> > Loading /usr/lib/emacs/21.3/i586-suse-linux/fns-21.3.1.el (source)...
> [...]
> > Isn't this something which should have been done during normal "make"?
>=20
> Of course.  And it always was.  But then someone helpfully turned that=20
> off, for no better excuse that he didn't have a running emacs installed.

Oh, I had a much better reason than that.

The current ./configure + make for the lisp files is, and has been
for a very long time, broken.  I have reported this problem
about 3 times, and other people have complained on the list as well.
Better to turn it off by default than to struggle with it every time.
=20
Having or not having a version of emacs installed is only part of
the problem.  The bigger part is that the Makefile tries to write
into various system directories to which it doesn't have access.
Saying "it works on my machine" doesn't help any.  It doesn't work
on mine, and it doesn't work for those others who complained.

If someone can fix ./configure or automake or whatever so that
building the lisp files works properly, then fine.  Otherwise it
had better remain disabled by default.

But I must have missed taking it out of "make install" in the case=20
of --disable-lisp-files.  Sorry :-)

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: How to disable/ignore "pause"?

[<br...@ph...>]

Mojca Miklavec wrote:
> I have a gnuplot.bat with
>     c:\path-to-wgnuplot.exe %*

Calling that batch file gnuplot.bat instead of wgnuplot.bat is creating 
smoke screen that hides the crucial detail: that you're doing this on MS 
Windows.  That's one single gnuplot platform where pause -1 can't detect 
that stdin was redirected (because Win32 GUI apps like wgnuplot don't 
*have* a stdin, so nothing to redirect), and therefore the usual method 
of short-circuiting pause -1 doesn't work.

> I'm still using the "old" windows terminal. Perhaps wxwidgets behave better.

IIRC it doesn't.  Wxwidgets only replaces the graph window, but not the 
text console window, nor the pause window.

> I'm not piping (I guess). 

Correctly.  To pipe, you would have to use pgnuplot, not wgnuplot.

Re: wxgnuplot and the screen terminal

[<br...@ph...>]

Ethan A Merritt wrote:
> On Sunday 16 April 2006 12:21 pm, Petr Mikulik wrote:
>  
>> BTW, "set term pop" for those things will fail if your "set term push"ed 
>> terminal is postscript, for example.
> 
> I was under the impression that 'set term push/pop' was a stack,
> but I see that I was wrong.

No.  It is a stack.  But it has a limitless bottom.  I.e. 'set term pop' 
on an empty stack yields the default terminal, simply because the 
terminal cannot be set to "NULL".

> Should it rather be "DEFAULT_TERMINAL" or something like that?

And before we go ahead adding such intruders into the udv namespace, I 
think we should set a reserved prefix immediately.  So far, we've only 
had FIT_* names reserved for extensions to fit (and no string vars among 
those).

Re: something within 'make install'

[<br...@ph...>]

Petr Mikulik wrote:
> When I do "make install", then gnuplot is executing also this:
> 
> Creating texinfo
> Loading /usr/lib/emacs/21.3/i586-suse-linux/fns-21.3.1.el (source)...
[...]
> Isn't this something which should have been done during normal "make"?

Of course.  And it always was.  But then someone helpfully turned that 
off, for no better excuse that he didn't have a running emacs installed.

Re: wxgnuplot and the screen terminal

[<br...@ph...>]

Petr Mikulik wrote:
>     term->interactive("disable q hotkey")
>     term->interactive("make mousing menus disabled")
>     term->interactive("make mousing menus enabled")
>     term->interactive("raise 5")
>     term->interactive("close")
>     term->interactive("put ruler")
>     term->interactive("change cursor")

The API entry as such may be a good idea.  Passing it a command string 
as indicated above, however, most emphatically is not.  This is an 
programming interface, not a user interface.  I won't have a secondary 
command parser stuck deep inside each of half a dozen terminal drivers. 
  The mess with all those term->option() parsers is quite bad enough 
already --- let's not make that mistake again.

If what the call does can't be parametrized into a usable C datatype (a 
couple of enums, one or two optional arguments, that kind of thing), 
then this is not API design --- it's an attempt to get away without 
actually doing any design.

Problem with

[Kerstin B. <ker...@t-...>]

Hi,

I've running gnuplot 4.1on a Mac 10.4.6 with aqua v1.0.b2 
Terminal type set to 'aqua'.
Now I've trying to plot some 2D datafile.

This line run's fine
gnuplot> plot "data.csv" with line


but this not
gnuplot> plot "data.csv" with points
2006-04-18 00:24:37.483 gnuplot[431] ***
 -[AQTAdapter setLinestyleSolid]: selector not recognized [self 
= 0x1503fa0]
2006-04-18 00:24:37.485 gnuplot[431] ***
 Uncaught exception: <NSInvalidArgumentException> *** -
[AQTAdapter setLinestyleSolid]: selector not recognized [self = 0x1503fa0]
Trace/BPT trap

but I don't find any solution for my problem.
Thanks for your help

Greetings Kerstin

Re: splot and surface visibility

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

On Monday 17 April 2006 04:10 pm, Mojca Miklavec wrote:
> 
> Consider the following two plots:
> 
> splot x*y with pm3d, 10*sin(x) with pm3d
> 
> The two surfaces are simply plotted one over another without
> considering proper 3D placement and visibility.

> Will there be a remedy for that anytime in the near future?

SourceForge patch #1077726

	have fun


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

splot and surface visibility

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

Hello,

there's a serious problem when drawing 2D surfaces in 3D space.
Consider the following two plots:

set palette gray
splot 10*sin(x) with pm3d, x*y with pm3d
splot x*y with pm3d, 10*sin(x) with pm3d

The two surfaces are simply plotted one over another without
considering proper 3D placement and visibility. (The two plots should
be identical, but they aren't.) Will there be a remedy for that
anytime in the near future? (Fixing that would probably require
rewriting quite a lot of code.)

Thanks a lot,
    Mojca

Re: How to disable/ignore "pause"?

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

Ethan Merritt wrote:

> Off-the-wall suggestions, since I don't really understand how
> your problem is created.
> 
> 1) Don't put any pause statements in your automated scripts to begin with
> 
> 2) sed -e 's/pause -1//' < script | gnuplot
> 
> 3) gnuplot script < /bin/true

Hans said the other day to try something like

gnuplot all.dem < /dev/null

Could try that.

Dan

Problem with "plot x with points"

[Kerstin B. <ker...@t-...>]

Hi,

I've running gnuplot 4.1on a Mac 10.4.6 with aqua v1.0.b2 Terminal  
type set to 'aqua'.
Now I've trying to plot some 2D datafile.

This line run's fine
gnuplot> plot "data.csv" with line


but this not
gnuplot> plot "data.csv" with points
2006-04-18 00:24:37.483 gnuplot[431] *** -[AQTAdapter  
setLinestyleSolid]: selector not recognized [self = 0x1503fa0]
2006-04-18 00:24:37.485 gnuplot[431] *** Uncaught exception:  
<NSInvalidArgumentException> *** -[AQTAdapter setLinestyleSolid]:  
selector not recognized [self = 0x1503fa0]
Trace/BPT trap

but I don't find any solution for my problem.
Thanks for your help

Greetings Kerstin

Re: How to disable/ignore "pause"?

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

On 4/17/06, Ethan Merritt wrote:
> On Monday 17 April 2006 02:05 pm, Mojca Miklavec wrote:
> > I'm sorry for a stupid question (probably not the most appropriate for
> > this list, but I didn't find the answer yet): how can I ignore
> > "pause"? I would like to call gnuplot from an external program (with
> > "set terminal whatever", has to produce a couple of graphics and then
> > exit quitely) and "I can't afford to hire a robot" to keep pushing
> > "enter" on pauses triggered with "pause -1"? Pause is good for
> > interactive terminals, but not when writing images into a file.
>
> This is a strange question, because "pause -1" should return
> immediately if the input is from a script.
> How, exactly, are you feeding your commands to gnuplot?

I have a gnuplot.bat with
    c:\path-to-wgnuplot.exe %*
and I call it with
    gnuplot somescript.plt
where somescript.plt might be something like
    set terminal context
    set output "somefile.tex"
    plot sin(x)
    pause -1
    plot cos(x)
or perhaps
    load "somefile.dem" # any demo file from the distribution

Then a pause windows pops up and wants me to press Enter in order to procee=
d.

I'm still using the "old" windows terminal. Perhaps wxwidgets behave better=
.

> And if you are piping the commands from an external program,
> why is it listening to the keyboard even if you *were* to
> hire a robot key-presser?

I'm not piping (I guess). I'm only calling "gnuplot[.bat]
somescript.plt" from TeX.

> Off-the-wall suggestions, since I don't really understand how
> your problem is created.
>
> 1) Don't put any pause statements in your automated scripts to begin with

Sure, but if I want to test demo scripts out of the box ... I won't
write any pause statements in my scripts (although I still might want
to use the same code for testing the plots where I need pauses and for
producing high quality plots where I would want them to be ignored).

> 2) sed -e 's/pause -1//' < script | gnuplot
>
> 3) gnuplot script < /bin/true

But that can't be used under windows (where I'm experiencing the "problem")=
.
I don't have access to any linux box at the moment, but well ... I can
try what happens there.

GhostScript has -dBATCH -dNOPAUSE switches for the same purpose for example=
.

Thanks,
    Mojca

Re: How to disable/ignore "pause"?

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

On Monday 17 April 2006 02:05 pm, Mojca Miklavec wrote:
> I'm sorry for a stupid question (probably not the most appropriate for
> this list, but I didn't find the answer yet): how can I ignore
> "pause"? I would like to call gnuplot from an external program (with
> "set terminal whatever", has to produce a couple of graphics and then
> exit quitely) and "I can't afford to hire a robot" to keep pushing
> "enter" on pauses triggered with "pause -1"? Pause is good for
> interactive terminals, but not when writing images into a file.

This is a strange question, because "pause -1" should return
immediately if the input is from a script.
How, exactly, are you feeding your commands to gnuplot?
And if you are piping the commands from an external program,
why is it listening to the keyboard even if you *were* to 
hire a robot key-presser?



Off-the-wall suggestions, since I don't really understand how
your problem is created.

1) Don't put any pause statements in your automated scripts to begin with

2) sed -e 's/pause -1//' < script | gnuplot

3) gnuplot script < /bin/true


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

How to disable/ignore "pause"?

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

I'm sorry for a stupid question (probably not the most appropriate for
this list, but I didn't find the answer yet): how can I ignore
"pause"? I would like to call gnuplot from an external program (with
"set terminal whatever", has to produce a couple of graphics and then
exit quitely) and "I can't afford to hire a robot" to keep pushing
"enter" on pauses triggered with "pause -1"? Pause is good for
interactive terminals, but not when writing images into a file.

I would appreciate any hints,
    Mojca

Re: What's left for a 4.2 release? [drivers]

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

On Monday 17 April 2006 09:10 am, Per Persson wrote:
> 
> > If I'm reading that right, it means that
> > 	plot <foo> with boxes lt 1 fillstyle pattern 2
> > and
> > 	plot <foo> with boxes lt 2 fillstyle pattern 1
> > produce the same output, which is a surprising result.
> 
> In the above examples, in AquaTerm I  
> get boxes with red outline (lt 1) and blue fill (pattern 2) in the  
> first case and green outline (lt 2) and green fill (pattern 1).

That's a surprising result also.
All other terminals would draw the outline and the fill in the
same color, with the fill modulated either by an actual pattern
or by the fill density.

It is possible to mix different outline (border) colors and
fill colors, but in order to do so the syntax is:
	fillstyle {pattern <n> | solid <density>} bordercolor <lt>

> Wouldn't cycling through colours give a better visual appearance than  
> shades of the outline color (effectively mapping "pattern x" to  
> "solid <y>")?

Cycling through colors is what "fillstyle solid" already does.
So if that is the effect you want, it's easy to achieve.
As you pointed out, "fillstyle pattern" is mostly intended for
monochrome plots.  But if it is to be implemented in color, to me it
makes sense that it do something different from "fillstyle solid".

> OK, I've fixed that. Before I commit anything though, when are
> TC_DEFAULT, TC_LINESTYLE, and TC_Z used? I couldn't find any clear  
> docs on that.

These values are used by the core code, but are never passed to
the terminal driver routines.  The are essentially place-holders
that indicate how the color will eventually be calculated before
passing it to term->set_color().

TC_DEFAULT is, or will be, used by the core routines to allow
individual plot elements to jointly adhere to a global style setting.
So far it is only used by the brand new "set object" code, but
my intent is to add similar processing to "set arrow", "set label",
and so on.  The idea is that if an individual label, say, is marked
TC_DEFAULT then its color will be taken from a global value set by
"set style label <default_color_spec>".  If you change this global
default, then all the corresponding labels change color at the same
time. Otherwise you would have to change them one by one.

TC_LINESTYLE is very similar to this, and perhaps TC_DEFAULT
should be collapsed into a subset or special case of this one.
It tells the core routines that the object properties (color in
this case, but it could be pointstyle or something else) is to
be taken from line *style* <n> rather than from line *type* <n>.

TC_Z is used during parsing to indicate that the color will come
from the object's Z value. This is the default "palette" coloring
option.  The color is not known yet at the time the object 
properties are parsed, because it will depend on the eventual
Z value.


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

Re: wxt terminal - questions

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

On Monday 17 April 2006 09:11 am, Timoth=E9e Lecomte wrote:

> I have implemented the behaviour described above : using the locale to
> determine the charset.=20


> I just added one other detail : when using the=20
> Symbol font, the terminal will assume you're using iso_8859_1, because
> you'll have to use non-utf8 characters.

What is "the" Symbol font, in this case? =20

The Adobe "Symbol" font, which is what most of the other drivers find by
default, is not an iso8859-1 encoding.  It is "Adobe-specific", which
causes headaches with libgd and libfreetype. =20

The Microsoft "symbol.ttf" font, on the other hand, claims to be encoding
"microsoft-symbol".

The symbol font entries in the screenshot I sent yesterday were
actual UTF-8 encoded characters.

I am uncertain how all of this will play out in practice when I'm
typing from the terminal, or running a gnuplot script.  But I guess
we'll find out.


> For example, in the demo, the=20
> integral character in \362, which is not a valid utf8 character. If the
> terminal tries to read the string in utf8, it would fail here and would
> not draw this character.

Ah. I see. So you're thinking about character data entered as octal
constants, as in charset.dem.   OK, I suppose if the user intends some
particular encoding for octal data, he should give an explicit=20
"set encoding <foo>".  Failing that, iso8859-1   (or 8859-15) is as
good a default as any.



=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: wxt terminal - questions

[<tim...@en...>]

> On Sunday 16 April 2006 08:35 pm, Timoth=C3=A9e Lecomte wrote:
>
>> I can implement the following :
>> - if the user has used "set encoding ..." where "..." is something
>> different from "default", the terminal converts from this encoding to
>> utf8
>> - otherwise, use the 'locale' to determine the input charset, and assu=
me
>> this is the input encoding for the conversion to utf8.
>
> Or at the least, if 'locale' reports any flavor of utf8 then do not do
> any conversion.
>
>> However, I am still not clear on one thing :
>> If you launch the demo 'charset.dem' :
>> - with the current code, the wxt terminal will show all characters as
>> iso8859-1 encoded.
>
> Correct.
>
>> - with the new code falling back to the 'locale' charset, and if your
>> locale charset is UTF-8, you won't see the last four lines [upper bit
>> set]
>>
>> At the same time, the X11 terminal will show these lines !!! So my
>> question is : what is the X11 terminal doing ??
>
> The X terminal chooses an iso-8859-1 font by default unless you tell
> it explicitly to use a multibyte font.  If you say
> 	set term x11 font "mbfont:verdana"
> then as you predict, the last four lines of charset.dem are blank.
> However, in this mode it handles utf-8 characters properly.

Ok, I understand.

I have implemented the behaviour described above : using the locale to
determine the charset. I just added one other detail : when using the
Symbol font, the terminal will assume you're using iso_8859_1, because
you'll have to use non-utf8 characters. For example, in the demo, the
integral character in \362, which is not a valid utf8 character. If the
terminal tries to read the string in utf8, it would fail here and would
not draw this character.

>
> I should add a "utf8.dem" as well.

Good idea !

Re: What's left for a 4.2 release? [drivers]

[Per P. <per...@ma...>]

On Apr 17, 2006, at 00:51, Ethan A Merritt wrote:

> On Sunday 16 April 2006 03:13 pm, Per Persson wrote:
>>>
>>> Several other terminals implement colored fill patterns as differing
>>> intensity.  E.g. (from emf.trm):
>>>         case FS_PATTERN: /* pattern fill implemented as partial
>>> density */
>>>                 fillpar *= 12;
>>> 		/* Fall through to ...*/
>>>         case FS_SOLID: /* solid fill */
>>>                 if (fillpar >= 0 && fillpar < 100) {
>>>                     double density = (double)fillpar / 100.;
>>
>> That's how its done in aqua too, but for B/W patterns make sense.
>
> Except that so far as I can tell from the code, aqua is cycling
> through different colors rather than cycling the same color
> through different fill intensities.  If I'm reading that
> right, it means that
> 	plot <foo> with boxes lt 1 fillstyle pattern 2
> and
> 	plot <foo> with boxes lt 2 fillstyle pattern 1
> produce the same output, which is a surprising result.

Whoops, sorry I mixed it up with the "solid <density>" option.
Still, I'm a little confused. In the above examples, in AquaTerm I  
get boxes with red outline (lt 1) and blue fill (pattern 2) in the  
first case and green outline (lt 2) and green fill (pattern 1).
Wouldn't cycling through colours give a better visual appearance than  
shades of the outline color (effectively mapping "pattern x" to  
"solid <y>")?


>
>>> It looks like  AQUA_set_color is missing TC_LT from
>>> its case statement, for example.  That is probably a trivial fix,  
>>> but
>>> there may be other places that bits are missing.
>>
>> Like I said before, I haven't paid close attention lately and I
>> probably have missed adding upport for new features.
>> Pointers to docs/examples?

OK, I've fixed that. Before I commit anything though, when are
TC_DEFAULT, TC_LINESTYLE, and TC_Z used? I couldn't find any clear  
docs on that.

/Per

Re: wxt terminal - questions

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

On Sunday 16 April 2006 08:35 pm, Timoth=C3=A9e Lecomte wrote:

> I can implement the following :
> - if the user has used "set encoding ..." where "..." is something
> different from "default", the terminal converts from this encoding to utf8
> - otherwise, use the 'locale' to determine the input charset, and assume
> this is the input encoding for the conversion to utf8.

Or at the least, if 'locale' reports any flavor of utf8 then do not do
any conversion.

> However, I am still not clear on one thing :
> If you launch the demo 'charset.dem' :
> - with the current code, the wxt terminal will show all characters as
> iso8859-1 encoded.

Correct.

> - with the new code falling back to the 'locale' charset, and if your
> locale charset is UTF-8, you won't see the last four lines [upper bit set]
>=20
> At the same time, the X11 terminal will show these lines !!! So my
> question is : what is the X11 terminal doing ??

The X terminal chooses an iso-8859-1 font by default unless you tell
it explicitly to use a multibyte font.  If you say
	set term x11 font "mbfont:verdana"
then as you predict, the last four lines of charset.dem are blank.
However, in this mode it handles utf-8 characters properly.

I should add a "utf8.dem" as well.
Here's a quick version, and a screen shot from=20

    set term x11 font "mbfont:sazanami mincho,vera,20"
    load 'utf8.dem'

> Chris has already answered, and I can only confirm. Cairo has definetely
> been designed with alpha transparency in mind.

Great.  But that's not a project for 4.2.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: wxt terminal - questions

[<tim...@en...>]

> Two questions
>
> (1)
> I've been poking about in the code, and so far as I can
> see the code assumes that character strings passed to Pango
> will be interpreted as UTF-8.  E.g. the following comment:
>
>   /* pango needs a string encoded in utf-8. We use g_convert from glib.
>    * gp_cairo_get_encoding() gives the encoding set via 'set enconding'
>    * memory allocated for enhanced_text_utf8 is freed at the end of
>    * gp_cairo_enhanced_flush */
>   string_utf8 =3D g_convert(string, -1, "UTF-8",
> gp_cairo_get_encoding(plot), NULL, NULL, NULL);
>
> But this doesn't happen. My machines are normally set to a UTF-8 locale=
,
> and all characters I type into gnuplot are UTF-8 encoded.
> But the multibyte characters are mangled when displayed in the wxt plot
> window.
> The same strings are properly displayed in x11 (when set to multibyte
> mode)
> and in gd (which by default uses UTF-8).  So I know they are correctly
> stored inside gnuplot. What's going wrong in wxt?

Thanks for digging on this side.

Let me explain how it works currently :
- if the user has used "set encoding ..." where "..." is something
different from "default", the terminal converts from this encoding to utf=
8
- otherwise, it falls back to iso8859-1. That's why the terminal doesn't
show your multibyte-utf8 characters.

I can implement the following :
- if the user has used "set encoding ..." where "..." is something
different from "default", the terminal converts from this encoding to utf=
8
- otherwise, use the 'locale' to determine the input charset, and assume
this is the input encoding for the conversion to utf8.

However, I am still not clear on one thing :
If you launch the demo 'charset.dem' :
- with the current code, the wxt terminal will show all characters as
iso8859-1 encoded.
- with the new code falling back to the 'locale' charset, and if your
locale charset is UTF-8, you won't see the last four lines, as the utf8
specification doesn't allow 8 bits characters where the upper bit is 1
(see http://en.wikipedia.org/wiki/UTF-8 for details on this specification=
)

At the same time, the X11 terminal will show these lines !!! So my
question is : what is the X11 terminal doing ?? Ethan, can you check on
your box ?


>
> (2)
> I happened across a page of sample plots from another plotting program,
> and was struck by how useful transparency can be in some cases.
> In particular in the case of overlapping histograms
>    http://sourceforge.net/project/screenshots.php?group_id=3D15494
> I think it would be possible to support this in gd.trm and svg.trm,
> but I'm not sure about any other terminals.   Do the Cairo graphics
> primitives support an alpha channel, so that wxt.trm could use this als=
o?
>

Chris has already answered, and I can only confirm. Cairo has definetely
been designed with alpha transparency in mind.


Regards,

Timoth=E9e