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

Pseudodata for Vector Fields [Patch]

[Peter D. <pc...@wi...>]

Direction fields come in handy for first order ODEs; some people have
expressed frustration that they're not directly supported.*

The attached patch produces two dimensions of data from the pseudofile
operator when df_current_plot->plot_style == VECTOR, allowing you to
do things like:**

    set isosamples 20
    set samples 20
    l = 0.05
    f(t,y) = 2*y + 4 - t
    g(c,x) = -7/4. + 1/2.*x + c*exp(2*x)
    plot [0:2][-4:0] '+' using 1:2:(l):(l*f($1,$2)) \
         with vectors title "dy/dt - 2y = 4 - t", \
         g(0,x) title "g(c, t) = -7/4 + 1/2t + ce^2t, c = 0", \
         g(.1,x), g(.2,x), g(.3,x), g(-.1,x), g(-.2,x), g(-.3,x)

Here's the sourceforge tracker:

    http://sourceforge.net/tracker/index.php?func=detail&aid=1872528&group_id=2055&atid=302055

-----------
* http://thread.gmane.org/gmane.comp.graphics.gnuplot.devel/5805/focus=5814
** http://wikisophia.org/wiki/User:Danenberg#Direction_field

Re: clipping filled polygons

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

On Friday 11 January 2008 05:47, Gerard Cats wrote:
> 
> I encountered a problem when I tried to fill a closed polygon which 
> extended beyond the xrange, yrange. This is conform the documentation, 
> which says:
> "Zoom of a filled curve drawn from a datafile may produce empty or 
> incorrect area because gnuplot is clipping points and lines, and not areas."
> I use Version 4.2 patchlevel 2.
> I guess that it is desirable to remove this "feature" from gnuplot.

I think you are correct that it would be worth re-visiting the generic
filled-area code in gnuplot.  I suspect that the existing code was written
in terms of clipping points and lines just because those clipping routines
were already implemented.  But yes, the code in graphics.c 
 plot_filledcurves()
 finish_filled_curve()
 fill_missing_corners()
and maybe also
 plot_betweencurves()

is quite tangled, and could probably be entirely replaced by a polygon-
clipping algorithm such as you suggest below.  As a side benefit it would
reduce the size of the code by ~500 lines.

That would be a nice project for someone.  


	Ethan

> A well-known  algorithm to clip a filled polygon is by Sutherland and 
> Hodgman. Some very ingenious implementations exist, e.g.
> http://www.codeguru.com/Cpp/misc/misc/graphics/article.php/c8965/, but I 
> wrote a simple one, in Perl, with which I was able to clip my polygons 
> myself, before sending them to gnuplot. The advantage of my code is that 
> it is simple and very fast, but its disadvantage is that it needs to 
> store both the input and the output polygons, so it needs more memory 
> than more sophisticated solutions. Yet, with current memory prices, this 
> should not really be a problem anymore. My implementation is 
> specifically to clip to rectangular areas.
> 
> I include my Perl program. Perhaps a gnuplot code guru is interested to 
> implement Sutherland/Hodgman clipping; if so, (s)he may find it useful 
> to have a look at my Perl program.
> I myself cannot write C (easily), but I think conversion of Perl to C 
> code will not be a great challenge. The real challenge lies in adjusting 
> the code to gnuplot data structures.
> 

-- 
Ethan A Merritt

clipping filled polygons

[Gerard C. <ca...@kn...>]

LS,
I encountered a problem when I tried to fill a closed polygon which 
extended beyond the xrange, yrange. This is conform the documentation, 
which says:
"Zoom of a filled curve drawn from a datafile may produce empty or 
incorrect area because gnuplot is clipping points and lines, and not areas."
I use Version 4.2 patchlevel 2.
I guess that it is desirable to remove this "feature" from gnuplot.

A well-known  algorithm to clip a filled polygon is by Sutherland and 
Hodgman. Some very ingenious implementations exist, e.g.
http://www.codeguru.com/Cpp/misc/misc/graphics/article.php/c8965/, but I 
wrote a simple one, in Perl, with which I was able to clip my polygons 
myself, before sending them to gnuplot. The advantage of my code is that 
it is simple and very fast, but its disadvantage is that it needs to 
store both the input and the output polygons, so it needs more memory 
than more sophisticated solutions. Yet, with current memory prices, this 
should not really be a problem anymore. My implementation is 
specifically to clip to rectangular areas.

I include my Perl program. Perhaps a gnuplot code guru is interested to 
implement Sutherland/Hodgman clipping; if so, (s)he may find it useful 
to have a look at my Perl program.
I myself cannot write C (easily), but I think conversion of Perl to C 
code will not be a great challenge. The real challenge lies in adjusting 
the code to gnuplot data structures.

-- 
<PRE>
R G   s
 e ard
G R

Gerard Cats, KNMI, PO Box 201, 3730 AE De Bilt, The Netherlands.
Tel. +31302206442, Fax +31302211371,  e-mail ca...@kn...
URL: http://www.knmi.nl/~cats
</PRE>

Re: cp1254 support for emf term

[Allin C. <cot...@wf...>]

On Thu, 10 Jan 2008, Ethan Merritt wrote:

> On Thursday 10 January 2008 11:00, Allin Cottrell wrote:
> > 
> > If she's using an output mode that employs UTF-8 internally, what 
> > happens if she does "set encoding locale"?  Do the UTF-8 terminals 
> > then automagically get a correctly recoded version of the CP1254 
> > text? 
> 
> To the best of my knowledge, none of the gnuplot terminals do
> any re-encoding of the text provided by the user.  The purpose
> of the "set encoding" command is simply to tell the output device
> what encoding the text is already in.

No, see the mechanism in gp_cairo.c, which uses either the 
user-specified encoding, or g_get_charset() by default, to 
determine the source encoding, then uses g_convert() to convert to 
UTF-8 for use with pango.  (To answer my own question!)

Allin Cottrell

Re: cp1254 support for emf term

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

On Thursday 10 January 2008 11:07, Mojca Miklavec wrote:
> >  
> Only: I have always found the built in encoding support of gnuplot a
> bit problematic so far.
> 
> In the case of Postscript:
> - it's almost a science fiction to figure out how to change a font
> - most fonts miss two characters needed for Slovenian

Heh. This is peanuts compared to the difficulty of using Japanese fonts.

> (not worth mentioning that OpenType and TrueType probably don't work)

Not true.  If anything, they are more likely to work than Adobe fonts
because they are more likely to contain Unicode mappings.  But unless
you embed the font in the document, you are at the mercy of whatever
the printer/viewer is configured to handle.
 
> But if it is of any use, I can send some patches (not before the end of month).

I'm not pushing for any patches in particular.  But I think gnuplot could
do better with internationalization, so I am happy to accept patches that
solve problems with internationalization.  As you say, internationalizing
PostScript output is close to hopeless. In fact it's completely broken in
4.2, as is svg. The situation in the CVS version is better, but still far
from perfect.

-- 
Ethan A Merritt

Re: cp1254 support for emf term

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

On Thursday 10 January 2008 11:00, Allin Cottrell wrote:
> 
> If she's using an output mode that employs UTF-8 internally, what 
> happens if she does "set encoding locale"?  Do the UTF-8 terminals 
> then automagically get a correctly recoded version of the CP1254 
> text? 

To the best of my knowledge, none of the gnuplot terminals do
any re-encoding of the text provided by the user.  The purpose
of the "set encoding" command is simply to tell the output device
what encoding the text is already in.

-- 
Ethan A Merritt

Re: cp1254 support for emf term

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

On Jan 10, 2008 6:39 PM, Ethan Merritt wrote:
>
> Of course it it is best to consult with someone who actually uses the
> encoding.  Are characters present in cp1254 but not in latin5 actually
> important to Turkish text?  Or is it just a case of MicroSoft fiddling
> around in contradiction to a standard used by the rest of the world?

I can only tell about the case of central european encoding: there are
two, cp1250 and iso-8859-2. They cover the same set of characters
(more or less), but the three characters we need are at different
locations, so it's important to be able to handle both.

Only: I have always found the built in encoding support of gnuplot a
bit problematic so far.

In the case of Postscript:
- it's almost a science fiction to figure out how to change a font
(not worth mentioning that OpenType and TrueType probably don't work)
- most fonts miss two characters needed for Slovenian
In the case of windows:
- lack of developers to fix the issue (Slovonian characters don't work there)
In the case of LaTeX:
- glad that nobody came to the idea of adding encoding support to the
latex terminal yet (what comes in, goes out, and that's just perfect
since one probably uses the same editor for gnuplot sources and LaTeX
documents)

But if it is of any use, I can send some patches (not before the end of month).

Mojca

Re: cp1254 support for emf term

[Allin C. <cot...@wf...>]

On Thu, 10 Jan 2008, Ethan Merritt wrote:

> On Wednesday 09 January 2008 17:28, Allin Cottrell wrote:
> > 
> > What I'm suggesting here is that "set encoding CP1254" is a
> > setting that, quite defensibly, could be acted upon only by emf term.
> 
> Could you explain your logic a little bit further?
> 
> It would seem to me that if the user needs a particular encoding
> at all, presumably because the input data or scripts use that
> encoding, then *all* output modes need to match.  Why would emf
> be a special case?  If it's a matter of running under Windows,
> wouldn't support for win.trm be at least as important?

You're right, I had forgotten about win.trm, that should be 
handled too.  

I'm thinking of the situation where, say, somebody is using 
gnuplot on a Windows PC in Turkey, using CP1254, and wants 
accented characters in a graph.  The most likely output modes are, 
I suppose, win and emf.  If she wants PostScript output, she could 
try specifying iso8859-9 and actual text should come through OK.

If she's using an output mode that employs UTF-8 internally, what 
happens if she does "set encoding locale"?  Do the UTF-8 terminals 
then automagically get a correctly recoded version of the CP1254 
text? 

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: cp1254 support for emf term

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

On Wednesday 09 January 2008 17:28, Allin Cottrell wrote:
> 
> What I'm suggesting here is that "set encoding CP1254" is a
> setting that, quite defensibly, could be acted upon only by emf term.

Could you explain your logic a little bit further?

It would seem to me that if the user needs a particular encoding
at all, presumably because the input data or scripts use that
encoding, then *all* output modes need to match.  Why would emf
be a special case?  If it's a matter of running under Windows,
wouldn't support for win.trm be at least as important?
 

-- 
Ethan A Merritt

Re: cp1254 support for emf term

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

On Wednesday 09 January 2008 16:06, Mojca Miklavec wrote:

> If these encodings are to be added: why not adding "all" the cp125X
> and iso-8859-X encodings (I mean the latin ones, Thai or Arabic makes
> no sense of course)?
> 
> (I can donate some code if there's no hurry, I have some scripts which
> already do the majority of work before anyone starts adding those
> names manually.)

I've been accepting all contributed encoding patches.
I figure if anyone cares enough to take the time to prepare such
a patch, it's an indication that there are real users out there who
want it.

Of course it it is best to consult with someone who actually uses the
encoding.  Are characters present in cp1254 but not in latin5 actually
important to Turkish text?  Or is it just a case of MicroSoft fiddling
around in contradiction to a standard used by the rest of the world?

-- 
Ethan A Merritt

Re: updates to links

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

Hello

--- Tim Hoffmann <tim...@un...> wrote:
> Hello,
> 
> I found that the links page is not up-to-date. Below is a list of errors 
> / changes. When possible I gave new links.
> front-ends
> [N/A] Xgfe
This should be change to Qgfe.  
http://www.xm1math.net/qgfe/

Regards

Tatsuro



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

Re: cp1254 support for emf term

[Allin C. <cot...@wf...>]

On Wed, 9 Jan 2008, Ethan Merritt wrote:

> I don't think that works.
> According to the encoding tables on Wikipedia, CP1254 uses
> the encoding points 8x and 9x (x = anything from 0 to F) whereas
> iso8859-9 leaves these undefined.   

Yes, CP1254 and iso8859-9 are not identical; the former defines 
certain characters that are left undefined in the latter.

But in the context of emf.term, where we're mapping from these 
encodings onto Microsoft's TURKISH_CHARSET macro, I suppose it's
CP1254 that's "correct" and iso8859-9 that's just an 
approximation.

> I think if you want to treat these two encodings jointly, you 
> need to expand the glyph tables in .../term/PostScript/8859-9.ps 
> to include the ones used by CP1254.

Yes, but I'm assuming (perhaps unwisely) that people handling 
PostScript will be using ISO encodings rather than MS codepage 
stuff.  I'm not sure it's worthwhile to put CP encodings into the 
prologues in term/PostScript, though if somebody wants to do it I 
won't object.

To clarify just a little more: I think it's implicit that just 
because gnuplot recognizes "set encoding foo" as a valid command, 
that doesn't mean that every terminal will make any sense of 
encoding foo (although, within reason, the more terminal types 
that do so, the better).  What I'm suggesting here is that "set 
encoding CP1254" is a setting that, quite defensibly, could be 
acted upon only by emf term.

Allin Cottrell

Re: cp1254 support for emf term

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

T24gSmFuIDEwLCAyMDA4IDEyOjIyIEFNLCBFdGhhbiBNZXJyaXR0IHdyb3RlOgo+IE9uIFdlZG5l
c2RheSAwOSBKYW51YXJ5IDIwMDggMTE6NTIsIEFsbGluIENvdHRyZWxsIHdyb3RlOgo+ID4gTm90
IHRoZSBoaWdoZXN0IHByaW9yaXR5LCBidXQgdGhlIGF0dGFjaGVkIHBhdGNoZXR0ZSBhZGRzCj4g
PiBzdXBwb3J0IGZvciBDUDEyNTQgKE1TIFR1cmtpc2ggY29kZXBhZ2UpLiAgSSd2ZSBhY3R1YWxs
eSBhY3RpdmF0ZWQKPiA+IHRoaXMgb25seSBmb3IgdGhlIEVNRiB0ZXJtaW5hbCwgd2hlcmUgSSB0
aGluayBpdCdzIGxpa2VseSB0byBiZSBvZgo+ID4gbW9zdCB1c2UuCj4KPiBJIGRvbid0IHRoaW5r
IHRoYXQgd29ya3MuCj4gQWNjb3JkaW5nIHRvIHRoZSBlbmNvZGluZyB0YWJsZXMgb24gV2lraXBl
ZGlhLCBDUDEyNTQgdXNlcwo+IHRoZSBlbmNvZGluZyBwb2ludHMgOHggYW5kIDl4ICh4ID0gYW55
dGhpbmcgZnJvbSAwIHRvIEYpIHdoZXJlYXMKPiBpc284ODU5LTkgbGVhdmVzIHRoZXNlIHVuZGVm
aW5lZC4KPgo+IFNvIGZhciBhcyBJIGNhbiBzZWUsIENQMTI1NCBjb250YWlucyBhdCBsZWFzdCBo
YWxmIGEgZG96ZW4gY2hhcmFjdGVycwo+IHRoYXQgYXJlIG5vdCBwcmVzZW50IGluIGlzbzg4NTkt
OSBpbmNsdWRpbmcgxaAoUyBjYXJvbikgxaEocyBjYXJvbikKPiDFuChZIGRpZXJlc2lzKSDFkihP
RSBsaWdhdHVyZSkgxZMob2UgbGlnYXR1cmUpLgo+Cj4gSSB0aGluayBpZiB5b3Ugd2FudCB0byB0
cmVhdCB0aGVzZSB0d28gZW5jb2RpbmdzIGpvaW50bHksCj4geW91IG5lZWQgdG8gZXhwYW5kIHRo
ZSBnbHlwaCB0YWJsZXMgaW4KPiAuLi4vdGVybS9Qb3N0U2NyaXB0Lzg4NTktOS5wcwo+IHRvIGlu
Y2x1ZGUgdGhlIG9uZXMgdXNlZCBieSBDUDEyNTQuCgpJZiB0aGVzZSBlbmNvZGluZ3MgYXJlIHRv
IGJlIGFkZGVkOiB3aHkgbm90IGFkZGluZyAiYWxsIiB0aGUgY3AxMjVYCmFuZCBpc28tODg1OS1Y
IGVuY29kaW5ncyAoSSBtZWFuIHRoZSBsYXRpbiBvbmVzLCBUaGFpIG9yIEFyYWJpYyBtYWtlcwpu
byBzZW5zZSBvZiBjb3Vyc2UpPwoKKEkgY2FuIGRvbmF0ZSBzb21lIGNvZGUgaWYgdGhlcmUncyBu
byBodXJyeSwgSSBoYXZlIHNvbWUgc2NyaXB0cyB3aGljaAphbHJlYWR5IGRvIHRoZSBtYWpvcml0
eSBvZiB3b3JrIGJlZm9yZSBhbnlvbmUgc3RhcnRzIGFkZGluZyB0aG9zZQpuYW1lcyBtYW51YWxs
eS4pCgpNb2pjYQo=

Re: cp1254 support for emf term

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

On Wednesday 09 January 2008 11:52, Allin Cottrell wrote:
> Not the highest priority, but the attached patchette adds=20
> support for CP1254 (MS Turkish codepage).  I've actually activated=20
> this only for the EMF terminal, where I think it's likely to be of=20
> most use.

I don't think that works.
According to the encoding tables on Wikipedia, CP1254 uses
the encoding points 8x and 9x (x =3D anything from 0 to F) whereas
iso8859-9 leaves these undefined.  =20

So far as I can see, CP1254 contains at least half a dozen characters
that are not present in iso8859-9 including =C5=A0(S caron) =C5=A1(s caron)
=C5=B8(Y dieresis) =C5=92(OE ligature) =C5=93(oe ligature).

I think if you want to treat these two encodings jointly,=20
you need to expand the glyph tables in
=2E../term/PostScript/8859-9.ps
to include the ones used by CP1254.



=2D-=20
Ethan A Merritt=20

Re: default terminal?

[Allin C. <cot...@wf...>]

On Wed, 9 Jan 2008, Ethan Merritt wrote:

> On Wednesday 09 January 2008, Allin Cottrell wrote:
> > Quick question: is there a way to determine non-interactively what
> > the default gnuplot terminal is?
> 
> On a linux system the default will be wxt if wxt is present at all.
> So you could do
>    ldd `which gnuplot` | grep wx
> If you get a non-empty result, then the default is wxt.
> 
> For that matter, if you are sitting at a terminal you could say:
> 
>   echo "show term" | gnuplot '-'
> 
> But I think this might not work from a script.

Thanks.  I wasn't very clear: the real task here is to find the 
information programmatically, for gnuplot running on somebody 
else's computer.  My experimentation, it seems that

echo "print GNUTERM" | gnuplot

does the job, at least for recent gnuplot.

Allin Cottrell

Re: default terminal?

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

On Wednesday 09 January 2008, Allin Cottrell wrote:
> Quick question: is there a way to determine non-interactively what
> the default gnuplot terminal is?
>
> I'd like to be able to tell, for example, whether an "unknown"
> instance of gnuplot on X11 defaults to x11 or wxt.

On a linux system the default will be wxt if wxt is present at all.
So you could do
   ldd `which gnuplot` | grep wx
If you get a non-empty result, then the default is wxt.

For that matter, if you are sitting at a terminal you could say:

  echo "show term" | gnuplot '-'

But I think this might not work from a script.


You could, of course. force the default to whichever you like using
the environmental variable GNUTERM.



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

default terminal?

[Allin C. <cot...@wf...>]

Quick question: is there a way to determine non-interactively what 
the default gnuplot terminal is?

I'd like to be able to tell, for example, whether an "unknown" 
instance of gnuplot on X11 defaults to x11 or wxt.

Thanks!

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

cp1254 support for emf term

[Allin C. <cot...@wf...>]

Not the highest priority, but the attached patchette adds 
support for CP1254 (MS Turkish codepage).  I've actually activated 
this only for the EMF terminal, where I think it's likely to be of 
most use.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: pdf term (pdflib) and "set encoding"

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

On Monday 07 January 2008 09:50, Allin Cottrell wrote:
> Here's a small patch for the pdflib-based pdf terminal, similar to 
> the one I submitted for emf term.
> 
> Again, the idea is to respect the user's choice of encoding if 
> possible. It may be that not all versions of pdflib-lite support 
> the iso-8859-X encodings, but recent versions do.  And I think the 
> fallback mechanism is such this change won't break anything that 
> works at present.

Works for me.
Added to CVS both for 4.2 and 4.3
 

-- 
Ethan A Merritt

Re: rename TERM_XMIN to GPVAL_TERM_XMIN

[Allin C. <cot...@wf...>]

On Mon, 7 Jan 2008, Ethan Merritt wrote:

> On Monday 07 January 2008 00:49, Petr Mikulik wrote:
> > Recently, new variables
> > 	TERM_XMIN TERM_XMAX TERM_YMIN TERM_YMAX
> > have been added. I propose to rename them to 
> > 	GPVAL_TERM_XMIN GPVAL_TERM_XMAX GPVAL_TERM_YMIN GPVAL_TERM_YMAX
> 
> I thought of that also.
> Either way is OK with me.

I too am OK with Petr's alternative namings (a little verbose, 
perhaps).

Allin Cottrell

Re: rename TERM_XMIN to GPVAL_TERM_XMIN

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

On Monday 07 January 2008 00:49, Petr Mikulik wrote:
> Recently, new variables
> 	TERM_XMIN TERM_XMAX TERM_YMIN TERM_YMAX
> have been added. I propose to rename them to 
> 	GPVAL_TERM_XMIN GPVAL_TERM_XMAX GPVAL_TERM_YMIN GPVAL_TERM_YMAX

I thought of that also.
Either way is OK with me.

-- 
Ethan A Merritt

pdf term (pdflib) and "set encoding"

[Allin C. <cot...@wf...>]

Here's a small patch for the pdflib-based pdf terminal, similar to 
the one I submitted for emf term.

Again, the idea is to respect the user's choice of encoding if 
possible. It may be that not all versions of pdflib-lite support 
the iso-8859-X encodings, but recent versions do.  And I think the 
fallback mechanism is such this change won't break anything that 
works at present.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Re: emf term and "set encoding"

[Allin C. <cot...@wf...>]

On Sun, 6 Jan 2008, Ethan A Merritt wrote:

> On Sunday 06 January 2008 18:09, Allin Cottrell wrote:
> > 
> > The attached patch fixes this for cp1250, and also contains a 
> > tentative fix for iso_8859_9, mapping it onto Windows' 
> > TURKISH_CHARSET.  It's possible that one could map koi8r onto 
> > RUSSIAN_CHARSET, I'm not sure.  But cp1250 I'm sure about.
> 
> Thanks. Added to cvs.
> 
> There is a separate KOI8_CHARSET that supposedly covers both
> koi8r and koi8u (at least that's what the comment in the header says).
> I added it to the patch.

Sounds good.

> By any chance would you have sufficient documentation for EMF to 
> add support for enhanced text mode?  I've never been able to 
> find a description of how exactly how the text placement works 
> in EMF.

Sorry, I can't claim any expertise in that.  One can find accounts 
of the structures EMREXTTEXTOUTA and EMRTEXT on msdn.com; the 
latter, at 

http://msdn2.microsoft.com/en-us/library/ms534511(VS.85).aspx

contains various fields that might be relevant, but I have no idea 
how to use them!

Allin Cottrell

rename TERM_XMIN to GPVAL_TERM_XMIN

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

Recently, new variables
	TERM_XMIN TERM_XMAX TERM_YMIN TERM_YMAX
have been added. I propose to rename them to 
	GPVAL_TERM_XMIN GPVAL_TERM_XMAX GPVAL_TERM_YMIN GPVAL_TERM_YMAX
so that 

- they have same name as all other autogenerated variables (see 
  "show variables all"), like GPVAL_TERM, GPVAL_TERMOPTIONS, GPVAL_X_MIN, 
  etc.

- they are "read-only", try e.g.

gnuplot> GPVAL_X_MIN=99
         ^
         Cannot set internal variables GPVAL_ and MOUSE_

---
PM

Re: emf term and "set encoding"

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

On Sunday 06 January 2008 18:09, Allin Cottrell wrote:
> 
> The attached patch fixes this for cp1250, and also contains a 
> tentative fix for iso_8859_9, mapping it onto Windows' 
> TURKISH_CHARSET.  It's possible that one could map koi8r onto 
> RUSSIAN_CHARSET, I'm not sure.  But cp1250 I'm sure about.

Thanks. Added to cvs.

There is a separate KOI8_CHARSET that supposedly covers both
koi8r and koi8u (at least that's what the comment in the header says).
I added it to the patch.

By any chance would you have sufficient documentation for EMF
to add support for enhanced text mode?  I've never been able to
find a description of how exactly how the text placement works
in EMF.

-- 
Ethan A Merritt