# Lua / Tikz / pgf works for pdflatex only ?

 Classic List Threaded
7 messages
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

## Lua / Tikz / pgf works for pdflatex only ?

 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

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

 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta Reply | Threaded Open this post in threaded view | Report Content as Inappropriate ## Re: Lua / Tikz / pgf works for pdflatex only ?  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. ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta Reply | Threaded Open this post in threaded view | Report Content as Inappropriate ## Re: Lua / Tikz / pgf works for pdflatex only ?  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------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta Reply | Threaded Open this post in threaded view | Report Content as Inappropriate ## Re: Lua / Tikz / pgf works for pdflatex only ?  In reply to this post by Daniel J Sebald 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Reply | Threaded
Open this post in threaded view
|
Report Content as Inappropriate

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

 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 ------------------------------------------------------------------------------ Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San Francisco, CA to explore cutting-edge tech and listen to tech luminaries present their vision of the future. This family event has something for everyone, including kids. Get more information and register today. http://sdm.link/attshape_______________________________________________ gnuplot-beta mailing list [hidden email] Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
Loading...