gnuplot-beta

Lua / Tikz / pgf works for pdflatex only ?

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

Does anyone familiar with Tikz/pgf know why the output from pdflatex 
terminal or "lua tikz" terminal should not work with the normal "latex" 
command line processing as opposed to requiring "pdflatex"?

https://sourceforge.net/p/gnuplot/bugs/1822/

If there is a good reason, should we put in the output LaTeX/TeX code 
some type of error message that complains when compiled without pdflatex?

Dan

Re: Lua / Tikz / pgf works for pdflatex only ?

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

On 28 June 2016 at 23:38, Daniel J Sebald wrote:
> Does anyone familiar with Tikz/pgf know why the output from pdflatex
> terminal or "lua tikz" terminal should not work with the normal "latex"
> command line processing as opposed to requiring "pdflatex"?
>
> https://sourceforge.net/p/gnuplot/bugs/1822/

The "plot sin(x)" as opposed to "test" works for me. I would suspect
fill patterns, but there might of course be any other reason for the
failure.

> If there is a good reason, should we put in the output LaTeX/TeX code
> some type of error message that complains when compiled without pdflatex?

That would be a very bad idea in my opinion.

First of all please note that many graphics (like "plot sin(x)") work
even when compiled via dvi->ps route. There's probably just something
wrong with pattern fill or one of those special features which might
just as well be a bug in TikZ (using pdflatex makes a lot more sense
nowadays than going through dvi, so I doubt that special features in
TikZ really get any extensive testing in the old workflow).

The other problem is that it is very tricky if not impossible to
determine the engine being used. People could use dvipdfmx instead of
dvips to process the files, or XeTeX, LuaTeX, upTeX or any other
exotic workflow. How exactly would you decide when to break the
compilation and when not?

Mojca

Re: Lua / Tikz / pgf works for pdflatex only ?

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

On 06/28/2016 08:06 PM, Mojca Miklavec wrote:
> On 28 June 2016 at 23:38, Daniel J Sebald wrote:
>> Does anyone familiar with Tikz/pgf know why the output from pdflatex
>> terminal or "lua tikz" terminal should not work with the normal "latex"
>> command line processing as opposed to requiring "pdflatex"?
>>
>> https://sourceforge.net/p/gnuplot/bugs/1822/
>
> The "plot sin(x)" as opposed to "test" works for me. I would suspect
> fill patterns, but there might of course be any other reason for the
> failure.

That sounds slightly different from what I'm experiencing (and should be 
fixed, as I think the TikZ shouldn't have too much trouble with 
patterns, judging from how extensive the manual is).  It sounds like you 
are at least able to get the TikZ code to work with "latex".  I'm not 
getting that far.  The PostScript files that "latex" is generating from 
TikZ/PGF targeted code is missing the definition "pgfo".  That 
definition is in the file

/usr/share/texmf/tex/generic/pgf/systemlayer/pgfsys-dvips.def


>> If there is a good reason, should we put in the output LaTeX/TeX code
>> some type of error message that complains when compiled without pdflatex?
>
> That would be a very bad idea in my opinion.
>
> First of all please note that many graphics (like "plot sin(x)") work
> even when compiled via dvi->ps route. There's probably just something
> wrong with pattern fill or one of those special features which might
> just as well be a bug in TikZ (using pdflatex makes a lot more sense
> nowadays than going through dvi, so I doubt that special features in
> TikZ really get any extensive testing in the old workflow).
>
> The other problem is that it is very tricky if not impossible to
> determine the engine being used. People could use dvipdfmx instead of
> dvips to process the files, or XeTeX, LuaTeX, upTeX or any other
> exotic workflow. How exactly would you decide when to break the
> compilation and when not?

Right, I suppose that is what Chapter 10 of the TikZ/PGF manual 
addresses.  The manual does suggest that dvips should work, by somehow 
including the pgfsys-dvips.def file.  (It contains PostScript 
definitions required for dvips.)  But I can't seem to include those 
definitions no matter what I include or redefine in the TikZ-targeted 
LaTeX code.

On what system are you running "latex", and what version?  I have

sebald@ ~ $ latex --version
pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian)
kpathsea version 6.1.1

Thanks,

Dan

Re: Lua / Tikz / pgf works for pdflatex only ?

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

On 06/28/2016 09:19 PM, Daniel J Sebald wrote:
> On 06/28/2016 08:06 PM, Mojca Miklavec wrote:
>> On 28 June 2016 at 23:38, Daniel J Sebald wrote:

> Right, I suppose that is what Chapter 10 of the TikZ/PGF manual
> addresses.  The manual does suggest that dvips should work, by somehow
> including the pgfsys-dvips.def file.  (It contains PostScript
> definitions required for dvips.)  But I can't seem to include those
> definitions no matter what I include or redefine in the TikZ-targeted
> LaTeX code.

I've isolated the problem on my system to the inclusion of the preview 
package.  So I've gotten a bit further, and will keep investigating on 
the bug/ticket tracker:

https://sourceforge.net/p/gnuplot/bugs/1822/

Dan

PS: test works for both latex and pdflatex, but the patterns are 
different from qt.  (I think patterns are terminal specific.)  The one 
difference is that the result from "latex" on the tikz-tex output does 
not have the alpha blending, while "pdflatex" processing produces an 
output with alpha blending of the hexagons.

Re: Lua / Tikz / pgf works for pdflatex only ?

[Ethan M. <eam...@gm...>]

On Tuesday, June 28, 2016 10:45:18 PM Daniel J Sebald wrote:
> On 06/28/2016 09:19 PM, Daniel J Sebald wrote:
> > On 06/28/2016 08:06 PM, Mojca Miklavec wrote:
> >> On 28 June 2016 at 23:38, Daniel J Sebald wrote:
> > Right, I suppose that is what Chapter 10 of the TikZ/PGF manual
> > addresses.  The manual does suggest that dvips should work, by somehow
> > including the pgfsys-dvips.def file.  (It contains PostScript
> > definitions required for dvips.)  But I can't seem to include those
> > definitions no matter what I include or redefine in the TikZ-targeted
> > LaTeX code.
> 
> I've isolated the problem on my system to the inclusion of the preview
> package.  

See:
  http://tex.stackexchange.com/questions/37982/problem-with-preview-package-and-standalone-class-with-tikz

Re: Lua / Tikz / pgf works for pdflatex only ?

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

On 29 June 2016 at 04:19, Daniel J Sebald wrote:
> On 06/28/2016 08:06 PM, Mojca Miklavec wrote:
>>
>> On 28 June 2016 at 23:38, Daniel J Sebald wrote:
>>>
>>> Does anyone familiar with Tikz/pgf know why the output from pdflatex
>>> terminal or "lua tikz" terminal should not work with the normal "latex"
>>> command line processing as opposed to requiring "pdflatex"?
>>>
>>> https://sourceforge.net/p/gnuplot/bugs/1822/
>>
>>
>> The "plot sin(x)" as opposed to "test" works for me. I would suspect
>> fill patterns, but there might of course be any other reason for the
>> failure.
>
> That sounds slightly different from what I'm experiencing (and should be
> fixed, as I think the TikZ shouldn't have too much trouble with patterns,
> judging from how extensive the manual is).

Officially not. But bugs keep popping up and some combinations of
features and engines are simply too rarely used and tested. In ConTeXt
not even things like "color=red!20!yellow" work properly and there are
other problems.

But again, I didn't claim that this was in fact the problem, it was
just a quick thought because simple graphs work just fine for me.

> It sounds like you are at least
> able to get the TikZ code to work with "latex".  I'm not getting that far.
> The PostScript files that "latex" is generating from TikZ/PGF targeted code
> is missing the definition "pgfo".  That definition is in the file
>
> /usr/share/texmf/tex/generic/pgf/systemlayer/pgfsys-dvips.def
>
> Right, I suppose that is what Chapter 10 of the TikZ/PGF manual addresses.
> The manual does suggest that dvips should work, by somehow including the
> pgfsys-dvips.def file.  (It contains PostScript definitions required for
> dvips.)  But I can't seem to include those definitions no matter what I
> include or redefine in the TikZ-targeted LaTeX code.

The official way to do that is supposed to be
    \def\pgfsysdriver{pgfsys-dvips.def}
before including TikZ, but dvips *is* already the default driver when
you compile with "latex", redefining the sysdriver only makes sense if
you plan to use dvipdfmx or anything like that. So you won't achieve
anything by including pgfsys-dvips.def.

> On what system are you running "latex", and what version?  I have

I don't believe the system makes any difference, but it's an old OS X
version with the latest TeX Live.

> latex --version
pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016)
kpathsea version 6.2.2
...
Compiled with libpng 1.6.21; using libpng 1.6.21
Compiled with zlib 1.2.8; using zlib 1.2.8
Compiled with xpdf version 3.04

> sebald@ ~ $ latex --version
> pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian)
> kpathsea version 6.1.1

The TeX Live version does make quite some difference though. 2013 is
quite a bit old and many packages have changed during the three years.

Anyway, it seems that the preview package was indeed the fault. Other
suggestions in the ticket work for me in principle, but I didn't yet
figure out how to fix the bounding box (I haven't used dvi for more
than a decade at least and I'm no longer a LaTeX user either).

> the patterns are different
> from qt.  (I think patterns are terminal specific.)

Indeed. Gnuplot doesn't even prescribe what the terminals could use to
be at least somewhat compatible.

> The one difference is
> that the result from "latex" on the tikz-tex output does not have the alpha
> blending, while "pdflatex" processing produces an output with alpha blending
> of the hexagons.

PostScript doesn't support transparencies, but for some reason (that I
don't quite understand) I'm getting the alpha blending in the final
PDF even via the tex->dvi->ps->pdf route. (I'm using GhostScript's
ps2pdf to convert from PS to PDF.)

It would probably be best if there was a way to fix the problem in
preview directly.

Mojca

Re: Lua / Tikz / pgf works for pdflatex only ?

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

On 06/29/2016 01:44 AM, Mojca Miklavec wrote:
> On 29 June 2016 at 04:19, Daniel J Sebald wrote:
>> On 06/28/2016 08:06 PM, Mojca Miklavec wrote:
>>>
>>> On 28 June 2016 at 23:38, Daniel J Sebald wrote:
>>>>
>>>> Does anyone familiar with Tikz/pgf know why the output from pdflatex
>>>> terminal or "lua tikz" terminal should not work with the normal "latex"
>>>> command line processing as opposed to requiring "pdflatex"?
>>>>
>>>> https://sourceforge.net/p/gnuplot/bugs/1822/
>>>
>>>
>>> The "plot sin(x)" as opposed to "test" works for me. I would suspect
>>> fill patterns, but there might of course be any other reason for the
>>> failure.
>>
>> That sounds slightly different from what I'm experiencing (and should be
>> fixed, as I think the TikZ shouldn't have too much trouble with patterns,
>> judging from how extensive the manual is).
>
> Officially not. But bugs keep popping up and some combinations of
> features and engines are simply too rarely used and tested. In ConTeXt
> not even things like "color=red!20!yellow" work properly and there are
> other problems.
>
> But again, I didn't claim that this was in fact the problem, it was
> just a quick thought because simple graphs work just fine for me.
>
>> It sounds like you are at least
>> able to get the TikZ code to work with "latex".  I'm not getting that far.
>> The PostScript files that "latex" is generating from TikZ/PGF targeted code
>> is missing the definition "pgfo".  That definition is in the file
>>
>> /usr/share/texmf/tex/generic/pgf/systemlayer/pgfsys-dvips.def
>>
>> Right, I suppose that is what Chapter 10 of the TikZ/PGF manual addresses.
>> The manual does suggest that dvips should work, by somehow including the
>> pgfsys-dvips.def file.  (It contains PostScript definitions required for
>> dvips.)  But I can't seem to include those definitions no matter what I
>> include or redefine in the TikZ-targeted LaTeX code.
>
> The official way to do that is supposed to be
>      \def\pgfsysdriver{pgfsys-dvips.def}
> before including TikZ, but dvips *is* already the default driver when
> you compile with "latex", redefining the sysdriver only makes sense if
> you plan to use dvipdfmx or anything like that. So you won't achieve
> anything by including pgfsys-dvips.def.

I found that out.  My best guess is that the preview LaTeX package is 
undoing some of what the pgfsys-dvips.def definitions did.


>> On what system are you running "latex", and what version?  I have
>
> I don't believe the system makes any difference, but it's an old OS X
> version with the latest TeX Live.
>
>> latex --version
> pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016)
> kpathsea version 6.2.2
> ...
> Compiled with libpng 1.6.21; using libpng 1.6.21
> Compiled with zlib 1.2.8; using zlib 1.2.8
> Compiled with xpdf version 3.04
>
>> sebald@ ~ $ latex --version
>> pdfTeX 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian)
>> kpathsea version 6.1.1
>
> The TeX Live version does make quite some difference though. 2013 is
> quite a bit old and many packages have changed during the three years.

I figured that.  I'm not about to upgrade though because I think it 
might be a lot of work.  I'll leave that to Mint.


> Anyway, it seems that the preview package was indeed the fault. Other
> suggestions in the ticket work for me in principle, but I didn't yet
> figure out how to fix the bounding box (I haven't used dvi for more
> than a decade at least and I'm no longer a LaTeX user either).
>
>> the patterns are different
>> from qt.  (I think patterns are terminal specific.)
>
> Indeed. Gnuplot doesn't even prescribe what the terminals could use to
> be at least somewhat compatible.
>
>> The one difference is
>> that the result from "latex" on the tikz-tex output does not have the alpha
>> blending, while "pdflatex" processing produces an output with alpha blending
>> of the hexagons.
>
> PostScript doesn't support transparencies, but for some reason (that I
> don't quite understand) I'm getting the alpha blending in the final
> PDF even via the tex->dvi->ps->pdf route. (I'm using GhostScript's
> ps2pdf to convert from PS to PDF.)

Oh, sure enough; that works here as well.  Let's look at the PostScript 
code.  Here looks to be the closed path definition for the green hexagon:

  save
  0.03984 pgfw
  0 1 0 setrgbcolor
  0.50 .pgfsetstrokeopacityalpha
  0.50 .pgfsetfillopacityalpha
  283.4681 197.01022 moveto
  274.59543 212.34586 lineto
  256.87868 212.34586 lineto
  248.03458 197.01022 lineto
  256.87868 181.64647 lineto
  274.59543 181.64647 lineto
  closepath

The definition for .pgfsetfillopacityalpha looks to be some creative 
conditional, probably interpreted differently in the PostScript screen 
driver than when sent to ps2pdf.


> It would probably be best if there was a way to fix the problem in
> preview directly.

Do you see nicely cropped plots (i.e., no missing border in test.pdf, or 
extra white pixels outside the border) from the preview package?

Dan