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