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

Re: special behavior of postscript terminal? (again)

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

On Thursday 23 October 2008 16:31:01 Allin Cottrell wrote:
> On Thu, 23 Oct 2008, Ethan Merritt wrote:
> 
> > On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote:
> > > It seems to me that a nice solution would be if "set style line" 
> > > were extended to include a "dashtype/dt" option, in the same way 
> > > that pointtype can be selected independently of other features of 
> > > the line.  
> > 
> > Isn't that what it does now?
> > Each line type has an explicit dash pattern, selected by saying "lt N",
> > analogous to selecting point type by saying "pt N".
> 
> Yes, but this depends on the terminal type, making it more or less 
> impossible to produce a "portable" gnuplot command file which will 
> produce similar effects (modulo inevitable differences in 
> capabilities) across the various terminals.

Ah, I misunderstood.
That's an entirely different issue.

We made a concerted effort for 4.2 to bring the sequence of point types
into conformity across terminals.  So far as I recall, no one argued for
doing the same to dash patterns. I have no objections to someone offering
a series of patches that re-orders the sequence of dash patterns to
achieve some level of cross-terminal agreement.

I don't particularly like the sequence used by postscript, but I guess
it is the most likely terminal for which we would have to worry about
compatibility with existing scripts.

Perhaps a more interesting question is how many of the terminals could
support user-defined dash patterns?

  set style dash 1  2,4,2,4      # short-dashes
  set style dash 2  8,4,1,4      # long-dash, dot

  plot sin(x) lc rgb "blue" dashstyle 2, ...
 
> I'm particularly interested in eps, pdf(cairo), png(cairo) and emf 
> (on behalf of Windows users).  To get any dashes you have to set 
> the "dashed" option for these terminals (except for postscript, 
> which as I noted is exceptional in doing dashes by default).  But 
> the "linetype" numbers in dashed mode produce different effects 
> as noted below:
> 
> In postscript, dashed mode:
> 
>  solid lines: 1, 10, 19, 28
>  regular dash: 2, 11, 20, 29
>  short dash: 3, 12, 21, 30
> 
> in pngcairo, pdfcairo, dashed mode:
> 
>  solid lines: 1, 6, 11, 16, 21
>  regular dash: 2, 7, 12, 17, 22
>  short dash: 3, 8, 13, 18
> 
> in emf, dashed mode:
> 
>  solid lines: 1 to 15
>  regular dash: 16 to 30
>  short dash: 31 to 33
> 
> This is a total nightmare with regard to portability.  
> 
> Allin Cottrell
> 



-- 
Ethan A Merritt

Re: special behavior of postscript terminal? (again)

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

On Thu, 23 Oct 2008, Ethan Merritt wrote:

> On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote:
> > It seems to me that a nice solution would be if "set style line" 
> > were extended to include a "dashtype/dt" option, in the same way 
> > that pointtype can be selected independently of other features of 
> > the line.  
> 
> Isn't that what it does now?
> Each line type has an explicit dash pattern, selected by saying "lt N",
> analogous to selecting point type by saying "pt N".

Yes, but this depends on the terminal type, making it more or less 
impossible to produce a "portable" gnuplot command file which will 
produce similar effects (modulo inevitable differences in 
capabilities) across the various terminals.

I'm particularly interested in eps, pdf(cairo), png(cairo) and emf 
(on behalf of Windows users).  To get any dashes you have to set 
the "dashed" option for these terminals (except for postscript, 
which as I noted is exceptional in doing dashes by default).  But 
the "linetype" numbers in dashed mode produce different effects 
as noted below:

In postscript, dashed mode:

 solid lines: 1, 10, 19, 28
 regular dash: 2, 11, 20, 29
 short dash: 3, 12, 21, 30

in pngcairo, pdfcairo, dashed mode:

 solid lines: 1, 6, 11, 16, 21
 regular dash: 2, 7, 12, 17, 22
 short dash: 3, 8, 13, 18

in emf, dashed mode:

 solid lines: 1 to 15
 regular dash: 16 to 30
 short dash: 31 to 33

This is a total nightmare with regard to portability.  

Allin Cottrell

Re: special behavior of postscript terminal? (again)

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

On Thursday 23 October 2008 12:30:21 Allin Cottrell wrote:
> On Mon, 20 Oct 2008, Ethan Merritt wrote:
> 
> > I see two ways to move forward; there may be others:
> > 
> > 1) Formulate a more general model in which you can specify dash-pattern
> > as an independent property at all times.  Most of the code necessary to
> > support this is already in place
> > (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm )
> > but it is not exposed to the user in a friendly fashion.
> 
> It seems to me that a nice solution would be if "set style line" 
> were extended to include a "dashtype/dt" option, in the same way 
> that pointtype can be selected independently of other features of 
> the line.  

Isn't that what it does now?
Each line type has an explicit dash pattern, selected by saying "lt N",
analogous to selecting point type by saying "pt N".
 
> To be a bit more explicit, the idea is that you  
> wouldn't need to set a top-level "dashed" option, but could choose 
> from a common enumeration of types such as
> 
> 0 = solid
> 1 = regular dashes
> 2 = dots
> 3 = short dashes
> 4 = dash-dot ...
> 
> (or some such), with the understanding that not all terminals 
> would necessarily support all options.

Is there a difference between this and simply deciding to set
all terminals to dashed mode by default?  What you are describing is,
so far as I understand it, the way it already works.  This is exactly
what is shown by the demo I pointed to.

The limitation that I see in the current setup is that you pretty
much have to set up all these line styles in advance;  you can't
easily just toggle dashed mode on for one line out of 20.
It is possible, but only by explicitly by setting the characteristics
of the other 19 lines to "lt 1 lc N".

-- 
Ethan A Merritt

Re: special behavior of postscript terminal? (again)

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

On Mon, 20 Oct 2008, Ethan Merritt wrote:

> I see two ways to move forward; there may be others:
> 
> 1) Formulate a more general model in which you can specify dash-pattern
> as an independent property at all times.  Most of the code necessary to
> support this is already in place
> (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm )
> but it is not exposed to the user in a friendly fashion.

It seems to me that a nice solution would be if "set style line" 
were extended to include a "dashtype/dt" option, in the same way 
that pointtype can be selected independently of other features of 
the line.  To be a bit more explicit, the idea is that you 
wouldn't need to set a top-level "dashed" option, but could choose 
from a common enumeration of types such as

0 = solid
1 = regular dashes
2 = dots
3 = short dashes
4 = dash-dot ...

(or some such), with the understanding that not all terminals 
would necessarily support all options.

Allin Cottrell

Re: gnuplot 4.2.4 problem report on "emf term enhanced" with snapshots (Link Error correction)

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

Hellp

The figures could not seen due to link errors.

I have corrected the errors.

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

Hello

gnuplot> set term emf enh
Terminal type set to 'emf'
Options are 'color dashed "Arial" 12'
gnuplot>  set xlabel 'Time (s)'
gnuplot> set out 'test1.emf'
gnuplot> plot sin(x)
gnuplot> set out
gnuplot> set xlabel 'Time (10^6 {/Symbol m}s)'
gnuplot> set out 'test2.emf'
gnuplot> plot sin(x)
gnuplot> set out

xlabel without enhaced text like set xlabel 'Time (s)' has no problem
http://www.geocities.jp/tmgpltwin/Files/Files.html
0006 test1.emf.png, 33,264 bytes, 2008-10-18, emf enhaced test

However 
xlabel without enhaced text like set xlabel 'Time (s)' has a problem.
The xlabel does not appear
http://www.geocities.jp/tmgpltwin/Files/Files.html
0007 test2.emf.png, 34,066 bytes, 2008-10-18, emf enhaced test

The enhaced text does not also appear on Microsoft PowerPoint 2003.
http://www.geocities.jp/tmgpltwin/Files/Files.html
0008 test2.emf.ppt.png, 45,282 bytes, 2008-10-18, emf enhaced test

However, on OpenOffice (Writer) 2.4, the enhaced text appears,
http://www.geocities.jp/tmgpltwin/Files/Files.html
0009 test2.emf.Oo.png, 53,863 bytes, 2008-10-18, emf enhaced test

After the figure is ungrouped on PowerPoint, the enhanced text appears,
http://www.geocities.jp/tmgpltwin/Files/Files.html
0010 test2.emf.ppt2.png, 53,863 bytes, 2008-10-18, emf enhaced test

The probelm seems that emf format for the enhanced text being imcompatible to windows viewer or
Microsoft office 2003 (I do not have Office 2007 so that the result for office 2007 will not be
known).

Regards

Tatsuro



--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: Download webpage is outdated

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

On Wednesday 22 October 2008 06:42:49 Petr Mikulik wrote:

> 
> I wanted to update the text, but I cannot log onto sourceforge to do it 
> since several weeks. When I do
> 	ssh gnuplot.sourceforge.net
> then I get
> 	port 22: Connection refused.
> 
> Somebody knows what is going wrong?

Yes. When SourceForge moved their operations to a new set of machines
at the beginning of last month (September), they dropped support for
shell login.  In order to access files on the web site you must use
sftp or the equivalent.  You will need to do something like:

   > sftp mikulik,gn...@fr... 
   sftp> cd htdocs
   sftp> get download.html

   [edit locally]

   sftp> put download.html

-- 
Ethan A Merritt

Re: Download webpage is outdated

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

On Wednesday 22 October 2008, gnu...@t4... wrote:
> This came up on IRC earlier; http://www.gnuplot.info/ says the current
> stable version is 4.2.4. Clicking on download under "Current released
> version" indeed takes one to a version 4.2.4 download. However,
> clicking download under "gnuplot homepage" at the top leads to the page
> http://gnuplot.sourceforge.net/download.html, which says the current
> version is 4.2.3. Can whoever has write access to the website update that
> little inconsistency?

I will add it to my list of things to do whenever a release happens.

-- 
Ethan A Merritt

Re: Download webpage is outdated

[Christoph B. <us...@be...>]

Petr Mikulik schrieb:
>
> I wanted to update the text, but I cannot log onto sourceforge to do it 
> since several weeks. When I do
> 	ssh gnuplot.sourceforge.net
> then I get
> 	port 22: Connection refused.
> 
> Somebody knows what is going wrong?


I found this:

http://sourceforge.net/community/forum/topic.php?id=3518&page&replies=1

Hope that helps you,
Christoph

Re: Download webpage is outdated

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

> This came up on IRC earlier; http://www.gnuplot.info/ says the current
> stable version is 4.2.4. Clicking on download under "Current released
> version" indeed takes one to a version 4.2.4 download. However,
> clicking download under "gnuplot homepage" at the top leads to the page
> http://gnuplot.sourceforge.net/download.html, which says the current
> version is 4.2.3. Can whoever has write access to the website update that
> little inconsistency?

I wanted to update the text, but I cannot log onto sourceforge to do it 
since several weeks. When I do
	ssh gnuplot.sourceforge.net
then I get
	port 22: Connection refused.

Somebody knows what is going wrong?

P.M.

Download webpage is outdated

[<gnu...@t4...>]

This came up on IRC earlier; http://www.gnuplot.info/ says the current
stable version is 4.2.4. Clicking on download under "Current released
version" indeed takes one to a version 4.2.4 download. However,
clicking download under "gnuplot homepage" at the top leads to the page
http://gnuplot.sourceforge.net/download.html, which says the current
version is 4.2.3. Can whoever has write access to the website update that
little inconsistency?

Tait

Re: iterate evaluate

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

On Tuesday 21 October 2008, Juergen Wieferink wrote:

> I have a set of n contour lines at, say, d0 = 1, d1 = 0.1, d2 =
> 1e-2, ...  and I would like to do something like:
> 
> command = 'set cntrparam levels discrete d0'
> add_var(i) = sprintf('command = command ., d%i', i)
> evaluate for [i=1:3] add_var(i)
> 
> Well, it may not be the best style, but there might be other use
> cases, too.  Additionally, the simple
> 
> set for [i=0:3] cntrparam levels discrete 10**(-i)
> 
> Does not work as the levels are replaced instead of appended.

That seems like a separate issue.
How about a patch to allow
   set cntrparam levels discrete add <foo>
similar to the existing option
   set xtics add ("label" POSITION)




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

Re: special behavior of postscript terminal? (again)

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

On Tue, 21 Oct 2008, Ethan A Merritt wrote:

> On Tuesday 21 October 2008, Allin Cottrell wrote:
> > But am I right in thinking that the 
> > dash-pattern spec doesn't work for x11, png, pngcairo and
> > pdfcairo?  (It does for postscript.)
> 
> This is not correct.
> 
> All the cairo-based terminals support dashed lines.
> In fact, most of the reasonably modern terminals do.

Ah, duh!  With the top-level "dashed" option.  I see.

Allin Cottrell

Re: iterate evaluate

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

> > BTW: AFAICS an int_error() leads to leakage right now as
> > check_for_iteration() simply discards (iteration_udv = NULL; ...)
> > instead of doing the correct deallocation.
>
> I could be wrong, but I don't think there is a leak.
> The udvs are all kept in one linked list.
> Setting iteration_udv = NULL doesn't remove the udv from the list.
> It is still accessible by name and will continue to be handled
> like any other defined user variable.

You are of course right.

> > My use case: I have some more or less generic scripts with a
> > differing number of values d0, d1, ...  As I have to construct the
> > command line I'm stuck to the evaluate command.  I cannot even put
> > the iteration into a set command within the evaluated string.
>
> I'm afraid I don't follow that explaination of intended use.
> Could you give an example of how you would use this?

I have a set of n contour lines at, say, d0 = 1, d1 = 0.1, d2 =
1e-2, ...  and I would like to do something like:

command = 'set cntrparam levels discrete d0'
add_var(i) = sprintf('command = command ., d%i', i)
evaluate for [i=1:3] add_var(i)

Well, it may not be the best style, but there might be other use
cases, too.  Additionally, the simple

set for [i=0:3] cntrparam levels discrete 10**(-i)

Does not work as the levels are replaced instead of appended.

Juergen

Re: iterate evaluate

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

On Tuesday 21 October 2008, Juergen Wieferink wrote:
> Hi,
> 
> I would like to expand the iteration feature to the evaluate command
> as I think this would be very useful.  I have attached a first naive
> but generally working patch.  The problem is that the iteration is
> not compatible to recursion.  Can it be fixed?  Is it worth the
> effort?  IMHO a simple recursion detection would suffice.  I don't
> see how to implement this right now in a way that still works after
> an int_error(), though.
> 
> My use case: I have some more or less generic scripts with a
> differing number of values d0, d1, ...  As I have to construct the
> command line I'm stuck to the evaluate command.  I cannot even put
> the iteration into a set command within the evaluated string.

I'm afraid I don't follow that explaination of intended use.
Could you give an example of how you would use this?

> BTW: AFAICS an int_error() leads to leakage right now as
> check_for_iteration() simply discards (iteration_udv = NULL; ...)
> instead of doing the correct deallocation.

I could be wrong, but I don't think there is a leak.
The udvs are all kept in one linked list.
Setting iteration_udv = NULL doesn't remove the udv from the list.
It is still accessible by name and will continue to be handled
like any other defined user variable.


-- 
Ethan A Merritt

Re: special behavior of postscript terminal? (again)

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

On Tuesday 21 October 2008, Allin Cottrell wrote:
> But am I right in thinking that the 
> dash-pattern spec doesn't work for x11, png, pngcairo and
> pdfcairo?  (It does for postscript.)

This is not correct.

All the cairo-based terminals support dashed lines.
In fact, most of the reasonably modern terminals do.

x11 has the most flexible support for dot/dash patterns of any
of the current terminals, since you can redefine it dynamically
using the X Resources gnuplot*line1Dashes and so on.
However, dotted/dashed lines on x11 look horrible, so it's a moot point.

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

Re: special behavior of postscript terminal? (again)

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

On Mon, 20 Oct 2008, Ethan Merritt wrote:

> On Monday 20 October 2008 16:07:11 Allin Cottrell wrote:
> > "With most terminal types, if you specify a color plot then it 
> > seems that by default solid lines are used, not dash patterns, for 
> > line graphs.  However, the postscript terminal behaves 
> > differently: it uses dash patterns by default even when color mode 
> > is selected."
> > 
> > "I think it would be preferable if the post terminal behaved in 
> > the same way as the others."
> > 
> > Are there good reasons for not doing this?  
> 
> I know of only one, but it's a core element of the development policy:
> being consistent with the way it has worked for the last 20 years.

That's fair enough.

> I see two ways to move forward; there may be others:
> 
> 1) Formulate a more general model in which you can specify dash-pattern
> as an independent property at all times.  Most of the code necessary to
> support this is already in place
> (see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm )
> but it is not exposed to the user in a friendly fashion.

That looks interesting.  But am I right in thinking that the 
dash-pattern spec doesn't work for x11, png, pngcairo and
pdfcairo?  (It does for postscript.)

> 2) Allow the user to customize the default order of line 
> properties across all terminals.  I have posted a series of 
> patches to implement this, patchset #2004590, but haven't 
> received much feedback.  If you invoke your preferred line style 
> definitions in ~/.gnuplot, then the "set terminal" options for 
> solid/dash are irrelevant.

Thanks, I'll take a look at that.

Allin Cottrell

iterate evaluate

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

Hi,

I would like to expand the iteration feature to the evaluate command
as I think this would be very useful.  I have attached a first naive
but generally working patch.  The problem is that the iteration is
not compatible to recursion.  Can it be fixed?  Is it worth the
effort?  IMHO a simple recursion detection would suffice.  I don't
see how to implement this right now in a way that still works after
an int_error(), though.

My use case: I have some more or less generic scripts with a
differing number of values d0, d1, ...  As I have to construct the
command line I'm stuck to the evaluate command.  I cannot even put
the iteration into a set command within the evaluated string.

BTW: AFAICS an int_error() leads to leakage right now as
check_for_iteration() simply discards (iteration_udv = NULL; ...)
instead of doing the correct deallocation.

Juergen

Re: special behavior of postscript terminal? (again)

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

On Monday 20 October 2008 16:07:11 Allin Cottrell wrote:
> Five days ago I wrote:
> 
> "With most terminal types, if you specify a color plot then it 
> seems that by default solid lines are used, not dash patterns, for 
> line graphs.  However, the postscript terminal behaves 
> differently: it uses dash patterns by default even when color mode 
> is selected."
> 
> "I think it would be preferable if the post terminal behaved in 
> the same way as the others."
> 
> Are there good reasons for not doing this?  

I know of only one, but it's a core element of the development policy:
being consistent with the way it has worked for the last 20 years.

> If not, would my idea get more attention if I were to submit a patch?

I see two ways to move forward; there may be others:

1) Formulate a more general model in which you can specify dash-pattern
as an independent property at all times.  Most of the code necessary to
support this is already in place
(see http://gnuplot.sourceforge.net/demo_4.3/dashcolor.htm )
but it is not exposed to the user in a friendly fashion.

2) Allow the user to customize the default order of line properties
across all terminals.  I have posted a series of patches to implement
this, patchset #2004590, but haven't received much feedback.  If you
invoke your preferred line style definitions in ~/.gnuplot, then the
"set terminal" options for solid/dash are irrelevant.



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

special behavior of postscript terminal? (again)

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

Five days ago I wrote:

"With most terminal types, if you specify a color plot then it 
seems that by default solid lines are used, not dash patterns, for 
line graphs.  However, the postscript terminal behaves 
differently: it uses dash patterns by default even when color mode 
is selected."

"I think it would be preferable if the post terminal behaved in 
the same way as the others."

Are there good reasons for not doing this?  If not, would my idea 
get more attention if I were to submit a patch?  Thanks.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated

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

Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-10-16)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

gnuplot 4.2.4 proglem report on "emf term enhanced" with snapshots

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

Hello

gnuplot> set term emf enh
Terminal type set to 'emf'
Options are 'color dashed "Arial" 12'
gnuplot>  set xlabel 'Time (s)'
gnuplot> set out 'test1.emf'
gnuplot> plot sin(x)
gnuplot> set out
gnuplot> set xlabel 'Time (10^6 {/Symbol m}s)'
gnuplot> set out 'test2.emf'
gnuplot> plot sin(x)
gnuplot> set out

xlabel without enhaced text like set xlabel 'Time (s)' has no problem
http://www.geocities.jp/tmgpltwin/Files/test1.emf.png

However 
xlabel without enhaced text like set xlabel 'Time (s)' has a problem.
The xlabel does not appear
http://www.geocities.jp/tmgpltwin/Files/test2.emf.png

The enhaced text does not also appear on Microsoft PowerPoint 2003.
http://www.geocities.jp/tmgpltwin/Files/test2.emf.ppt.png

However, on OpenOffice (Writer) 2.4, the enhaced text appears,
http://www.geocities.jp/tmgpltwin/Files/test2.emf.Oo.png

After the figure is ungrouped on PowerPoint, the enhanced text appears,
http://www.geocities.jp/tmgpltwin/Files/test2.emf.ppt2.png
 

The probelm seems that emf format for the enhanced text being imcompatible to windows viewer or
Microsoft office 2003 (I do not have Office 2007 so that the result for office 2007 will not be
known).

Regards

Tatsuro


--------------------------------------
Enjoy MLB with MAJOR.JP! Ichiro, Matsuzaka, Matsui, and more!
http://pr.mail.yahoo.co.jp/mlb/

Re: polygon issues

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

On Friday 17 October 2008 15:08:58 Manfred Schwarb wrote:
> > 
> > I have modified the code in CVS so that if all the polygon vertices are
> > given in screen coordinates, then it is clipped against the full canvas
> > rather than against the plot borders.
> > 
> 
> Thanks a lot, yes this will work for me.
> But this is probably quite confusing, if "set object rect" has other 
> clipping properties than "set object polygon".

Hmmm. True, they are not quite identical.

rectangles: clipped to the canvas if none of the vertices are
            given in axis coordinates.

polygons:   clipped to the canvas if all of the vertices are
            given in screen coordinates.

circles:    clipped to the plot for "plot with circles"
            clipping not reliable for "set object circle"

The only conflicting case is where an edge has one end specified in
axis coordinates and the other end specified in screen coordinates.
That seems like an unusual thing to do, at best.
If this causes a problem, we will deal with it.  Right now I don't know
whether the rectangle or the polygon scheme is better in practice.
It would be nice to have better clipping for circles; perhaps the new 
polygon clipping algorithm can be used there also.


-- 
Ethan A Merritt

Re: polygon issues

[Manfred S. <man...@gm...>]

Am Donnerstag, den 16.10.2008, 14:12 -0700 schrieb Ethan Merritt:
> On Wednesday 15 October 2008 14:03:07 Manfred Schwarb wrote:
> > > > 2) clipping:
> > > >   At the plot borders, these objects seem to be clipped (cut off). As I use these objects as 
> > > >   somehow generic drawing objects in a mixture with "set arrow", things become 
> > > >   really messy, as arrows are not clipped.
> > > >   What I would need are objects that are not clipped, so I can use the whole screen.
> > > >   Up to now I found no way to deactivate this clipping feature. Is there a way to do so?
> > > 
> > > Heh.  You have no idea how much time I spent to get that clipping to work.
> > > 
> > 
> > Hmm :-) I guess doing this clipping is a reasonable default and what
> > most people probably expect.
> > 
> > > But yes, I can imagine there are cases when clipping is undesirable.
> > > The question is: is that a property of the object or a property of the whole plot?
> > > I'll have to think about it.
> 
> I have modified the code in CVS so that if all the polygon vertices are
> given in screen coordinates, then it is clipped against the full canvas
> rather than against the plot borders.
> 

Thanks a lot, yes this will work for me.
But this is probably quite confusing, if "set object rect" has other 
clipping properties than "set object polygon".
A possibility would be, of course, to add this scheme to the whole
"set object" class ...

Cheers,
Manfred

Re: polygon issues

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

On Wednesday 15 October 2008 14:03:07 Manfred Schwarb wrote:
> > > 2) clipping:
> > >   At the plot borders, these objects seem to be clipped (cut off). As I use these objects as 
> > >   somehow generic drawing objects in a mixture with "set arrow", things become 
> > >   really messy, as arrows are not clipped.
> > >   What I would need are objects that are not clipped, so I can use the whole screen.
> > >   Up to now I found no way to deactivate this clipping feature. Is there a way to do so?
> > 
> > Heh.  You have no idea how much time I spent to get that clipping to work.
> > 
> 
> Hmm :-) I guess doing this clipping is a reasonable default and what
> most people probably expect.
> 
> > But yes, I can imagine there are cases when clipping is undesirable.
> > The question is: is that a property of the object or a property of the whole plot?
> > I'll have to think about it.

I have modified the code in CVS so that if all the polygon vertices are
given in screen coordinates, then it is clipped against the full canvas
rather than against the plot borders.

-- 
Ethan A Merritt

Re: extending pstricks terminal driver

[Christoph B. <us...@be...>]

Ethan Merritt schrieb:
> On Wednesday 15 October 2008 03:36:53 Christoph Bersch wrote:
>> Hi,
>>
>> I am currently extending the pstricks terminal driver.
>>
>> Besides some general improvements it should support all color commands 
>> using the enhanced coloring capabilities of the xcolor package. As this 
>> would not work with Tex but only with LaTeX, I will include it as an 
>> option for the driver.
> 
> You correctly point out that the pstricks terminal driver has not been
> kept fully up to date with new gnuplot features.  But gnuplot carries 
> along many out-of-date drivers, so that by itself is not necessarily a
> problem.
> 
> Probably it would be easy enough to add RGB color support using xcolor,
> but adding support for the various "with image" modes would be a lot
> more work.

You are right, I didn't think about the "with image" modes...

> I could offer more useful comments if I had a better understanding of
> why people would choose to use pstricks rather than epslatex.
> Is there some feature in pstricks that is missing from epslatex?

Well, to be honest: I don't really know :-) The current pstricks driver
has no features that the epslatex doesn't have.
As I work a lot with PSTricks, I just wanted to adapt the driver to
support more features.

I thought of one reasonable feature which could be included which is not
supported by other drivers:

- possibility to change the linestyles later in the LaTeX document:

    ...
    \begin{document}
	\newpsstyle{Solid}{linecolor=violet}
	\input pstricksoutput
    \end{document}


    That would also allow the user to create its own linestyles (maybe
also dotstyles):
    \newpsstyle{Solid}{linestyle=dashed, dash=1pt 2pt 3pt 4pt}


Christoph