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