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

Re: Re: color loop for gd.trm

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

>> set style linetype colorsequence red,green,blue,"FFEE00", ...
>>
>> which would redefine the color sequence for the linetype series, and
>> then it
>> would become the same for all terminals?
>
> Not a bad idea.  So the color would wrap when reaching the end of the
> sequence.  ("colorsequence" is quite long and not easily abreviated
> because of conflicts.)  A bit of extra work perhaps.  How would one
> guarantee that all terminals have the described colors?  And what would
> one do if that were not the case?

It would be supported by all terminals supporting 'lt color rgb "xxxxxx"'.
Others will silently ignore it.

---
PM

Re: Again: canvas size

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

> scale factor, which imply a new terminal option along the
> lines of "dpi <foo>".

I like this option as well.

---
PM

Re: Again: canvas size

[Aapo L. <aap...@gm...>]

On Fri, 2005-10-14 at 08:48 -0700, Ethan Merritt wrote:
> Harald Harders and I have been discussing the possibility of
> allowing sizes to be specified in physical units (cm mm in).
> The scalable vector devices could handle this easily.
> Pixel device would need to be assigned a pixels-per-unit
> scale factor, which imply a new terminal option along the
> lines of "dpi <foo>".

Sounds very good.  I hope a consensus about implementation will be
reached.  This would be an important new feature, especially because
many users already except to be able to (re)size their plotting
area.  ;-)


> But even if we never implement such a sweeping global
> change, it is clear that many people would like a
> size option for the PostScript and TeX based terminals.

IMO (a user opinion), the global change would be good.  Because a) the
old system is not very consistent between different terminals and b) it
is easier to remember just one keyword for sizes that would work for all
terminals.

							Aapo

-- 
Aapo Lankinen <aap...@gm...>

make dist

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

Hi,

"make dist" generally isn't very stable.  The attached patch has got
it working for me at least for one computer.  It explicitly includes
the source files in demo/html instead of the directory.  Is there a
better way to include demo/html?

While in demo/html/: Shouldn't GNUPLOT_LIB be set to .. for
webify.pl by default?  I don't know how to achieve that without
overwriting some prior value, though.


Juergen

Re: Again: canvas size

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

On Friday 14 October 2005 01:37 am, Aapo Lankinen wrote:
> On Thu, 2005-10-13 at 09:18 -0700, Ethan Merritt wrote:
> > Let me phrase that in a different way:
> > 
> > I strongly advocate that "set size" have the same behaviour
> > regardless of whether it is called before or after "set term".
> > It should affect the scaling of the next plot to be drawn,
> > but it should never affect the size of the canvas[*].
> 
> Does that mean there should be a new command "set canvas" or a dedicated
> "canvas" option that all terminals should implement?

Maybe.

There are at least three classes of terminals:
- pixel terminals (png pbm x11 win ...)
- scalable vector devices (post latex svg emf cgm mif fig ...)
- fixed-size hardware (pen_plotters ...)

Harald Harders and I have been discussing the possibility of
allowing sizes to be specified in physical units (cm mm in).
The scalable vector devices could handle this easily.
Pixel device would need to be assigned a pixels-per-unit
scale factor, which imply a new terminal option along the
lines of "dpi <foo>".  The fixed-size devices probably have
some intrinsic and unchangeable scale, but gnuplot probably
cannot determine what that is on its own.

We had not progressed to the point of discussing what sort of
error message or default  behaviour would be appropriate if, e.g.,
the user requests a  size in cm but the current output device
has no idea what is a "cm".

But even if we never implement such a sweeping global
change, it is clear that many people would like a
size option for the PostScript and TeX based terminals.


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

Re: color loop for gd.trm

[Shigeharu T. <sh...@ie...>]

shige 10/14 2005
----------------

| From: Ethan Merritt <merritt@u.washington.edu>
| To: Shigeharu TAKENO <sh...@ie...>
| Subject: Re: color loop for gd.trm
| Date: Tue, 11 Oct 2005 11:42:36 -0700
| Cc: gnu...@li...
=====
| So your goal is not to reduce the total number of colors, instead
| it is to have the same default colors on all terminals?

No. I only want to realize x11 or win term's color loops on png 
term simply.

| My feeling is that the default colors on different terminal types
| should *not* be the same, because each terminal has its own set
| of visual properties.  

I agree with you.

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Re: Again: canvas size

[Aapo L. <aap...@gm...>]

On Thu, 2005-10-13 at 09:18 -0700, Ethan Merritt wrote:
> Let me phrase that in a different way:
> 
> I strongly advocate that "set size" have the same behaviour
> regardless of whether it is called before or after "set term".
> It should affect the scaling of the next plot to be drawn,
> but it should never affect the size of the canvas[*].

Does that mean there should be a new command "set canvas" or a dedicated
"canvas" option that all terminals should implement?

						Aapo

-- 
Aapo Lankinen <aap...@gm...>

Re: gnuplot+octave+cygwin-X11

[John W. E. <jw...@be...>]

On 14-Oct-2005, Shai Ayal wrote:

| can you point me at the source files which contain all the plot
| related stuff? 

Start here:

  scripts/plot
  src/DLD-FUNCTIONS/gplot.l

jwe

Re: gnuplot+octave+cygwin-X11

[Shai A. <sh...@gm...>]

John,

can you point me at the source files which contain all the plot related stu=
ff?

Shai

On 10/14/05, John W. Eaton <jw...@be...> wrote:
> On 12-Oct-2005, Shai Ayal wrote:
>
> | Maybe while doing these changes, the much talked about "split" of the
> | plotting code from octave could also be implemented? I have no idea
> | how, but it seems that the gnuplot interface will undergo not so minor
> | changes so it's a good time to at least do it in way which will be
> | consistent with the future plan to split the gnuplot code.
>
> In 2.9.x, the split is mostly complete.
>
> Also, I've checked in some changes that make Octave use a separate
> process for each figure window.  It seems to work for me.  If you'd
> like to check it out, try the latest version of Octave from the CVS
> archive.
>
> jwe
>

Re: gnuplot+octave+cygwin-X11

[John W. E. <jw...@be...>]

On 12-Oct-2005, Shai Ayal wrote:

| Maybe while doing these changes, the much talked about "split" of the
| plotting code from octave could also be implemented? I have no idea
| how, but it seems that the gnuplot interface will undergo not so minor
| changes so it's a good time to at least do it in way which will be
| consistent with the future plan to split the gnuplot code.

In 2.9.x, the split is mostly complete.

Also, I've checked in some changes that make Octave use a separate
process for each figure window.  It seems to work for me.  If you'd
like to check it out, try the latest version of Octave from the CVS
archive.

jwe

Re: Again: canvas size

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

On Thursday 13 October 2005 09:56 am, Ethan Merritt wrote:
 And here are the results for 3.7
> 
> 	mif	Bounding box remains unchanged, plot scale is doubled
		3.7 same
> 	dumb	segfault
		3.7 no segfault I don't know what changed
> 	emf	Abort
		3.7 no emf driver 
> 	cgm	Abort
		3.7 same
> 	png	image is twice the size requested in "set term"
> 	pbm	image size is twice default
> 		(4.0 had no "set term pbm size ..." option)
		3.7 uses old png driver, png and pbm behave the same

> 	fig	"set term fig inches size 3 3"
> 		resulting plot extends from -2 to 4 inches on y
> 		and from 1 to 7 inches on x
		3.7 Xfig displays no plot if size is set to 2,2
		but shows the expected plot is size is set to 1,1
		I have no idea why, but version 4.0 was clearly an
		improvement

> 	post	%%BoundingBox: -454 50 554 1490
> 		(size 1,1 gives %%BoundingBox: 50 50 554 770)
		3.7 same

> 	eps	%%BoundingBox: 50 50 770 554
> 		(size 1,1 gives %%BoundingBox: 50 50 410 302)
		3.7 same

> 	epslatex	result depends on the TeX options in the
> 			surrounding document
		3.7 no epslatex driver
 
> size greater than 1 was already seriously broken, and it remains so.
  3.7 same :-)


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

Re: Again: canvas size

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

On Thursday 13 October 2005 09:36 am, Hans-Bernhard Broeker wrote:
> 
> Backward compatibility cannot be judged from the current CVS version. 
> Only the release version(s) can serve as a reference, 

Fine. I have re-run my test sequence using version 4.0
  set size 2,2
  set term <foo>
  set output '2.foo'
  plot sin(x)

Here are the results:

	mif	Bounding box remains unchanged, plot scale is doubled

	dumb	segfault
	emf	Abort
	cgm	Abort
	png	image is twice the size requested in "set term"
	pbm	image size is twice default
		(4.0 had no "set term pbm size ..." option)

	fig	"set term fig inches size 3 3"
		resulting plot extends from -2 to 4 inches on y
		and from 1 to 7 inches on x

	post	%%BoundingBox: -454 50 554 1490
		(size 1,1 gives %%BoundingBox: 50 50 554 770)
	eps	%%BoundingBox: 50 50 770 554
		(size 1,1 gives %%BoundingBox: 50 50 410 302)

	epslatex	result depends on the TeX options in the
			surrounding document


> and compability  
> with 4.0 has *already* been broken, for reasons I personally don't think 
> justify doing so.

So I find no change between 4.0 and 4.1,
except that I recently added a "set term pbm size xx,yy" option.

size > 1 was already seriously broken, and it remains so.

 

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

Re: linestyle docs broken?

[Lars H. <lhe...@us...>]

 
> Works fine for me.
> 
> gnuplot> set style line 1 lt 4 lc rgb "pink"
> gnuplot> plot sin(x) with lines ls 1
> 
> Or am I misunderstanding your point?
 
 Ahh. I wasn't aware that I need to set a line style first. That is
 not very clear from the docs.

Re: linestyle docs broken?

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

Lars Hecking wrote:
> Hans-Bernhard Broeker writes:
> 
>  Sorry, I meant: should the code change, i.e. should the linestyle/ls option
>  be created?

No.  It already exists (or at least, it did, for quite a while).  If 
it's gone, thats a bug which needs fixing.

>  Confusing. So the documentation should be changed

No.  The code has to be.

Re: Again: canvas size

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

Ethan Merritt wrote:

>  If I request that image size explicitly, then absolutely that is what
>  I am expecting to get.  The size of the plot within that image may be
>  varied using "set size", as it is for multiplots, but the image size
>  should be invariant.

Herein lies the problem.  I think some recent changes in this area were 
committed wihthout sufficient insight.

'set size' before 'set term' was a working method in gnuplot-4.0, for a
non-negligeable number of drivers, to change the overall size of the 
plot.  Scripts using that are now broken.

> I claim that "set size" should *not* change the page size, or bounding
> box size.  

I tend to see compatibility with previously working, publically 
recommended (in the newsgroup) practice more important than a 'should' 
based on aesthetic arguments.

 > The mif behavior is exactly what it should be, assuming that
> it is legal to specify a size greater than 1 in the first place.

It always was, and was sometimes necessary.   I don't think that 
deliberately breaking all scripts that used it is an acceptable 
short-term plan.


> No, it is not.  It is producing a scalable image that is now twice
> as large as the bounding box.  

And that means its lieing through its teeth about that bounding box.

 > As Harald point out, that is also the
> result from "set term post eps".  

Release 4.0 still got that right.

> I strongly advocate that "set size" be limited to sizes equal
> or less than 1.0,  but only after some to-be-determined list
> of terminals drivers are modified to accept a "size" option as
> part of the terminal spec.

Having the same option in very many, maybe all terminals, feels wrong. 
It also breaks one of our basic design principles of old: scripts must 
work reasonably, and should work as equally as possible, on all drivers. 
    If essentially terminals are to have this option, IMHO that's 
grounds for introducing a new core command that talks to a new terminal 
API function to implement that functionality.

> Forget backward compatibility. There can be none, because the current
> behaviour is not even compatibility with itself.

Backward compatibility cannot be judged from the current CVS version. 
Only the release version(s) can serve as a reference, and compability 
with 4.0 has *already* been broken, for reasons I personally don't think 
justify doing so.

Re: linestyle docs broken?

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

On Thursday 13 October 2005 09:08 am, Lars Hecking wrote:
> 
>  I've been playing around with linestyles to see whether I could get any
>  resemblance of dashed lines with X/png/gif, which is apparently not
>  possible, and came across this issue.

It is possible in X, but only if you set the appropriate Xresources
as described in the documentation.  The default state is the equivalent
to "set term post solid".  If the Xresources provide dash patterns,
then you get the equivalent of "set term post dashed".

Try:
   echo "gnuplot*line2Dashes:   42" | xrdb -merge
   echo "gnuplot*line3Dashes:   88" | xrdb -merge
   echo "gnuplot*line5Dashes:   63" | xrdb -merge
   gnuplot -persist dashcolor.dem

   
>  But "with <style>" does not accept a "linestyle" or "ls" option,

Works fine for me.

gnuplot> set style line 1 lt 4 lc rgb "pink"
gnuplot> plot sin(x) with lines ls 1

Or am I misunderstanding your point?

> I think I've seen quite a few scripts using
>  "plot foo with lines N".

That was acceptable syntax in earlier versions, and is still
accepted for backward compatibility with old scripts.
However, in the presence of some new (4.1 only) features,
this syntax is ambiguous and can cause parsing errors.  

The ambiguity is not a problem for old scripts because they
obviously do not contain the new options. And the explicit
use of the "lt" or "linetype" keyword is accepted by all
versions of gnuplot.    

So the form "with lines N" is deprecated for new scripts,
but is still accepted for backward compatibility with old scripts.
I suppose the documentation could state that. 


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

Re: linestyle docs broken?

[Lars H. <lhe...@us...>]

Hans-Bernhard Broeker writes:
> Lars Hecking wrote:
> > But "with <style>" does not accept a "linestyle" or "ls" option,
> 
> If so, that's quite clearly a bug.
> 
> > If you agree, I'll commit the change to cvs. Or should the could change

 Sorry, I meant: should the code change, i.e. should the linestyle/ls option
 be created?

> > to match the docs? 
> 
> The latter.
> 
> > I think I've seen quite a few scripts using
> > "plot foo with lines N".
> 
> Of course --- but those should all be legacy scripts, from the time 
> before 'linetype' was an named argument, and that 'N' does *not* mean 
> 'ls <N>' but 'lt <N>'.

 Confusing. So the documentation should be changed

 Syntax:
       with <style> { <line_type>
                      | {{linetype  | lt <line_type>}
         ....

 ?

Re: Again: canvas size

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

On Thursday 13 October 2005 09:05 am, Ethan Merritt wrote:
> I strongly advocate that "set size" be limited to sizes equal
> or less than 1.0

Let me phrase that in a different way:

I strongly advocate that "set size" have the same behaviour
regardless of whether it is called before or after "set term".
It should affect the scaling of the next plot to be drawn,
but it should never affect the size of the canvas[*].


* Canvas:  The image size in pixels for pixel devices,
  the BoundingBox for postscript or TeX devices,  the paper
  size for pen plotters.


As before, I note that backwards compatibility is out of
question because there is no consistent behaviour to be
compatible with.


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

Re: linestyle docs broken?

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

Lars Hecking wrote:
>  But "with <style>" does not accept a "linestyle" or "ls" option,

If so, that's quite clearly a bug.

>  If you agree, I'll commit the change to cvs. Or should the could change
>  to match the docs? 

The latter.

 > I think I've seen quite a few scripts using
>  "plot foo with lines N".

Of course --- but those should all be legacy scripts, from the time 
before 'linetype' was an named argument, and that 'N' does *not* mean 
'ls <N>' but 'lt <N>'.

linestyle docs broken?

[Lars H. <lhe...@us...>]

 I've been playing around with linestyles to see whether I could get any
 resemblance of dashed lines with X/png/gif, which is apparently not
 possible, and came across this issue.

 gnuplot> help style
 Functions and data may be displayed in one of a large number of styles.
 The `with` keyword provides the means of selection.
 
 Syntax:
       with <style> { {linestyle | ls <line_style>}
                      | {{linetype  | lt <line_type>}
                         {linewidth | lw <line_width>}
                         {linecolor | lc <colorspec>}
                         {pointtype | pt <point_type>}
                         {pointsize | ps <point_size>}
                         {fill | fs <fillstyle>}
                         {palette}}
                    }
 
 But "with <style>" does not accept a "linestyle" or "ls" option,
 so this should be rewritten as

 Syntax:
       with <style> { <line_style>
                      | ...

 If you agree, I'll commit the change to cvs. Or should the could change
 to match the docs? I think I've seen quite a few scripts using
 "plot foo with lines N".

Re: Again: canvas size

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

On Thursday 13 October 2005 01:58 am, Hans-Bernhard Broeker wrote:
> 
> > gd.trm		full plot is drawn - size is twice that requested
> 
> And what size was that?

 set term png size <xpixels>,<ypixels>

 If I request that image size explicitly, then absolutely that is what
 I am expecting to get.  The size of the plot within that image may be
 varied using "set size", as it is for multiplots, but the image size
 should be invariant.
 
> > mif.trm		full plot is drawn but bounding box describes only
> > 		lower left corner. Arguably this is the only terminal
> > 		to get it right!
> 
> No, it's not.  The size was set to twice the normal one, *before* 'set 
> terminal' and 'set output'. Thus, it should have changed not just the   
> plot size, but also the page size, i.e. the bounding box.

Here is the root of the problem.
I claim that "set size" should *not* change the page size, or bounding
box size.  The mif behavior is exactly what it should be, assuming that
it is legal to specify a size greater than 1 in the first place.

> mif.trm is  
> ignoring the one input it currently has about the intended actual size 
> of the plotted output.

No, it is not.  It is producing a scalable image that is now twice
as large as the bounding box.  As Harald point out, that is also the
result from "set term post eps".  So that raises the total number
of correct and consistent output devices to 2, if you count eps as
a separate output device from postscript.

I realize that different people have different expectations.
But equally, different gnuplot terminals have different behaviors.
My expectations are met by mif and eps; yours are apparently met
by some other terminal type (which one?).

Whoever is "right", the current state is a total mess as far as
cross-device compatibility.

I strongly advocate that "set size" be limited to sizes equal
or less than 1.0,  but only after some to-be-determined list
of terminals drivers are modified to accept a "size" option as
part of the terminal spec.

Forget backward compatibility. There can be none, because the current
behaviour is not even compatibility with itself.


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

Re: Again: canvas size

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

Ethan Merritt wrote:
> Arguably, the only terminal to get it right is mif.trm.

No.

> post.trm	full plot is drawn - bounding box goes negative

> gd.trm		full plot is drawn - size is twice that requested

And what size was that?

> fig.trm		full plot is drawn - size is twice that expected

Expected by whom, why?

> mif.trm		full plot is drawn but bounding box describes only
> 		lower left corner. Arguably this is the only terminal
> 		to get it right!

No, it's not.  The size was set to twice the normal one, *before* 'set 
terminal' and 'set output'.  Thus, it should have changed not just the 
plot size, but also the page size, i.e. the bounding box.  mif.trm is 
ignoring the one input it currently has about the intended actual size 
of the plotted output.

Re: Again: canvas size

[V. <gae...@no...>]

On Wed, Oct 12, 2005 at 02:35:33PM -0700, Ethan Merritt wrote:
> On Tuesday 11 October 2005 11:16 pm, Ga=EBl Varoquaux wrote:
> >     By the way, the fonts are tiny and unreadable in my browser (Fire=
fox)
> > for the demo webpages. I am the only one this happens to ?

> For me it comes out small but very legible in firefox.
> But I see that it is hitting the minimum fontsize limit (9)
> rather than the default/2 (12/2=3D6), so I will increase that spec
> on the web site to fontsize to 75% of default instead.
> See if that is better for you.

    Currently (thursday 13th, 8am paris time) the code in the 4.1 demos
are unreadable, but the 4.0 demos are very nice. That's the case with
firefox, both on a Ubuntu box, and on a win2k box (both have 1024x768=20
screens), but not with IE 5.5.

--
    Ga=EBl

Re: Again: canvas size

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

On Wed, 12 Oct 2005, Ethan Merritt wrote:

> On Wednesday 12 October 2005 04:45 pm, Harald Harders wrote:
>
> > > Introduce a new coordinate system "absolute", or maybe even the specific
> > > units  "in", "cm", "pt", "pixel".
> >
> > I totally agree with this approach. The specific units have too problems:
> > How shall pixel defined in vector terminals
>
> I assume that you would not specify a measurement in pixels if you are
> using a vector terminal.

I won't. But many other people will. And it might happen that you have
used a pixel terminal and switch to a vector terminal afterwards. Thus,
every unit should work everywhere.

> > and how shall in, ch, pt be
> > defined in terminals without a absolute canvas size?
>
> Which terminals do you have in mind here - the pixel terminals?

I thought of screen terminals (which in fact are also pixel terminals).
Pixel terminals are not a problem because of the resolution. I think we
can give every terminal that does not know a resolution a default of
72dpi. Also vector-based terminals could use a (pseudo) resolution to
convert pixels to real measures.

> > For png and jpeg, a
> > resolution in dpi could be given and thus in, ch, and pt also used.
>
> I think we would have to introduce a "dpi" parameter into the various terminal
> options.  There would have to be a default value, which would usually turn out
> to be wrong, but what else can we do?
>
> 	set term png size 900,300  {dpi 300}
> would be the same as
> 	set term png size 3in, 1in dpi 300

That's a good idea. Then, all terminals could get the ability of absolute
measures. The second line would change to

        set term png size inch 3,1 dpi 300

if inch is one of the new measures. Then, sizes could be given using
get_position() which allows all measures except 'screen', 'first',
'second', and 'graph'. Even 'character' could be valid (even if strange).
For pixel-based terminals, the unit could default to 'pixel', for
postscript to 'pt'.

I think adding 'inch', 'millimeter', 'point', and 'pixel' to the list of
coordinate systems would be a big step in the right direction. This would
enable users to produce plots in exact the size they want to get them.

Best regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: Again: canvas size

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

On Wednesday 12 October 2005 04:45 pm, Harald Harders wrote:

> > Introduce a new coordinate system "absolute", or maybe even the specific
> > units  "in", "cm", "pt", "pixel".
> 
> I totally agree with this approach. The specific units have too problems:
> How shall pixel defined in vector terminals

I assume that you would not specify a measurement in pixels if you are
using a vector terminal.

> and how shall in, ch, pt be 
> defined in terminals without a absolute canvas size? 

Which terminals do you have in mind here - the pixel terminals?

> For png and jpeg, a 
> resolution in dpi could be given and thus in, ch, and pt also used.

I think we would have to introduce a "dpi" parameter into the various terminal
options.  There would have to be a default value, which would usually turn out
to be wrong, but what else can we do?

	set term png size 900,300  {dpi 300}
would be the same as
	set term png size 3in, 1in dpi 300

Both would generate a 3 inch by 1 inch image when printed to
a 300 dpi printer.  The first form would only require the dpi
value if you in fact wanted to use absolute coordinates in inches or cm.
The second form absolutely requires the dpi value in order to calculate
the necessary size in pixels.

> what about x11 and windows? Do they have access to the system-wide
> resolution settings?

X11 has access to the display resolution.
It is not system-wide because it can be different for each display device.


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