Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2007-02-11 23:13:44
|
> 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 That would be cool for subfigures. --- PM |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-02-10 22:21:48
|
On Saturday 10 February 2007 08:04, Mojca Miklavec wrote: > > At the very bottom of > http://sourceforge.net/tracker/download.php?group_id=2055&atid=302055&file_id=215003&aid=1654807 > you can see which symbols I used for ConTeXt > {\scale[scale=800]{$+$}}, > {\scale[scale=800]{$\times$}}, > $\ast$, > {\scale[scale=700]{$\square$}}, > {\scale[scale=700]{$\blacksquare$}}, > $\circ$, > $\bullet$, > {\scale[scale=900]{$\triangleup$}}, > {\scale[scale=900]{$\blacktriangle$}}, > {\scale[scale=900]{$\triangledown$}}, > {\scale[scale=900]{$\blacktriangledown$}}, > {\scale[scale=800]{$\lozenge$}}, > {\scale[scale=800]{$\blacklozenge$}}%, Yes, thanks. I found these in a grand compendium of LaTeX symbols after my earlier post. We ended up with the same choices, except for \square (which comes out a different size than \blacksquare). > I would suggest to put something like > > \def\GnuplotSymbol#1{\ifcase#1 \GpSymI \or \GpSymII \or \GpSymIV \or > \GpSymV \or \GpSymVI \or \GpSymVII ... \fi } > > and then > > \def\GpSymI{$+$} % perhaps including the scale somewhere > \def\GpSymII{$\times$} > \def\GpSymIII{$\ast$} > ... etc. Similar to the PostScript prologue. Yes, that is not a bad idea. The logical next step would be to create an actual gnuplot package for TeX so that the user would do \usepackage{gnuplot} -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Mojca M. <moj...@gm...> - 2007-02-11 04:14:45
|
On 2/10/07, Ethan A Merritt wrote:
>
> The logical next step would be to create an actual gnuplot package
> for TeX so that the user would do \usepackage{gnuplot}
Sure, but there has to be a good reason first (ie. enough
functionality provided). Solely for the reason of defining the
thirteen points types, it's not worth the problems. (Keep in mind that
the only reasonble way of having the solution work out-of-the-box is
to have the package on CTAN, not shipped with gnuplot, since shipping
the file with gnuplot needs an extra "installation" first - and you
might end up with the same question that you once asked me: what if
one has older gnuplot and newer TeX distribution or newer gnuplot and
older TeX)
But I still support having a gnuplot.sty if one can think of enough
ideas to implement in that package, so that it will be "worth the
problems".
There is already a package "gnuplottex". With it one can do
\begin{gnuplot}
plot sin(x)
\end{gnuplot}
and it will run gnuplot automatically (with terminal "latex") and
include the resulting file (one needs write18 enabled and gnuplot in
PATH). Also, TikZ has an interesting module which passes a function to
gnuplot and runs it, but only to get the values of the function back:
it draws the result on it's own then.
Perhaps extentions to gnuplottex might make sense, again, if one has
ideas what to do. The package is rather new.
Mojca
|
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-02-11 19:23:39
|
On Sunday 11 February 2007 03:16, Timoth=E9e Lecomte wrote:
>=20
> But do we want gnuplot to stay at what was the least-common denominator=20
> 20 years ago ? How many people use gnuplot right now for pen plotters ?
> And since we provide rgb colors, why not doing the same with other kind=20
> of "modern" features ?
I have been working for some time now to add exactly this capability for
RGB color, explicit fonts, choice of symbols for plotting, and so on.
And you know what? In version 4.2 we are already about 90% of the way
to exactly what you want.
In particular, if you have not already done so, please take time out to
investigate the new mechanism for replacing the fixed set of line "types"
with an arbitrary set of line "styles". This allows you to choose any
sequence of colors, line widths, point types, etc, and have those used
in preference to the default set. Furthermore, it is implemented in=20
such a way that old command scripts "just work", even thought they are
unaware of the new set of line properties being used. =20
The operative command is
set style increment user
I must admit that I hate that syntax. Suggestions for a more obvious
command are welcome.
Back to the topic of allowing color in LaTeX plots. It seems perfectly
reasonable to me. Just as with the post, emf, pbm terminals there would
be a choice of {monochrome|color} when you select the terminal. If you
don't want color in your TeX document, then don't select it.
I am inclined to agree with Timoth=E9e and Mojca. We should either update
the latex driver to the extent possible or deprecate it altogether.
> Hans-Bernhard Br=F6ker 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? Why would it be "pointless" to allow color in other LaTeX
output via color.sty?
Mind you, I myself do not see much point in using the current latex
terminal at all. The curve-drawing is terrible, the list of features is
minimal, and I am unaware of any practical benefit that comes from=20
avoiding the more feature-complete epslatex pathway. But I may be=20
ignorant of some major category of use.
=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Petr M. <mi...@ph...> - 2007-02-11 23:44:11
|
> Back to the topic of allowing color in LaTeX plots. It seems perfectly
> reasonable to me. Just as with the post, emf, pbm terminals there would
> be a choice of {monochrome|color} when you select the terminal. If you
> don't want color in your TeX document, then don't select it.
Exactly. The options for the latex terminal can be "rotate" and "color". I=
=20
remember times I was using latex terminal and I had to put those \rotate=20
commands for the y-axis myself.
> I am inclined to agree with Timoth=C3=A9e and Mojca. We should either upd=
ate
> the latex driver to the extent possible or deprecate it altogether.
Nowaday, latex terminal is useful for simple drawings. It's easier than=20
learning diagram latex packages.
---
PM |
|
From: <HBB...@t-...> - 2007-02-12 20:36:35
|
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. |
|
From: Ethan M. <merritt@u.washington.edu> - 2007-02-12 21:14:45
|
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
|
|
From: Mojca M. <moj...@gm...> - 2007-02-12 21:39:54
|
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]
|
|
From: Daniel J S. <dan...@ie...> - 2007-02-12 22:06:59
|
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
|
|
From: Ethan M. <merritt@u.washington.edu> - 2007-02-13 19:43:33
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-02-13 19:48:38
|
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! :-) |
|
From: <tim...@en...> - 2007-02-11 23:26:49
|
Ethan A Merritt wrote: > On Sunday 11 February 2007 03:16, Timothée Lecomte wrote: > >> But do we want gnuplot to stay at what was the least-common denominator >> 20 years ago ? How many people use gnuplot right now for pen plotters ? >> And since we provide rgb colors, why not doing the same with other kind >> of "modern" features ? >> > > I have been working for some time now to add exactly this capability for > RGB color, explicit fonts, choice of symbols for plotting, and so on. > And you know what? In version 4.2 we are already about 90% of the way > to exactly what you want. > and that's very good to see. Congrats to you for that. I just don't understand why there seems to be some sort of opposition for the same thing with dash patterns... Best regards, Timothée |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-02-12 00:12:29
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-02-11 23:53:43
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-02-12 00:41:12
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-02-12 00:59:07
|
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 |
|
From: Ethan A M. <merritt@u.washington.edu> - 2007-02-12 01:09:19
|
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 |
|
From: Daniel J S. <dan...@ie...> - 2007-02-13 19:40:27
|
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
|
|
From: Daniel J S. <dan...@ie...> - 2007-02-14 08:58:25
|
Daniel J Sebald wrote:
> 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
Oh, that's single quotes, I use double quotes... (double oy).
Dan
|
|
From: Mojca M. <moj...@gm...> - 2007-02-14 12:55:50
|
On 2/13/07, Daniel J Sebald wrote:
> While on the topic if LaTeX related terminals, here's a few comments
>
> 2) In the documentation are these examples:
>
> Use gnuplot defaults (mostly sensible, but sometimes not really best):
> set title '\LaTeX\ -- $ \gamma $'
>
> 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 $'
No, either
set label '{\LaTeX\ -- $ \gamma $}' at 0,0
or
set label "{\\LaTeX\\ -- $ \\gamma $}" at 0,0
Note the difference between single and double quote.
> 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.)
I'm not sure if I understood the question, but in LaTeX there's a big
problem, because alignment usually doesn't work properly. If you write
'\varepsilon^{2}', gnuplot will reserve 15 characters of space, but
you need less than two. The examples above show how to overcome this
problem.
> 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?
What would be the difference between "titlesize" and the size of the
font that you specify in the header?
Which font sizes are you planning to map to which LaTeX commands??? I
don't think that's good idea. In that case it might make more sense to
simply scale the title (if you assume that the font size is 10pt and
user asks for 16pt, you scale it to 160%). I bet there there are some
packages which allow you to specify font size explicitly, but fonts
have a high tendency to change (at least their names, if not the
format) and to become obsolete. Perhaps you don't notice that, but
just for example ... the euro symbol in ConTeXt is broken on TeXLive
this year, because the author has changed the font name and nobody
spotted that until it was too late.
In the ConTeXt terminal I pass the font string almost literally to
ConTeXt (I needed to add "pt" or some other explicit measure next to
font size - actually one of the ugliest part of the code). Saying
\switchtobodyfont[somename,16pt] works there, but I don't know about
LaTeX.
True, labels are not truly compatible between (La)TeX/ConTeXt and
other terminals, but they won't even be for some time and I would
expect the users to be aware of that:
- if you ever tried or will try to run some demos with the LaTeX
terminal, you'll see that appoximately half of the demo files will
fail because there is %, _, ^ or $ present in text labels.
- if someone decides to use LaTeX labels, he's probably also planning
to type {\bf ...}, $\alpha$, $\gamma$ or similar commands. And those
will fail with other terminals as well. I also use utf-8, which
doesn't work with ps.
Mojca
|
