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

Keybox too small for user defined location when using splot

[Mike S. <mw...@us...>]

for 4.2 CVS branch.

When I run the the script below the keybox is incorrectly drawn.  The bottom 
of the keybox cuts right between the cos and tan entries in the key.  If I 
omit the key title the box is drawn correctly.

set term x11 persist
set key box
set key title "KEY TITLE LONG"
set key box at screen .9, screen .98
splot x,x,sin(x),cos(x),tan(x)

Mike Sutton

Re: Are minor grid lines broken?

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Daniel J Sebald" <dan...@ie...>
> To: "Mike Sutton" <mw...@us...>
> Subject: Re: Are minor grid lines broken?
> Date: Tue, 13 Feb 2007 14:38:01 -0600
>=20
>=20
> Mike Sutton wrote:
> > I tried the following and I get the minor tics, but not the minor grid =
lines.
> >
> > gnuplot> set mxtics
> > gnuplot> set mytics
> > gnuplot> set tics scale 3,1.5
> > gnuplot> set grid lc rgb "green",lc rgb "blue"
> > gnuplot> sh grid
> >
> >         Rectangular grid drawn at x y tics
> >         Major grid drawn with linetype 0 linecolor rgb "green"=20=20
> > linewidth 1.000
> >         Minor grid drawn with linetype 0 linecolor rgb "blue"=20=20
> > linewidth 1.000
> >         Grid drawn at default layer
> >
> > gnuplot> plot x
>=20
> The sequence above works if "set grid" is used.  The documentation=20
> doesn't say anything about "linecolor", just "linestyle",=20
> "linetype", "linewidth".

DUH.  I forgot 'set grid mxtic mytic'.

Mike Sutton


=3D
Clothing Hangers - For The Home
Huge selection-wood, metal, plastic low prices and free shipping offer.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Dcdb6175d7434f7a2c5d99=
a7f3c227bcd

Re: Are minor grid lines broken?

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

Mike Sutton wrote:
> I tried the following and I get the minor tics, but not the minor grid lines.
> 
> gnuplot> set mxtics
> gnuplot> set mytics
> gnuplot> set tics scale 3,1.5
> gnuplot> set grid lc rgb "green",lc rgb "blue"
> gnuplot> sh grid
> 
>         Rectangular grid drawn at x y tics
>         Major grid drawn with linetype 0 linecolor rgb "green"  linewidth 
> 1.000
>         Minor grid drawn with linetype 0 linecolor rgb "blue"  linewidth 1.000
>         Grid drawn at default layer
> 
> gnuplot> plot x

The sequence above works if "set grid" is used.  The documentation doesn't say anything about "linecolor", just "linestyle", "linetype", "linewidth".

Dan

Are minor grid lines broken?

[Mike S. <mw...@us...>]

I tried the following and I get the minor tics, but not the minor grid lines.

gnuplot> set mxtics
gnuplot> set mytics
gnuplot> set tics scale 3,1.5
gnuplot> set grid lc rgb "green",lc rgb "blue"
gnuplot> sh grid

        Rectangular grid drawn at x y tics
        Major grid drawn with linetype 0 linecolor rgb "green"  linewidth 
1.000
        Minor grid drawn with linetype 0 linecolor rgb "blue"  linewidth 1.000
        Grid drawn at default layer

gnuplot> plot x


Mike Sutton

Re: latex/pslatex terminals (was Re: grouping available terminals together)

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

Ethan Merritt wrote:
> On Tuesday 13 February 2007 11:51, Daniel J Sebald wrote:
> 
>>1)  I was thinking a nice option would be "complete" 
> 
> or "selfcontained" (too long) or something that not only would put all 
> the LaTeX/PS code in one file but would also encapsulate that code with 
> the few LaTeX commands that would allow the file to be compiled on its 
> own.
> 
> 	set term epslatex standalone

Oy!  :-)

Re: latex/pslatex terminals (was Re: grouping available terminals together)

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

On Tuesday 13 February 2007 11:51, Daniel J Sebald wrote:
> 1)  I was thinking a nice option would be "complete" 
or "selfcontained" (too long) or something that not only would put all 
the LaTeX/PS code in one file but would also encapsulate that code with 
the few LaTeX commands that would allow the file to be compiled on its 
own.

	set term epslatex standalone

-- 
Ethan A Merritt                                 Courier Deliveries: 1959 
NE Pacific
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

latex/pslatex terminals (was Re: grouping available terminals together)

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

While on the topic if LaTeX related terminals, here's a few comments

1)  I was thinking a nice option would be "complete" or "selfcontained" (too long) or something that not only would put all the LaTeX/PS code in one file but would also encapsulate that code with the few LaTeX commands that would allow the file to be compiled on its own.  Say the idea is to compile the code into EPS format as:

gnuplot foo.gp; latex foo; dvips foo -o foo.ps; ps2eps -f foo.ps

Then just refresh the gv terminal and it is like having the pslatex terminal in a window.  I know it is easy to simply create a short little file to include the gnuplot output, but that creates extra files to keep around when archiving.  (Sure, copy the contents into another file, but that's not convenient for debugging purposes.)


2)  In the documentation are these examples:

 Use gnuplot defaults (mostly sensible, but sometimes not really best):
        set title '\LaTeX\ -- $ \gamma $'
 Force centering both horizontally and vertically:
        set label '{\LaTeX\ -- $ \gamma $}' at 0,0
 Specify own positioning (top here):
        set xlabel '[t]{\LaTeX\ -- $ \gamma $}'
 The other label -- account for long ticlabels:
        set ylabel '[r]{\LaTeX\ -- $ \gamma $\rule{7mm}{0pt}}'

However, my experience is that to get a backslash into the LaTeX code requires \\, not just \.  So the above should probably be

 Use gnuplot defaults (mostly sensible, but sometimes not really best):
        set title '\\LaTeX\\ -- $ \\gamma $'
 Force centering both horizontally and vertically:
        set label '{\\LaTeX\\ -- $ \\gamma $}' at 0,0
 Specify own positioning (top here):
        set xlabel '[t]{\\LaTeX\\ -- $ \\gamma $}'
 The other label -- account for long ticlabels:
        set ylabel '[r]{\\LaTeX\\ -- $ \\gamma $\\rule{7mm}{0pt}}'

Am I overlooking a backslash behavior switch somewhere?  The "most sensible, but sometimes not really best" comment above leaves one wondering "Why?".  Of course, there is always the possibility of defining ones own words outside gnuplot, like "\mytext1", "\eq1", that sort of thing.  But I'm not sure why the original author put that comment there.  (Not arguing against, just wondering what was meant.)

3)  Is the

font '<font>,#'

terminal independent?  At least in terms of size.  I mean, it would be nice if there were a way of translating

font ',16'

so that the pslatex terminal places an approximate "\\large" in the text.  For example, say I want

set title "Here is a title" font ",16"

which creates a bigger title in x11, but not in pslatex.  If I do the following:

set title "\\large Here is a title"

then that "\\large " shows up in other terminals that aren't LaTeX.  Any objection if I write such a patch some day?  Or might there be a reason for a more broader use of the word "size".  We've got "pointsize", maybe "titlesize", "linesize".  Thoughts?


Dan

Re: dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

[Pierre <pie...@gm...>]

On 2/13/07, m sutton <mw...@us...> wrote:
>
> > ----- Original Message -----
> > From: "Ethan A Merritt" <merritt@u.washington.edu>
> > To: gnu...@li...
> > Subject: Re: dashed lines with GD [ was Re: symbol/color/line consistency in  terminals]
> > Date: Sun, 11 Feb 2007 21:44:45 -0800
> >
> >
> > On Sunday 11 February 2007 21:25, Daniel J Sebald wrote:
> > >
> > > > However, it would be nice to set DPI somehow through GD.  > It
> > > would simplify things when I import images into Word or
> > > PowerPoint. Well, that isn't too difficult, is it?
> >
> > Actually, it is.
> >
> > The PNG standard does not provide a place to store dpi.
> > Some apps store it in a comment record, but that is idiosynchratic,
> > and anyhow gd does not (yet) support comment records in PNG.
> >
>
> OK so it not DPI but its close.
>
> The PNG specification supports a chunk called pHYs which related pixels to phyiscal dimensions.
>
> LIBPNG has the following:
>     png_set_pHYs(png_ptr, info_ptr, res_x, res_y,
>         unit_type);
>     res_x       - pixels/unit physical resolution
>                   in x direction
>     res_y       - pixels/unit physical resolution
>                   in y direction
>     unit_type   - PNG_RESOLUTION_UNKNOWN,
>                   PNG_RESOLUTION_METER
>
> So it would appear the GDLIB could would need to a way to call png_set_pHYs.  Then modify gd.trm to accept a resolution setting.
>
> Mike Sutton
>
> p.s.  As a temporary workaround I run ImageMagick's convert with the -density option to set resolution.

The DPI/resolution is a purely informative data. A pixel remains a
pixel. A software can take care of it or not, applies its own, etc (I
had all kind of troubles in pre-press while trusting this info too
much). So I would take it with a grain of salt :)

About GD and meta data, I would like to provide some bridges between
GD and a (working) meta library with a permissive enough license. At
the very least, if nothing exists, I will go with a GD specific
implementation.

--Pierre

Re: dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: gnu...@li...
> Subject: Re: dashed lines with GD [ was Re: symbol/color/line consistency=
 in	terminals]
> Date: Sun, 11 Feb 2007 21:44:45 -0800
>=20
>=20
> On Sunday 11 February 2007 21:25, Daniel J Sebald wrote:
> >
> > > However, it would be nice to set DPI somehow through GD.  > It=20
> > would simplify things when I import images into Word or=20
> > PowerPoint. Well, that isn't too difficult, is it?
>=20
> Actually, it is.
>=20
> The PNG standard does not provide a place to store dpi.
> Some apps store it in a comment record, but that is idiosynchratic,
> and anyhow gd does not (yet) support comment records in PNG.
>=20

OK so it not DPI but its close.

The PNG specification supports a chunk called pHYs which related pixels to =
phyiscal dimensions.

LIBPNG has the following:
    png_set_pHYs(png_ptr, info_ptr, res_x, res_y,
        unit_type);
    res_x       - pixels/unit physical resolution
                  in x direction
    res_y       - pixels/unit physical resolution
                  in y direction
    unit_type   - PNG_RESOLUTION_UNKNOWN,
                  PNG_RESOLUTION_METER

So it would appear the GDLIB could would need to a way to call png_set_pHYs=
.  Then modify gd.trm to accept a resolution setting.

Mike Sutton

p.s.  As a temporary workaround I run ImageMagick's convert with the -densi=
ty option to set resolution.


=3D
Wedding Gown Preservation Specialist
Wedding gown experts specializing in cleaning and preserving of new and vin=
tage wedding gowns, garments and other specialty textiles.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Dde129f1c556af0966c664=
4e2818b6c1d

Re: grouping available terminals together

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

Ethan Merritt wrote:
> On Monday 12 February 2007 12:39, Hans-Bernhard Bröker wrote:
> 
>>Ethan A Merritt wrote:
>>
>>
>>>Back to the topic of allowing color in LaTeX plots.  It seems perfectly
>>>reasonable to me.  
>>
>>Unfortunately, Donald E. Knuth disagrees with that view.  TeX doesn't do 
>>colour, period.
> 
> 
> But LaTeX does, it seems.
> This is a LaTeX driver, right? not a TeX-with-nothing-else driver.
> I'm a LaTeX novice, and may be missing something obvious, but adding
> color "just works" for me here using teTeX.

You both have a valid point.

I think there should be a form of output that is LaTeX with no "specials", and a form that allows use of standard LaTeX packages that might use "\special".  What to call those differences, I'm not sure, e.g., option "-specials", different driver name "slatex", whatever.

Hans mentioned the reasons for DVI platform/app/program independence.  xdvi, for example, uses its own bag of tricks for displaying EPS images.  (Note how EPS images can't be zoomed.)  Other "\special" items like rotated end up in the xdvi view as being not rotated.  (I've just ignored that... so long as it comes out right with dvips I pay no mind, but Hans has a point.)


> 
>>Yes, some extensions of TeX using \special commands put into the DVI 
>>output file, do; as do variants of TeX such as pdftex.  But those are 
>>not TeX.
> 
> 
> Here is a simple test.tex file produced by gnuplot with color enabled
> 
> % GNUPLOT: LaTeX picture
> \setlength{\unitlength}{0.240900pt}
> \ifx\plotpoint\undefined\newsavebox{\plotpoint}\fi
> \sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
> \color[rgb]{0.00,0.00,0.00}
> \begin{picture}(1500,900)(0,0)
> \sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
> \color[rgb]{0.00,0.00,0.00}
> \put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \color[rgb]{0.00,0.00,1.00}
> \put(759,839){\makebox(0,0){TeX color test - title in blue, plot in red}}
> \put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \color[rgb]{1.00,0.00,0.00}
> \put(60,40){\makebox(0,0){$+$}}
> \put(526,286){\makebox(0,0){$+$}}
> \put(993,531){\makebox(0,0){$+$}}
> \put(1459,777){\makebox(0,0){$+$}}
> \color[rgb]{0.00,0.00,0.00}
> \put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \color[rgb]{0.00,0.00,0.00}
> \end{picture}
> 
> And here is my test LaTeX document:
>   \documentclass{article}
>   \usepackage{color}
>   \begin{document}
>   \input{test}
>   \end{document}
> 
> I see nothing marked \special

The "\special" is part of the color package.  Similarly, the "\special" is part of the rotate package.  The idea is LaTeX output that avoids using any LaTeX workarounds for shortcomings in TeX.  (Hence, the reason for running xdvi with warnings turned on the other day.)


> It may well be that there is already no point in using latex.trm;
> that was my other question :-)

Well, there is a point there, but I still think there is a fine distinction for having this.  The advantage of the LaTeX output, i.e., that gnuplot can produce such output, is the ability to place text formatted for interpretation by LaTeX.  That is, one can place a string of text on the plot, that when run through LaTeX comes out as a beautifully formatted math formula or symbol.

So, I'm with Hans that there should be some form of LaTeX terminal whose end result is absolutely no "\specials" or LaTeX packages that produce "\specials".  But at the same time I'm not averse to a "-specials" option that allows use of color and rotate packages, or any other standard LaTeX package.

Dan

Re: grouping available terminals together

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

On 2/12/07, Ethan Merritt wrote:
> On Monday 12 February 2007 12:39, Hans-Bernhard Br=F6ker wrote:
> > Ethan A Merritt wrote:
> >
> > > Back to the topic of allowing color in LaTeX plots.  It seems perfect=
ly
> > > reasonable to me.
> >
> > Unfortunately, Donald E. Knuth disagrees with that view.  TeX doesn't d=
o
> > colour, period.
>
> But LaTeX does, it seems.
> This is a LaTeX driver, right? not a TeX-with-nothing-else driver.
> I'm a LaTeX novice, and may be missing something obvious, but adding
> color "just works" for me here using teTeX.
>
> > Yes, some extensions of TeX using \special commands put into the DVI
> > output file, do; as do variants of TeX such as pdftex.  But those are
> > not TeX.
>
> Here is a simple test.tex file produced by gnuplot with color enabled
>
> % GNUPLOT: LaTeX picture
> \setlength{\unitlength}{0.240900pt}
> \ifx\plotpoint\undefined\newsavebox{\plotpoint}\fi
> \sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
> \color[rgb]{0.00,0.00,0.00}
> \begin{picture}(1500,900)(0,0)
> \sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
> \color[rgb]{0.00,0.00,0.00}
> \put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \color[rgb]{0.00,0.00,1.00}
> \put(759,839){\makebox(0,0){TeX color test - title in blue, plot in red}}
> \put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \color[rgb]{1.00,0.00,0.00}
> \put(60,40){\makebox(0,0){$+$}}
> \put(526,286){\makebox(0,0){$+$}}
> \put(993,531){\makebox(0,0){$+$}}
> \put(1459,777){\makebox(0,0){$+$}}
> \color[rgb]{0.00,0.00,0.00}
> \put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
> \put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
> \color[rgb]{0.00,0.00,0.00}
> \end{picture}
>
> And here is my test LaTeX document:
>   \documentclass{article}
>   \usepackage{color}
>   \begin{document}
>   \input{test}
>   \end{document}
>
> I see nothing marked \special
>
> > I'm pointing out that the whole reason for 'set term latex' to
> > exist, given the much more feature-rich alternatives available, is that
> > its output has a quality that none of the others can offer: it works
> > with *every* valid TeX implementation, no matter how old, no matter how
> > strange.  The price for this feature is that the capabilities are rathe=
r
> > severely limited.  If we break this feature, there'll be no point left
> > to use latex.trm instead of epslatex.trm.  In that case latex.trm would
> > have become pointless.
>
> It may well be that there is already no point in using latex.trm;
> that was my other question :-)
>
> Why this vehemence against color?  The same driver (latex.trm)
> already emits emtex specials if asked.  Those was *are* marked
> \special, and in fact I can't get the resulting file to do anything
> reasonable when fed to teTeX.  Why is that OK but not color?

The command \color itself uses special's on low-level. But I don't see
anything wrong with that.

I would suggest to add both color and rotatebox
1.) If users don't want it, they can still use the same old latex.trm
without color and rotatebox, so they can still get perfectly
compatible file.
2.) Color works well with any reasonable driver. (PS: use the first
color switching command inside \begin{picture}, otherwise it might
influence the text that follows the graphics (I might be wrong
though). Or, perhaps better, color each component separatly - that way
you can preserve a different background color.)

I'm ready to implement those two features, but I guess that you just
did that already.

Mojca]

Re: grouping available terminals together

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

On Monday 12 February 2007 12:39, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>=20
> > Back to the topic of allowing color in LaTeX plots.  It seems perfectly
> > reasonable to me. =20
>=20
> Unfortunately, Donald E. Knuth disagrees with that view.  TeX doesn't do=
=20
> colour, period.

But LaTeX does, it seems.
This is a LaTeX driver, right? not a TeX-with-nothing-else driver.
I'm a LaTeX novice, and may be missing something obvious, but adding
color "just works" for me here using teTeX.
=20
> Yes, some extensions of TeX using \special commands put into the DVI=20
> output file, do; as do variants of TeX such as pdftex.  But those are=20
> not TeX.

Here is a simple test.tex file produced by gnuplot with color enabled

% GNUPLOT: LaTeX picture
\setlength{\unitlength}{0.240900pt}
\ifx\plotpoint\undefined\newsavebox{\plotpoint}\fi
\sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
\color[rgb]{0.00,0.00,0.00}
\begin{picture}(1500,900)(0,0)
\sbox{\plotpoint}{\rule[-0.200pt]{0.400pt}{0.400pt}}%
\color[rgb]{0.00,0.00,0.00}
\put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
\put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
\put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
\color[rgb]{0.00,0.00,1.00}
\put(759,839){\makebox(0,0){TeX color test - title in blue, plot in red}}
\put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
\color[rgb]{1.00,0.00,0.00}
\put(60,40){\makebox(0,0){$+$}}
\put(526,286){\makebox(0,0){$+$}}
\put(993,531){\makebox(0,0){$+$}}
\put(1459,777){\makebox(0,0){$+$}}
\color[rgb]{0.00,0.00,0.00}
\put(60.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
\put(60.0,40.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
\put(1459.0,40.0){\rule[-0.200pt]{0.400pt}{177.543pt}}
\put(60.0,777.0){\rule[-0.200pt]{337.019pt}{0.400pt}}
\color[rgb]{0.00,0.00,0.00}
\end{picture}

And here is my test LaTeX document:
  \documentclass{article}
  \usepackage{color}
  \begin{document}
  \input{test}
  \end{document}

I see nothing marked \special

> I'm pointing out that the whole reason for 'set term latex' to=20
> exist, given the much more feature-rich alternatives available, is that=20
> its output has a quality that none of the others can offer: it works=20
> with *every* valid TeX implementation, no matter how old, no matter how=20
> strange.  The price for this feature is that the capabilities are rather=
=20
> severely limited.  If we break this feature, there'll be no point left=20
> to use latex.trm instead of epslatex.trm.  In that case latex.trm would=20
> have become pointless.

It may well be that there is already no point in using latex.trm;
that was my other question :-)

Why this vehemence against color?  The same driver (latex.trm)
already emits emtex specials if asked.  Those was *are* marked
\special, and in fact I can't get the resulting file to do anything
reasonable when fed to teTeX.  Why is that OK but not color?

=2D-=20
Ethan A Merritt                                 Courier Deliveries: 1959 NE=
 Pacific
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: grouping available terminals together

[<HBB...@t-...>]

Ethan A Merritt wrote:

> Back to the topic of allowing color in LaTeX plots.  It seems perfectly
> reasonable to me.  

Unfortunately, Donald E. Knuth disagrees with that view.  TeX doesn't do 
colour, period.

Yes, some extensions of TeX using \special commands put into the DVI 
output file, do; as do variants of TeX such as pdftex.  But those are 
not TeX.

>> Hans-Bernhard Bröker wrote:
>>> The moment "set term latex" produces dvi files with \special in them,
>>> it becomes pointless to have it.
> 
> Could you elaborate, please?  Are you suggesting that only
> PostScript-based specials (pstricks, metapost, [e]pslatex, pstex) have
> any merit? 

No.  I'm pointing out that the whole reason for 'set term latex' to 
exist, given the much more feature-rich alternatives available, is that 
its output has a quality that none of the others can offer: it works 
with *every* valid TeX implementation, no matter how old, no matter how 
strange.  The price for this feature is that the capabilities are rather 
severely limited.  If we break this feature, there'll be no point left 
to use latex.trm instead of epslatex.trm.  In that case latex.trm would 
have become pointless.

Once we start adding features to latex.trm that require extensions or
\specials, there would be no good point at which to stop this move short 
of re-inventing epslatex.  So let's not go there.

 > Why would it be "pointless" to allow color in other LaTeX
> output via color.sty?

No.

Re: dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

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

Daniel J Sebald wrote:

> No, I didn't mean DPI, more a relative sort of thing.  I believe what
> I meant, after thinking a bit, is dots-per-"show ticscale" on the
> test image.  So, yeah I guess that is scale.

Clarification: meaning there is no need for this "resolution #" thing I first proposed; dots-per-"show ticscale" already accomplishes that.  But yes, scale that Ethan referred to controls thickness of lines, size of symbols, etc. (relative to that "show ticscale" length in the test pattern, I'd argue).

Dan

Re: dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

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

Ethan A Merritt wrote:
> On Sunday 11 February 2007 21:25, Daniel J Sebald wrote:
> 
>>>However, it would be nice to set DPI somehow through GD.  
>>>It would simplify things when I import images into Word or PowerPoint. 
>>
>>Well, that isn't too difficult, is it?
> 
> 
> Actually, it is.
> 
> The PNG standard does not provide a place to store dpi.
> Some apps store it in a comment record, but that is idiosynchratic,
> and anyhow gd does not (yet) support comment records in PNG.

OK...

Dan

Re: dashed lines with GD [ was Re: symbol/color/line consistency =?iso-8859-1?q?in=09terminals=5D?=

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

On Sunday 11 February 2007 21:25, Daniel J Sebald wrote:
> 
> > However, it would be nice to set DPI somehow through GD.  
> > It would simplify things when I import images into Word or PowerPoint. 
> 
> Well, that isn't too difficult, is it?

Actually, it is.

The PNG standard does not provide a place to store dpi.
Some apps store it in a comment record, but that is idiosynchratic,
and anyhow gd does not (yet) support comment records in PNG.

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

Re: dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

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

m sutton wrote:
>> Message: 6 Date: Sat, 10 Feb 2007 11:37:47 -0800 From: Ethan A
>> Merritt <merritt@u.washington.edu> Subject: Re: symbol/color/line
>> consistency in terminals To: gnu...@li... Cc:
>> Daniel J Sebald <dan...@ie...> Message-ID:
>> <200702101137.47710.merritt@u.washington.edu> Content-Type:
>> text/plain;  charset="iso-8859-1"
>> 
>> On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
>> 
>>> Hans-Bernhard Br?ker wrote:
>>> 
>>>>> That's because GD, last I looked, didn't support linewidths
>>> 
>>> on patterned > lines.  Which made it rather pointless to try and
>>>  implement dashing for > the first three.
>>> 
>>> I'm not real familiar with GD, but the header file has:
>>> 
>>> gdImageSetStyle (); gdImageSetThickness ();
>> 
>> Take my word for it, the gd routines for dashed lines and for 
>> linewidth are useless for our purposes.
> 
> 
> I was looking at just this issued over the past week or so.  I wanted
> to make the grid lines thicker for the GD terminal.  I found some odd
> behavior when using gdImageSetStyle  and gdImageSetThickness
> together.
> 
> The pixels are not drawn in the order I expected.  I think the style
> setting will have to set uniquely for each line width.  The style may
> even have to be adjusted for horizontal and vertical lines.

Well, I agree with that fact.  But I'm not sure I can exactly say what the rule should be.  (x11 has similar issues to PNG, but symbols scale accordingly x11.)  In any case, I think it is a lot of work to keep straight so writing a patch would need a solid concept...  Guess I'm not willing to try that much at the moment.


>>Say there were a "resolution #" option that would internally scale 
>>line thickness, pointsize, and fonts (have to have a mapping to 
>>medium, large, giant... unfortunately the largest font doesn't have 
>>very high resolution).
> 
> 
> At first I thought you meant resolution to be dots per inch (DPI).  But I think you really mean scaling as Ethan has elaborated on.

No, I didn't mean DPI, more a relative sort of thing.  I believe what I meant, after thinking a bit, is dots-per-"show ticscale" on the test image.  So, yeah I guess that is scale.


> However, it would be nice to set DPI somehow through GD.  It would simplify things when I import images into Word or PowerPoint.

Well, that isn't too difficult, is it?  If you know the the size in inches of the figure in the document and the DPI of the document you can calculate size and specify that at the "set term" option.  Or does it work the other way?  That there is a DPI value in the PNG file so that Word/PowerPoint can resample the figure?

Dan

Re: symbol/color/line consistency in terminals

[m s. <mw...@us...>]

>=20
> Message: 3
> Date: Sun, 11 Feb 2007 02:22:02 -0600
> From: Daniel J Sebald <dan...@ie...>
> Subject: Re: symbol/color/line consistency in terminals
> Cc: gnu...@li...
> Message-ID: <45C...@ie...>
> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed
>=20
> So, it seems to me that with PNG one is inherently restricted to=20
> low resolution plots.  One could argue it is for network graphics,=20
> but still 1000x1000 in a compact format like PNG doesn't seem=20
> excessive.

I agree.  I use 1280x1024 as my default size to match full screen projectio=
n for PowerPoint.

>=20
> Say there were a "resolution #" option that would internally scale=20
> line thickness, pointsize, and fonts (have to have a mapping to=20
> medium, large, giant... unfortunately the largest font doesn't have=20
> very high resolution).

At first I thought you meant resolution to be dots per inch (DPI).  But I t=
hink you really mean scaling as Ethan has elaborated on.

However, it would be nice to set DPI somehow through GD.  It would simplify=
 things when I import images into Word or PowerPoint.

Mike Sutton


=3D
Search for products and services at:=20
http://search.mail.com

dashed lines with GD [ was Re: symbol/color/line consistency in terminals]

[m s. <mw...@us...>]

> Message: 6
> Date: Sat, 10 Feb 2007 11:37:47 -0800
> From: Ethan A Merritt <merritt@u.washington.edu>
> Subject: Re: symbol/color/line consistency in terminals
> To: gnu...@li...
> Cc: Daniel J Sebald <dan...@ie...>
> Message-ID: <200702101137.47710.merritt@u.washington.edu>
> Content-Type: text/plain;  charset=3D"iso-8859-1"
>=20
> On Saturday 10 February 2007 11:28, Daniel J Sebald wrote:
> > Hans-Bernhard Br?ker wrote:
> > > > That's because GD, last I looked, didn't support linewidths=20
> > on patterned > lines.  Which made it rather pointless to try and=20
> > implement dashing for > the first three.
> >
> > I'm not real familiar with GD, but the header file has:
> >
> > gdImageSetStyle ();
> > gdImageSetThickness ();
>=20
> Take my word for it, the gd routines for dashed lines and for
> linewidth are useless for our purposes.

I was looking at just this issued over the past week or so.  I wanted to ma=
ke the grid lines thicker for the GD terminal.  I found some odd behavior w=
hen using gdImageSetStyle  and gdImageSetThickness  together.

The pixels are not drawn in the order I expected.  I think the style settin=
g will have to set uniquely for each line width.  The style may even have t=
o be adjusted for horizontal and vertical lines.

Mike Sutton


=3D
Search for products and services at:=20
http://search.mail.com

linewidth missing from gnuplot.doc?

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

gnuplot> help style line
 The `lines` style connects adjacent points with straight line segments.
 See also `linetype`, `linewidth`, and `linestyle`.

gnuplot> help linewidth
Sorry, no help for 'linewidth'
gnuplot>


Should there be a gnuplot.doc entry for linewidth?

Dan

Re: "set scale" as opposed to "set size" or something else

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

On Sunday 11 February 2007 17:10, Daniel J Sebald wrote:
> > 
> > Not true.  It is scalable, just like the font size and the point size.
> 
> The dash pattern scale (i.e., length of space relative to thickness of line)
> should also scale along with the line is what I meant.  Otherwise quality would be poor. 

That is exactly what it does.  Please try it before criticizing.

	set term post mono dash dashlength 10 linewidth 10
	set output 'fat_lines.ps'
	set yrange [0:12]
	plot for [i=1:10] i

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

Re: "set scale" as opposed to "set size" or something else

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

Ethan A Merritt wrote:
> On Sunday 11 February 2007 16:05, Daniel J Sebald wrote:
> 
>>If we want to carry the idea of consistent line patterns across 
> 
> terminals, that means that 1,2,3,4,5,6 example in "test" would always also 
> have to look about the same relative to "ticscale".
> 
> Not true.  It is scalable, just like the font size and the point size.

The dash pattern scale (i.e., length of space relative to thickness of line) should also scale along with the line is what I meant.  Otherwise quality would be poor.

Dan

Re: "set scale" as opposed to "set size" or something else

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

On Sunday 11 February 2007 16:05, Daniel J Sebald wrote:
> If we want to carry the idea of consistent line patterns across 
terminals, that means that 1,2,3,4,5,6 example in "test" would always also 
have to look about the same relative to "ticscale".

Not true.  It is scalable, just like the font size and the point size.

> We couldn't just set the pattern for the library to 011101 (dash-dot), in 
some instances we'd have to set it to 001111100011, i.e., change pattern 
scale (that is, resample the pattern somehow).  Not as easy as it looks 
and I think that is what Ethan was getting at--correct me if I'm wrong. 

I don't recall saying anything about it at all, other than pointing out
this was already under the control of "set term ... dashlength <foo>".
If you want to scale it up or down with the terminal size, you just say so.

(The emf terminal seems to be missing this feature. I don't know whether
that's because nobody noticed, or because the emf protocol makes it hard).



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

Re: grouping available terminals together

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

On Sunday 11 February 2007 15:22, you wrote:
> I just don't understand why there seems to be some sort of opposition
> for the same thing with dash patterns...

Opposition?  I thought it was more a case of nothing to work with.

How many terminal types are capable of defining dash patterns at all?
So far as I know, the list is basically emf, post, pdf, and x11.
And LaTeX, I suppose, but the usable TeX terminal variants are piggy-backing
on postscript.  

post and pdf already use the same dash patterns.

emf uses a completely different approach:
	for (i=0; i<ndashpatterns; i++)
	for (j=0; j<ncolors; j++)
		use color j and dashpattern i;

There are patches floating around that use a scheme similar to emf
for postscript as well (e.g.  http://www.h2.dion.ne.jp/~yamaga/gnuplot/)
so I guess there at least some users who prefer it.

Dashes for screen terminals are pretty useless, but you can define the
ones for x11 however you like.

So I guess I am puzzled as to exactly what you are asking for.
Is it just a decision about whether the emf terminal should be changed
to mimic the post/pdf terminals?  Are you concerned that other screen-based
terminals do not support dashes? (I see no reason that they should, but if
someone wants to add it, I guess it wouldn't hurt any).



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

Re: "set scale" as opposed to "set size" or something else

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

Ethan A Merritt wrote:
> On Sunday 11 February 2007 00:22, Daniel J Sebald wrote:
> 
>>set term png size 1280,960
>>
>>the result is a 1280 x 960 PNG image with the same resolution as the 
>>previous 640 x 480 PNG image.  That is, depending on one's viewpoint, 
>>it's as though every plot item has become 1/2 the size relative to 
>>the plot coordinate system.   
>>I could increase resolution by making the pointsize twice 
>>as big, line thickness twice as big, etc.
> 
> 
> I believe that this was the original intent of the "set size" command.
> It later got co-opted to implement multiplot mode instead.
> The original terminal entry point  term->scale() is still there, however.
> 
> It is interesting that Timothée recently submitted a patchset (#1616945)
> to remove this terminal entry, and now you are arguing in effect that
> we whould intead resurrect it for its original purpose.  
> 
> So if I may re-phrase your suggestion.  We should add a command
> 	set scale <multiplier>
> that is passed to each terminal.  Terminals capable of uniform scaling
> would apply this multiplier to relevant plot elements, including
> 	font size
> 	point size
> 	line width
> 	dash length
> 
> This is not strictly necessary, as all of these can be set separately
> for terminals that support them.  But it would add some degree of 
> convenience.

Yes, that is about right.  However, I'm not sure if the above list covers border line thickness, etc.  Anyway...

Reflecting on this, the parameters you listed should be units relative to the screen (plot?).  That is, what would be nice is to strive for sizes to always match the "ticscale" (relatively speaking) on the test pattern from one terminal to another.  If I change the number of pixels in the PNG image from 640,480 to 1280,960 the little marks at the top center of the test pattern stay about the same.  OK, so those little marks sort of correspond to the unit size on a screen when it comes to laying out borders.

The elements that remains roughly the same size relative to the screen are the hexagon and the patterns.  Fonts and line widths do not.  I guess I'm arguing they should attempt to do so.  (If one has to fall back on the fixed point fonts, it's a problem... but so be it.)

Some comments (that may be obvious):  If we do something like this:

  set term png font "courb,12" size 640,480

the 12 of "<font>,12" inherently sets "set font size" based upon the resoultion 640x480.  Vice-versa, "set font size" inherently sets "<font>,???".  Seems obvious, but what I'm saying is that "<font>,#" is extraneous (maybe not?) if we have an understanding that "pointsize", etc. is always relative to "ticscale".

[Timothée, note this part.]  So, what is the ramification for the line patterns?  Well, if we want to carry the idea of consistent line patterns across terminals, that means that 1,2,3,4,5,6 example in "test" would always also have to look about the same relative to "ticscale".  We couldn't just set the pattern for the library to 011101 (dash-dot), in some instances we'd have to set it to 001111100011, i.e., change pattern scale (that is, resample the pattern somehow).  Not as easy as it looks and I think that is what Ethan was getting at--correct me if I'm wrong.


> [nit-picking follows]

Well, there's my usual dash of inate confusion...

> 
> 
>>Say there were a "resolution #" option that would internally scale line 
> 
> thickness, pointsize, and fonts (have to have a mapping to medium, large, 
> giant... unfortunately the largest font doesn't have very high 
> resolution).
> 
> What is this "medium, large, giant" business?  
> Surely you are not still using the old 1999 PNG driver!

Yes, I knew that.  When in doubt, try "helvetica".  (Didn't work...)

I've read now and understand the fonts.  Hey, any interest in using opendir() and readdir() to scan through the files in the font directories for the file names (and search those that have an internal ASCII name) to list available fonts, e.g.,

show fonts

??  Could use file name completion or something to limit the list:

show fonts "*elvetica*"

Dan