Menu
▾
▴
gnuplot-beta
|
From: Harald H. <h.h...@tu...> - 2005-02-14 19:30:06
|
On Mon, 14 Feb 2005, Ethan Merritt wrote: > On Monday 14 February 2005 09:28 am, Harald Harders wrote: > > > > Have you had a look at the header that is produced by gnuplot when using > > 'standalone'? It's not that easy to write it. It automatically selects the > > same fontsize for the output as the plot uses for calculating space of > > text. It sets the correct page size for dvips, VTeX, and pdflatex (which > > really is hard to do by hand for pdflatex). > > Isn't that just a really convoluted way to "set term pdf" ? > Why go through latex at all if you really want a pdf plot? The pdf term is _really_ much inferior to all postscript-based terminals. I have always been using the options rounded, dashlength, linewidth, monochrome|colour. And I am using different fonts than the core PDF fonts. Thus, I cannot use the pdf terminal at all. In addition, the full LaTeX syntax for text is really nice, far better than the enhanced text support of gnuplot. When -- in future -- the pdf terminal may support everything the postscript terminal already supports I will think of using the pdf terminal. Regards Harald -- Harald Harders h.h...@tu... http://www.harald-harders.de |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-14 20:36:22
|
On Monday 14 February 2005 11:31 am, Harald Harders wrote: > > The pdf term is _really_ much inferior to all postscript-based terminals. > I have always been using the options rounded, dashlength, linewidth, > monochrome|colour. And I am using different fonts than the core PDF fonts. > Thus, I cannot use the pdf terminal at all. The pdf term already supports fonts and linewidth just fine. Adding "rounded | butt" as a terminal option took me all of 10 minutes; I'll add it to cvs after confirming backward compatibility with the older versions of libpdf. I see no particular problem with adding dashes as well, that fits in with the current plan of adding dot/dash support as a general feature. What else was it that you needed? > When -- in future -- the pdf terminal may support everything the > postscript terminal already supports I will think of using the pdf > terminal. That future may be as soon as next week depending on what you mean by "everything". -- Ethan A Merritt merritt@u.washington.edu Biomolecular Structure Center Mailstop 357742 University of Washington, Seattle, WA 98195 |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-14 21:14:52
|
On Monday 14 February 2005 01:03 pm, Harald Harders wrote:
>
> Everything postscript also supports:
>
> blacktext | colortext | colourtext
trivial (also IMHO useless, but whatever)
> color | colour | monochrome
this might be the only tricky one
> solid | dashed (you already mentioned it, they and the point types should
> be compatible to postscript)
> dashlength | dl <DL>
no problem, but I think it should wait for the general syntax on
dot/dash to be sorted out
> palfuncparam <samples>{,<maxdeviation>}
sorry, I don't know what that one does. Petr?
Is there any reason this should be a terminal-specific function?
> Arbitrary fonts (other than the 35 basic pdf fonts) similar to the
> postscript fontfile option, for example CMR10 provided in cmr10.pfb ...
Works fine for me.
The problem may be in your viewer, not in gnuplot+pdflib.
I'm assuming you know about the configuration file
(/usr/local/share/pdflib.upr or whereever it got installed)
that defines font locations.
> One feature will never be supported by any terminal that does not work
> together with LaTeX: Full LaTeX command support and the superior LaTeX
> typesetting quality. The already good enhanced text support will never
> reach LaTeX. Thus, my strange way to produce pdf will stay useful for me.
I suppose it depends on how much text is contained inside your plots.
I have been perfectly happy with importing *.eps plots produced by
'set term post eps' into LaTeX documents.
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Petr M. <mi...@ph...> - 2005-02-15 07:37:40
|
> > palfuncparam <samples>{,<maxdeviation>}
>
> sorry, I don't know what that one does. Petr?
> Is there any reason this should be a terminal-specific function?
All terminals, except for postscript, use sth like
R,G,B = getRgbColor()
term->set_color(R,G,B)
in postscript, it has its own "formula expression" written in postscript
instead of getRgbColor(). That "palfuncparam" sets its sampling for color
formulae provided as linear gradients.
So, it's really just for postscript.
---
PM
|
|
From: Ethan M. <merritt@u.washington.edu> - 2005-02-15 16:35:45
|
On Monday 14 February 2005 11:37 pm, you wrote: > > in postscript, it has its own "formula expression" written in postscript > instead of getRgbColor(). That "palfuncparam" sets its sampling for > color formulae provided as linear gradients. > > So, it's really just for postscript. But wouldn't pdf want to do the same thing? Or x11 for that matter. In both cases there is plenty of processing power available at the display end if there is a good reason to use it. -- Ethan A Merritt Biomolecular Structure Center University of Washington 98195-7742 |
|
From: Petr M. <mi...@ph...> - 2005-02-16 08:05:05
|
> > in postscript, it has its own "formula expression" written in postscript > > instead of getRgbColor(). That "palfuncparam" sets its sampling for > > color formulae provided as linear gradients. > > > > So, it's really just for postscript. > > But wouldn't pdf want to do the same thing? > Or x11 for that matter. Not necessary, it is much easier to pass r,g,b triplet or gray value ... actually, gnuplot_x11 is including getcolor.c, so it already does a similar thing. > In both cases there is plenty of processing power available at the display > end if there is a good reason to use it. No good reason for pdf I think. For postscript it is clear -- file size -- every byte counts (mainly if it appears 100^2 times). Petr |
