[Pkg-octave-devel] Bug#478677: Bug#478677: Bug#478677: Bug#478677: print('foo.pdf', '-dpdf') fails

Thomas Weber thomas.weber.mail at gmail.com
Wed May 21 09:02:43 UTC 2008


Am Mittwoch, den 21.05.2008, 10:55 +0200 schrieb Soeren Sonnenburg:
> On Wed, 2008-05-21 at 10:49 +0200, Thomas Weber wrote:
> > Am Donnerstag, den 01.05.2008, 10:59 +0200 schrieb Thomas Weber:
> > > On 30/04/08 15:15 +0200, Rafael Laboissiere wrote:
> > > > * Thomas Weber <thomas.weber.mail at gmail.com> [2008-04-30 13:21]:
> > > > > gnuplot needs pdflib to produce PDF output. pdflib's license is
> > > > > non-free. 
> > > > > 
> > > > > Which raises the question: did this ever work?
> > > > > 
> > > > > [looking through BTS ...] => #248426
> > > > 
> > > > This explains the problem, but I think that we still ought to fix print.m,
> > > > whose documentation ("help print") lists PDF as a possible output format and
> > > > yields the cryptic error message "unknown or ambiguous terminal type".
> > > 
> > > To be fair, it prints a line with a pointer right at the "pdf" part.
> > > 
> > > > If I have some time next week I will try to create a patch for fixing this.
> > > 
> > > How to fix it? I think dropping the 'pdf' part from print()'s help
> > > string should suffice, shouldn't it?
> > 
> > I like to fix this bug with the next upload. Now, how to fix it:
> > dropping the pdf part from the documentation? I don't want to change the
> > actual code, people may want to compile both pdflib and gnuplot
> > themselves.
> 
> I guess it is sufficient to add a note to help print that says that pdf
> support is not available in gnuplot... hmmhh but maybe it is gnuplot
> that could give a more reasonable error here.

That might be an option, but as Octave is on its way away from gnuplot,
I don't want to spend to much time with it ...

	Thomas






More information about the Pkg-octave-devel mailing list