Menu
▾
▴
gnuplot-beta
|
From: Petr M. <mi...@ph...> - 2009-06-05 08:15:53
|
> > > >printing to pdfcairo > > > > > > > >plot(1:100) > > > >print -dpdf z.pdf > > > >print -dpdfcairo zz.pdf > > > > > > > >... the output file is called pdfcairo:zz.pdf > > > > > >This behavior is intended. > > > >This will certainly *not* work under windows, since the colon is not a valid > >filename character. It actually designates the streams associated with a > >file. So it might not issue an error (haven't checked) but then very subtly > >misbehave. > > > >This should be fixed. > > > >benjamin > > > Recently this behavior was removed. Octave had been using "convert" (from > imagemagick) to produce alternative formats. This is now done using > ghostscript. Specifically, when a terminal is specified that is not > supported/recognized, it is assumed that ghostcript is to be used to convert > to the specified format. As the cairo terminals are not explicitly supported, > specifying -pdfcairo produces a ghostscript error when using the developers > sources. > > The pdfcairo and pngcairo terminals could be supported, but are not supported > at this time. > > Petr, what are the benefits of the pdfcairo and pngcairo terminals over the > pdf and png terminals? Usually the (original) pdf terminal is not compiled in because of license issues. pdfcairo and pngcairo are automatically compiled in if the system has cairo library (available as a package for most linux distributions, for example). I think that the cairo terminals handle UTF-8 text correctly. I gave cc: to gnuplot list so that somebody can explain the difference in more details. --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-06-05 14:54:21
|
On Jun 5, 2009, at 5:45 AM, Petr Mikulik wrote: >>> issues. pdfcairo and pngcairo are automatically compiled in if the >>> system >>> has cairo library (available as a package for most linux >>> distributions, for >>> example). >>> >>> I think that the cairo terminals handle UTF-8 text correctly. >>> >>> I gave cc: to gnuplot list so that somebody can explain the >>> difference in >>> more details. >> >> Are there any license problems with the plain png terminal, or is >> it just the >> pdf? > > png is fine, it uses gd library > >> Presently, when the pdf terminal is specified, the print() function >> checks >> with gnuplot to determine if the "pdf" terminal is supported. If >> not, or >> unknown, print() checks for the presence of ghostscript. If >> present, the ps >> terminal is used to produce a ps-file and then ghostscript is used >> to convert >> to pdf. > > I wonder whether "set term pdf" is used if "set term" shows > "pdfcairo" but > not "pdf"? I'm confused by your question. Do you suggest that "pdfcairo" be used in the event that "pdf" is not present". Personally, I like the ghostscript solution, but these are not necessarily mutually exclusive. In any event, please clarify. Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-06-05 15:10:39
|
On Friday 05 June 2009, Ben Abbott wrote: > > I'm confused by your question. Do you suggest that "pdfcairo" be used > in the event that "pdf" is not present". Personally, I like the > ghostscript solution, but these are not necessarily mutually exclusive. I would recommend to use pdfcairo even if "pdf" _is_ present. Or, as I said in a separate post, the new tikz terminal (but that requires having pdflatex installed). Ethan |
|
From: Petr M. <mi...@ph...> - 2009-06-05 15:24:49
|
> >I wonder whether "set term pdf" is used if "set term" shows "pdfcairo" but > >not "pdf"? > > I'm confused by your question. Do you suggest that "pdfcairo" be used in the > event that "pdf" is not present". Personally, I like the ghostscript solution, > but these are not necessarily mutually exclusive. What do you mean by "pdf is not present but pdfcairo is present"? If either of pdflib or pdfcairo libraries are compiled with gnuplot, then in both cases set term pdf sets the output to pdf. There is no "different" command. The command set term shows that there is "pdfcairo" terminal which is the full name of the new pdf terminal, i.e. set term pdfcairo can be used as well. So, how does Octave know/detect whether gnuplot has/has not pdf (any) terminal? --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-06-05 15:23:33
|
On Jun 5, 2009, at 11:02 AM, Ethan Merritt wrote: > On Friday 05 June 2009, Ben Abbott wrote: > >>>> Petr, what are the benefits of the pdfcairo and pngcairo terminals >>>> over the pdf and png terminals? > > Aside from licensing issues for PDFLib, using cairo to generate the > plots > allows antialiasing, transparency, and UTF-8 support. Ok, the pdfcairo sounds like it should be our default choice. >> Are there any license problems with the plain png terminal, or is it >> just the pdf? > > The "plain png" terminal has not been supported for about 8 years now. > Instead the default is to use libgd, and the newer option is to use > cairo. None of these has any licensing issues that I am aware of. Ok. What syntax is needed to access the libgd version of png? >> Presently, when the pdf terminal is specified, the print() function >> checks with gnuplot to determine if the "pdf" terminal is supported. >> If not, or unknown, print() checks for the presence of ghostscript. >> If >> present, the ps terminal is used to produce a ps-file and then >> ghostscript is used to convert to pdf. > > Going through an intermediate postscript file is non-optimal, because > PostScript itself does not support transparency or UTF-8 characters. > At least from the perspective of plot quality, this is probably the > least satisfactory of several options. > It would be better to use either pdfcairo or the brand new tikz > terminal. > > Does Octave have a confguration file or configuration menu that the > user can find easily? I suggest to make the production of pdf > output a > user-configurable choice. > PDF output via (select one) > --> pdf (let gnuplot choose for you) > --> pdfcairo > --> tikz / pdflatex > --> PostScript / ps2pdf Such a configuration capability is not present in Octave's sources. However, how do we let gnuplot choose for us (I like this approach) ? Ben |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-06-05 15:55:23
|
> > Does Octave have a confguration file or configuration menu that the > > user can find easily? I suggest to make the production of pdf > > output a > > user-configurable choice. > > PDF output via (select one) > > --> pdf (let gnuplot choose for you) > > --> pdfcairo > > --> tikz / pdflatex > > --> PostScript / ps2pdf > > > Such a configuration capability is not present in Octave's sources. > > However, how do we let gnuplot choose for us (I like this approach) ? That's what "set term pdf" does. It chooses either the PDFLib or cairo based pdf terminal depending one which is installed. If both are installed it currently defaults to using PDFLib, but it might make sense to change that. There is an unfortunate disconnect between the people who create/name new terminal drivers and the people who use them. The developer is understandably focused on the mechanism being used to create the file. The user only cares about the output. We're still at the tail end of a long back-and-forth about whether the new "driver that creates a pdf file by using gnuplot to create a lua script, lua to create a tikz script, and pdflatex to create a pdf file" should be called a lua terminal, a tikz terminal, or (new to the mix) a pdf terminal. There are legitimate points to be made for all three choices: - "lua" because hypothetically you could use the same terminal and same output file with other lua scripts to create some other output. - "tikz" because that is the TeX flavor being created by the existing script (parallel to the naming of the metapost and pstricks terminals) - "pdf" because at the end of the day that's probably what you will end up with. Context is important also, and it is hard for the program, either Octave or gnuplot, to know the user's ultimate intent. If you want a pdf plot for inclusion in a LaTeX document, then lua/tikz/pdflatex is the way to go. But if you have no LaTeX installed, which is common, then this is probably the worst choice. Ugh. That's why I advocate for providing the user with a configuration option. You still have to pick a default, but you do so knowing that it may be the wrong default for many users. |
|
From: Ben A. <bpa...@ma...> - 2009-06-05 15:36:03
|
On Jun 5, 2009, at 11:24 AM, Petr Mikulik wrote: >>> I wonder whether "set term pdf" is used if "set term" shows >>> "pdfcairo" but >>> not "pdf"? >> >> I'm confused by your question. Do you suggest that "pdfcairo" be >> used in the >> event that "pdf" is not present". Personally, I like the >> ghostscript solution, >> but these are not necessarily mutually exclusive. > > What do you mean by "pdf is not present but pdfcairo is present"? > If either of pdflib or pdfcairo libraries are compiled with gnuplot, > then in both cases > set term pdf > sets the output to pdf. There is no "different" command. The command > set term > shows that there is "pdfcairo" terminal which is the full name of > the new > pdf terminal, i.e. > set term pdfcairo > can be used as well. > > So, how does Octave know/detect whether gnuplot has/has not pdf (any) > terminal? Ok, it appears I'm confused. On Mac OSX both pdf and pdfcairo are listed in GPVAL_TERMINALS. Do I infer correctly that by selecting the "pdf" that gnuplot will use pdfcairo terminal driver? Regarding how we know what terminals are present we obtain a list from the GPVAL_TERMINALS variable. This is done in gnuplot_drawnow.m by ... available_terminals = __gnuplot_get_var__ (plot_stream, "GPVAL_TERMINALS"); Ben |
|
From: Petr M. <mi...@ph...> - 2009-06-05 15:45:41
|
> >So, how does Octave know/detect whether gnuplot has/has not pdf (any) > >terminal? > > Ok, it appears I'm confused. On Mac OSX both pdf and pdfcairo are listed in > GPVAL_TERMINALS. Do I infer correctly that by selecting the "pdf" that gnuplot > will use pdfcairo terminal driver? > > Regarding how we know what terminals are present we obtain a list from the > GPVAL_TERMINALS variable. This is done in gnuplot_drawnow.m by ... Thanks for clarifing this. The "pdf" is that of pdflib. I think that "pfdcairo" should be the preferred choice of pdf terminal if both "pdf" and "pdfcairo" are listed. Thus I propose for pdf output: - if "pdfcairo" is present => use "set term pdfcairo" - if "pdf" is present => use that - if none of them => use "set term postscript" + ps2pdf --- PM |
|
From: Ben A. <bpa...@ma...> - 2009-06-05 16:07:49
|
On Jun 5, 2009, at 11:55 AM, Ethan Merritt wrote: > >>> Does Octave have a confguration file or configuration menu that the >>> user can find easily? I suggest to make the production of pdf >>> output a >>> user-configurable choice. >>> PDF output via (select one) >>> --> pdf (let gnuplot choose for you) >>> --> pdfcairo >>> --> tikz / pdflatex >>> --> PostScript / ps2pdf >> >> >> Such a configuration capability is not present in Octave's sources. >> >> However, how do we let gnuplot choose for us (I like this approach) ? > > That's what "set term pdf" does. It chooses either the PDFLib or > cairo > based pdf terminal depending one which is installed. If both are > installed > it currently defaults to using PDFLib, but it might make sense to > change > that. > > There is an unfortunate disconnect between the people who create/name > new terminal drivers and the people who use them. The developer is > understandably focused on the mechanism being used to create the file. > The user only cares about the output. We're still at the tail end of > a long back-and-forth about whether the new "driver that creates a pdf > file by using gnuplot to create a lua script, lua to create a tikz > script, and pdflatex to create a pdf file" should be called a > lua terminal, a tikz terminal, or (new to the mix) a pdf terminal. > There are legitimate points to be made for all three choices: > > - "lua" because hypothetically you could use the same terminal and > same > output file with other lua scripts to create some other output. > - "tikz" because that is the TeX flavor being created by the existing > script (parallel to the naming of the metapost and pstricks terminals) > - "pdf" because at the end of the day that's probably what you will > end > up with. > > Context is important also, and it is hard for the program, either > Octave > or gnuplot, to know the user's ultimate intent. If you want a pdf > plot > for inclusion in a LaTeX document, then lua/tikz/pdflatex is the way > to > go. But if you have no LaTeX installed, which is common, then this is > probably the worst choice. > > Ugh. > > That's why I advocate for providing the user with a configuration > option. > You still have to pick a default, but you do so knowing that it may be > the wrong default for many users. I do plan to add the tikz terminal to octave as soon as it is patched to handle fonts better and I'm able to build again (presently my build fails due to an out-dated patch for Fink on Mac OSX). Regarding the various pdf terminals, it would be a simple matter to allow the user to choose what terminal he wishes, via ... print -dpdf file.dpf or print -dpdfcairo file.pdf However, Petr's suggestion is attractive. That being ... - if "pdfcairo" is present => use "set term pdfcairo ..." - if "pdf" is present => use "set term pdf ..." - if neither => use "set term postscript ..." and then convert using ghostscript Ben |
|
From: Allin C. <cot...@wf...> - 2009-06-06 14:30:02
|
On Fri, 5 Jun 2009, Ben Abbott wrote: > However, Petr's suggestion is attractive. That being ... > > - if "pdfcairo" is present => use "set term pdfcairo ..." > - if "pdf" is present => use "set term pdf ..." > - if neither => use "set term postscript ..." and then convert using > ghostscript That's what gretl (gretl.sourceforge.net) does, when calling gnuplot (well, minus the last bit, using gs). I would support making pdfcairo the default pdf terminal (which I think Ethan suggested). That is, if you have both cairo and pdflib support in gnuplot, then set term pdf would do the same as "set term pdfcairo", and you'd have to do, e.g., "set term pdflib" if you wanted pdflib to be used. (But of course if pdflib is supported but cairo is not, then "set term pdf" would be equivalent to "set term pdflib".) Allin Cottrell |
|
From: Benjamin L. <lin...@gm...> - 2009-06-05 18:11:01
|
Ethan Merritt wrote: > On Friday 05 June 2009, Ben Abbott wrote: > >>>> Petr, what are the benefits of the pdfcairo and pngcairo terminals >>>> over the pdf and png terminals? > > Aside from licensing issues for PDFLib, using cairo to generate the plots > allows antialiasing, transparency, and UTF-8 support. This may be a sutpid question, but what should a vector-based graphics description support antialiasing for? An output device, yes, but the graphics language? >> Are there any license problems with the plain png terminal, or is it >> just the pdf? > > The "plain png" terminal has not been supported for about 8 years now. > Instead the default is to use libgd, and the newer option is to use > cairo. None of these has any licensing issues that I am aware of. > >> Presently, when the pdf terminal is specified, the print() function >> checks with gnuplot to determine if the "pdf" terminal is supported. >> If not, or unknown, print() checks for the presence of ghostscript. If >> present, the ps terminal is used to produce a ps-file and then >> ghostscript is used to convert to pdf. > > Going through an intermediate postscript file is non-optimal, because > PostScript itself does not support transparency or UTF-8 characters. > At least from the perspective of plot quality, this is probably the > least satisfactory of several options. > It would be better to use either pdfcairo or the brand new tikz terminal. pdfcairo might be superior if you require transparency and UTF-8, granted, but the quality of the generated output is disappointing compared to pdf via postscript. I do a lot of image plots and found that the resulting file sizes with the pdfcairo terminal are 4-8 times larger than a ps->pdf output. Also you don't have good control over font selection, which is IMO a knock-out criteria when doing high-quality plots for e.g. latex inclusion. But it naturally involves an indirect step requiring ghostscript, thus being slightly more complicated than a simple pdfcairo output. So for the sake of simplicity it'll be good if octave's print would support the pdfcairo terminal, and for applications where quality detail matters (and you don't need features postscript can't give you) the ps-to-pdf-via-ghostscript is available. I also like the idea of the user being able to choose the method of pdf creation, but I wouldn't know how to implement it ad hoc. benjamin |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-06-05 20:09:41
|
On Friday 05 June 2009 11:12:52 Benjamin Lindner wrote: > Ethan Merritt wrote: > > On Friday 05 June 2009, Ben Abbott wrote: > > > >>>> Petr, what are the benefits of the pdfcairo and pngcairo terminals > >>>> over the pdf and png terminals? > > > > Aside from licensing issues for PDFLib, using cairo to generate the plots > > allows antialiasing, transparency, and UTF-8 support. > > This may be a sutpid question, but what should a vector-based graphics > description support antialiasing for? Ben asked about both pdfcairo and pngcairo. The anti-aliasing is an issue for png, not for pdf. Conversely, the transparency support is an issue for pdf but not for png. > pdfcairo might be superior if you require transparency and UTF-8, > granted, but the quality of the generated output is disappointing > compared to pdf via postscript. > I do a lot of image plots and found that the resulting file sizes with > the pdfcairo terminal are 4-8 times larger than a ps->pdf output. Also > you don't have good control over font selection, which is IMO a > knock-out criteria when doing high-quality plots for e.g. latex inclusion. All I can say is that I have had the opposite experience. Maybe that's because I work in a UTF environment and need support for CJK character sets. PostScript is basically hopeless for those. There are some very fragile workarounds, but they are so installation- specific that it doesn't work to build scripts or work flow around them. For latex inclusion, ps2pdf or direct PDF generation should be exactly the same, and subject to the same limitations of whatever converted Computer Modern fonts you are using. If that is a primary concern, then using one of the latex-based terminals directly is a better bet. Ethan -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: Ben A. <bpa...@ma...> - 2009-06-06 01:17:33
|
On Jun 5, 2009, at 4:08 PM, Ethan Merritt wrote: > On Friday 05 June 2009 11:12:52 Benjamin Lindner wrote: >> Ethan Merritt wrote: >>> On Friday 05 June 2009, Ben Abbott wrote: >>> >>>>>> Petr, what are the benefits of the pdfcairo and pngcairo >>>>>> terminals >>>>>> over the pdf and png terminals? >>> >>> Aside from licensing issues for PDFLib, using cairo to generate >>> the plots >>> allows antialiasing, transparency, and UTF-8 support. >> >> This may be a sutpid question, but what should a vector-based >> graphics >> description support antialiasing for? > > Ben asked about both pdfcairo and pngcairo. > The anti-aliasing is an issue for png, not for pdf. > Conversely, the transparency support is an issue for pdf but not for > png. > >> pdfcairo might be superior if you require transparency and UTF-8, >> granted, but the quality of the generated output is disappointing >> compared to pdf via postscript. >> I do a lot of image plots and found that the resulting file sizes >> with >> the pdfcairo terminal are 4-8 times larger than a ps->pdf output. >> Also >> you don't have good control over font selection, which is IMO a >> knock-out criteria when doing high-quality plots for e.g. latex >> inclusion. > > All I can say is that I have had the opposite experience. > Maybe that's because I work in a UTF environment and need support > for CJK character sets. PostScript is basically hopeless for those. > There are some very fragile workarounds, but they are so installation- > specific that it doesn't work to build scripts or work flow around > them. > > For latex inclusion, ps2pdf or direct PDF generation should be exactly > the same, and subject to the same limitations of whatever converted > Computer Modern fonts you are using. If that is a primary concern, > then using one of the latex-based terminals directly is a better bet. > > Ethan It doesn't appear to me that there is one solution that is preferred over the other in all cases. I'll propose the following, and encourage all to comment. ----------- 1) if "pdfcairo" is present => use "set term pdfcairo ..." 2) if "pdf" is present => use "set term pdf ..." 3) if neither => use "set term postscript ..." and then convert using ghostscript ----------- Although I'm a big LaTeX user, I elevated pdfcairo over pdf for the transparency feature. Similarly for png ----------- 1) if "pngcairo" is present => use "set term pngcairo ..." 2) if "png" is present => use "set term png ..." 3) if neither => use "set term postscript eps ..." and then convert using ghostscript ----------- For LaTeX, I will soon be adding support for the Lua/TikZ terminal. Its rendering is a bit slow, but produces excellent results for both latex and pdflatex. The solutions above will only work well for gnuplot 4.3+. Prior to that the variable GPVAL_TERMINALS does not exist, and octave has no manner to check for the existence of specific terminals. My building of gnuplot is broken at the moment, so my work on this will be delayed until I fix that. So if there are any suggestions/ comments for improvements, now is a good time to discuss further. Ben |
|
From: Benjamin L. <lin...@gm...> - 2009-06-06 11:47:09
|
Ben Abbott wrote: > > On Jun 5, 2009, at 4:08 PM, Ethan Merritt wrote: > >> On Friday 05 June 2009 11:12:52 Benjamin Lindner wrote: >>> Ethan Merritt wrote: >>>> On Friday 05 June 2009, Ben Abbott wrote: >>>> >>>>>>> Petr, what are the benefits of the pdfcairo and pngcairo terminals >>>>>>> over the pdf and png terminals? >>>> >>>> Aside from licensing issues for PDFLib, using cairo to generate the >>>> plots >>>> allows antialiasing, transparency, and UTF-8 support. >>> >>> This may be a sutpid question, but what should a vector-based graphics >>> description support antialiasing for? >> >> Ben asked about both pdfcairo and pngcairo. >> The anti-aliasing is an issue for png, not for pdf. >> Conversely, the transparency support is an issue for pdf but not for png. >> >>> pdfcairo might be superior if you require transparency and UTF-8, >>> granted, but the quality of the generated output is disappointing >>> compared to pdf via postscript. >>> I do a lot of image plots and found that the resulting file sizes with >>> the pdfcairo terminal are 4-8 times larger than a ps->pdf output. Also >>> you don't have good control over font selection, which is IMO a >>> knock-out criteria when doing high-quality plots for e.g. latex >>> inclusion. >> >> All I can say is that I have had the opposite experience. >> Maybe that's because I work in a UTF environment and need support >> for CJK character sets. PostScript is basically hopeless for those. >> There are some very fragile workarounds, but they are so installation- >> specific that it doesn't work to build scripts or work flow around them. >> >> For latex inclusion, ps2pdf or direct PDF generation should be exactly >> the same, and subject to the same limitations of whatever converted >> Computer Modern fonts you are using. If that is a primary concern, >> then using one of the latex-based terminals directly is a better bet. >> >> Ethan > > It doesn't appear to me that there is one solution that is preferred > over the other in all cases. > > I'll propose the following, and encourage all to comment. > > ----------- > 1) if "pdfcairo" is present => use "set term pdfcairo ..." > 2) if "pdf" is present => use "set term pdf ..." > 3) if neither => use "set term postscript ..." and then convert using > ghostscript > ----------- > Sounds very reasonable to me. > Although I'm a big LaTeX user, I elevated pdfcairo over pdf for the > transparency feature. > > Similarly for png > > ----------- > 1) if "pngcairo" is present => use "set term pngcairo ..." > 2) if "png" is present => use "set term png ..." > 3) if neither => use "set term postscript eps ..." and then convert > using ghostscript > ----------- > same as above > For LaTeX, I will soon be adding support for the Lua/TikZ terminal. Its > rendering is a bit slow, but produces excellent results for both latex > and pdflatex. > > The solutions above will only work well for gnuplot 4.3+. Prior to that > the variable GPVAL_TERMINALS does not exist, and octave has no manner to > check for the existence of specific terminals. For windows platform this is OK, since a working console application is only possible with 4.3+ Also interactive zooming with piped gnuplot works only with 4.3+ benjamin |
|
From: Ben A. <bpa...@ma...> - 2009-06-06 14:38:16
Attachments:
changeset-pdf.patch
|
On Jun 6, 2009, at 7:49 AM, Benjamin Lindner wrote: > Ben Abbott wrote: >> On Jun 5, 2009, at 4:08 PM, Ethan Merritt wrote: >>> On Friday 05 June 2009 11:12:52 Benjamin Lindner wrote: >>>> Ethan Merritt wrote: >>>>> On Friday 05 June 2009, Ben Abbott wrote: >>>>> >>>>>>>> Petr, what are the benefits of the pdfcairo and pngcairo >>>>>>>> terminals >>>>>>>> over the pdf and png terminals? >>>>> >>>>> Aside from licensing issues for PDFLib, using cairo to generate >>>>> the plots >>>>> allows antialiasing, transparency, and UTF-8 support. >>>> >>>> This may be a sutpid question, but what should a vector-based >>>> graphics >>>> description support antialiasing for? >>> >>> Ben asked about both pdfcairo and pngcairo. >>> The anti-aliasing is an issue for png, not for pdf. >>> Conversely, the transparency support is an issue for pdf but not >>> for png. >>> >>>> pdfcairo might be superior if you require transparency and UTF-8, >>>> granted, but the quality of the generated output is disappointing >>>> compared to pdf via postscript. >>>> I do a lot of image plots and found that the resulting file sizes >>>> with >>>> the pdfcairo terminal are 4-8 times larger than a ps->pdf output. >>>> Also >>>> you don't have good control over font selection, which is IMO a >>>> knock-out criteria when doing high-quality plots for e.g. latex >>>> inclusion. >>> >>> All I can say is that I have had the opposite experience. >>> Maybe that's because I work in a UTF environment and need support >>> for CJK character sets. PostScript is basically hopeless for those. >>> There are some very fragile workarounds, but they are so >>> installation- >>> specific that it doesn't work to build scripts or work flow around >>> them. >>> >>> For latex inclusion, ps2pdf or direct PDF generation should be >>> exactly >>> the same, and subject to the same limitations of whatever converted >>> Computer Modern fonts you are using. If that is a primary concern, >>> then using one of the latex-based terminals directly is a better >>> bet. >>> >>> Ethan >> It doesn't appear to me that there is one solution that is >> preferred over the other in all cases. >> I'll propose the following, and encourage all to comment. >> ----------- >> 1) if "pdfcairo" is present => use "set term pdfcairo ..." >> 2) if "pdf" is present => use "set term pdf ..." >> 3) if neither => use "set term postscript ..." and then convert >> using ghostscript >> ----------- > > Sounds very reasonable to me. > >> Although I'm a big LaTeX user, I elevated pdfcairo over pdf for the >> transparency feature. >> Similarly for png >> ----------- >> 1) if "pngcairo" is present => use "set term pngcairo ..." >> 2) if "png" is present => use "set term png ..." >> 3) if neither => use "set term postscript eps ..." and then convert >> using ghostscript >> ----------- > > same as above > >> For LaTeX, I will soon be adding support for the Lua/TikZ terminal. >> Its rendering is a bit slow, but produces excellent results for >> both latex and pdflatex. >> The solutions above will only work well for gnuplot 4.3+. Prior to >> that the variable GPVAL_TERMINALS does not exist, and octave has no >> manner to check for the existence of specific terminals. > > For windows platform this is OK, since a working console application > is only possible with 4.3+ > Also interactive zooming with piped gnuplot works only with 4.3+ > > benjamin Great! I've attached a changeset for the pdf part. It is combined with a changeset for forcing mono rendering (there is some problem with rgb2gray that has delayed me in pushing that change). In any event, I'd appreciated confirmation form linux and window's users that this chageset works correctly. Ben |
|
From: Ben A. <bpa...@ma...> - 2009-06-15 13:06:39
|
On Jun 15, 2009, at 3:35 AM, Benjamin Lindner wrote: > Ethan Merritt wrote: >> On Wednesday 10 June 2009 07:46:08 Benjamin Lindner wrote: >>> Ben Abbott wrote: >>>> On Wednesday, June 10, 2009, at 09:11AM, "Benjamin Lindner" <lin...@gm... >>>> > wrote: >>>>> Ben Abbott wrote: >>>>>> On Jun 10, 2009, at 5:02 AM, Benjamin Lindner wrote: >>>>>> >>>>>>> plot(0:0.1:10, sin(0:0.1:10), "@-;sin;", 0:0.1:10, >>>>>>> cos(0:0.1:10), "@-;cos;"); >>>>>>> print -depsc2 -debug:print.eps.log test.eps >>>>>>> print -dpsc2 -debug:print.ps.log test.ps >>>>>>> print -dpng -debug:print.png.log test.png >>>>>>> print -demf -debug:print.emf.log test.emf >>>>>>> print -dpdf -debug:print.pdf.log test.pdf >>>>>>> >>>>>>> I get now a pdfcairo and pngcairo output. >>>>>>> >>>>>>> However the pdfcairo output seems buggy, since it consists of >>>>>>> 3 pages: a blank first page, a second page with the expected >>>>>>> graph and a blank third page. >>>>>>> Hmm, looks like a problem with gnuplot I guess. >>>>>>> >>>>>>> benjamin >>>>>> What version of gnuplot are you running? >>>>>> >>>>>> I can run 4.2.2, 4.2.3, 4.2.4, 4.2,5 and 4.3.0 (current >>>>>> developers sources). If I can confirm the same behavior, I'll >>>>>> add "pdfcairo_is_broken" to __gnuplot_has_feature__ and switch >>>>>> to ghostrscript for that instance. >>>>>> >>>>> I have a 4.3.0 version, namely the CVS 2008-11-21 snapshot. >>>>> >>>>> benjamin >>>> Ok. I'm running developers sources that are less than a week old. >>>> I don't see the problem you reported. >>>> >>> Probably it has been fixed in CVS. >>> I hope there will be another gnuplot CVS snapshot, so I can >>> include it in a octave 3.2.1 release. >> Yes. There was a cairo terminal bug fixed 10 May 2009. >> If you generate a snapshot, please use the 4.4 pre-release sources >> rather than the 4.3 sources. >> It is currently marked "alpha", but if you have a need for a more >> well-defined >> version level we could bump that to "-rc1". >> Ethan > > Ok, possibly dumb question: How do I get the 4.4 sources? > I'm doing a "cvs update -d" from the sourceforge sources as > recommended on the gnuplot website. Correct? > > For inclusion in an octave binary a snapshot would be good, because > it makes support easier if there is a well-defined version bundled. > I'm not a cvs expert, not even a mildly experienced user. I know > from svn and mercurial, that there is a unique version or revision > which characterizes the source tree, so if I check out today and > compile a binary, I can tell which version of the source tree was > used, even without a dedicated snapshot. > Is there an equivalent in cvs? > > benjamin I see the 4.4 branch does exist. http://gnuplot.cvs.sourceforge.net/viewvc/gnuplot/gnuplot/term/x11.trm?view=log&pathrev=branch-4-4-stable However, I'm a novice when it comes to selecting cvs branches. Using the command line, how to I select a particular branch? ... and is MAIN or GNUPLOT_BETA the default branch for development? Ben p.s. I've cc'd the gnuplot mail-list. We should remove that once the cvs questions are answered. |
|
From: Ben A. <bpa...@ma...> - 2009-06-05 08:38:31
|
On Jun 5, 2009, at 4:15 AM, Petr Mikulik wrote: >>>>> printing to pdfcairo >>>>> >>>>> plot(1:100) >>>>> print -dpdf z.pdf >>>>> print -dpdfcairo zz.pdf >>>>> >>>>> ... the output file is called pdfcairo:zz.pdf >>>> >>>> This behavior is intended. >>> >>> This will certainly *not* work under windows, since the colon is >>> not a valid >>> filename character. It actually designates the streams associated >>> with a >>> file. So it might not issue an error (haven't checked) but then >>> very subtly >>> misbehave. >>> >>> This should be fixed. >>> >>> benjamin >> >> >> Recently this behavior was removed. Octave had been using >> "convert" (from >> imagemagick) to produce alternative formats. This is now done using >> ghostscript. Specifically, when a terminal is specified that is not >> supported/recognized, it is assumed that ghostcript is to be used >> to convert >> to the specified format. As the cairo terminals are not explicitly >> supported, >> specifying -pdfcairo produces a ghostscript error when using the >> developers >> sources. >> >> The pdfcairo and pngcairo terminals could be supported, but are not >> supported >> at this time. >> >> Petr, what are the benefits of the pdfcairo and pngcairo terminals >> over the >> pdf and png terminals? > > Usually the (original) pdf terminal is not compiled in because of > license > issues. pdfcairo and pngcairo are automatically compiled in if the > system > has cairo library (available as a package for most linux > distributions, for > example). > > I think that the cairo terminals handle UTF-8 text correctly. > > I gave cc: to gnuplot list so that somebody can explain the > difference in > more details. Are there any license problems with the plain png terminal, or is it just the pdf? Presently, when the pdf terminal is specified, the print() function checks with gnuplot to determine if the "pdf" terminal is supported. If not, or unknown, print() checks for the presence of ghostscript. If present, the ps terminal is used to produce a ps-file and then ghostscript is used to convert to pdf. Ben |
|
From: Petr M. <mi...@ph...> - 2009-06-05 09:46:07
|
> >issues. pdfcairo and pngcairo are automatically compiled in if the system > >has cairo library (available as a package for most linux distributions, for > >example). > > > >I think that the cairo terminals handle UTF-8 text correctly. > > > >I gave cc: to gnuplot list so that somebody can explain the difference in > >more details. > > Are there any license problems with the plain png terminal, or is it just the > pdf? png is fine, it uses gd library > Presently, when the pdf terminal is specified, the print() function checks > with gnuplot to determine if the "pdf" terminal is supported. If not, or > unknown, print() checks for the presence of ghostscript. If present, the ps > terminal is used to produce a ps-file and then ghostscript is used to convert > to pdf. I wonder whether "set term pdf" is used if "set term" shows "pdfcairo" but not "pdf"? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2009-06-05 15:02:51
|
On Friday 05 June 2009, Ben Abbott wrote: > > >> > >> Petr, what are the benefits of the pdfcairo and pngcairo terminals > >> over the pdf and png terminals? Aside from licensing issues for PDFLib, using cairo to generate the plots allows antialiasing, transparency, and UTF-8 support. > Are there any license problems with the plain png terminal, or is it > just the pdf? The "plain png" terminal has not been supported for about 8 years now. Instead the default is to use libgd, and the newer option is to use cairo. None of these has any licensing issues that I am aware of. > Presently, when the pdf terminal is specified, the print() function > checks with gnuplot to determine if the "pdf" terminal is supported. > If not, or unknown, print() checks for the presence of ghostscript. If > present, the ps terminal is used to produce a ps-file and then > ghostscript is used to convert to pdf. Going through an intermediate postscript file is non-optimal, because PostScript itself does not support transparency or UTF-8 characters. At least from the perspective of plot quality, this is probably the least satisfactory of several options. It would be better to use either pdfcairo or the brand new tikz terminal. Does Octave have a confguration file or configuration menu that the user can find easily? I suggest to make the production of pdf output a user-configurable choice. PDF output via (select one) --> pdf (let gnuplot choose for you) --> pdfcairo --> tikz / pdflatex --> PostScript / ps2pdf |
