I am not clear about differences between pgf and TikZ. The latter is the frontend of the former. That's fine. In any case, their codes are clearly different. I have two questions.

  1. Is it possible to convert pgf code into TikZ code? If yes, can you suggest any app (Mac please)?

  2. Is it possible to use pgf code in TikZ environment?

Your help is appreciated.

  • 1
    Welcome to TeX.SX! You may have a look on our starter guide. (1) There is no app. (2) Yes. – Marco Daniel May 12 '13 at 15:45
  • 3
    All TikZ code is converted to PGF code internally (TikZ is just a wrapper for PGF), but you can't automatically convert from PGF to TikZ. You can use pgf code directly in a TikZ environment. – Jake May 12 '13 at 15:46
  • TikZ does a lot under the hood before anything is processed by PGF’s macros. In fact, TikZ offers a few things you couldn’t do that nicely or comfortably with PGF. Is there any real use-case behind the idea of converting PGF up to TikZ? – Qrrbrbirlbel Jun 10 '13 at 21:56
  • I was looking for a program that would allow me to draw diagrams in a WYSIWYG way and at the same time generate codes for later manipulation. Then, I came across Jpgfdraw, but codes were difficult for me to learn. That is why I asked if it is possible to convert PGF to TikZ codes. I can now draw simple diagrams for my papers in TikZ codes. But it would be beneficial for beginners like me if there is a program that converts PGF to TikZ codes, given that there is no WYSIWYG program that generates TikZ codes (I was not find one so far). – T_T Jun 11 '13 at 11:40
  • @T_T matlab2tikz which is often mentioned on TeX.sx produces TikZ output. Then there is inkscape2tikz. Check texample.net/tikz/examples/tag/code-generation for other examples generated by other software. dot2tex can generate PSTricks as well as PGF and TikZ code. To answer your question: Yes, it is possible to convert PGF to TikZ code (by hand at least) but with an overhead, as TikZ does and is more than just PGF. Your request is very exceptional because for most people it is easier to write TikZ code than it is to write PGF code. – Qrrbrbirlbel Jun 25 '13 at 21:14

I thought this should be a duplicate of Is there an advantage in using the pgf Basic Layer over tikz? but since there are a few tiny differences here is a very rough one just to archive this.

If you think of the code conversion as a mathematical function that recevies the PGF code and spits out TikZ code (I don't know why you would do that), it's a multivalued and nonsurjective function.

In other words, the same PGF snippet might lead to the different TikZ code. Example,


\draw (0,0) -- (2,0) --  node[pos=0.4,above= 2mm,right=0.5mm] {A} (0,2) --   (-2,0) -- cycle;
\draw (0,0) -- (2,0) --  node[pos=0.38,anchor=south west] {A} (0,2) --   (-2,0) -- cycle;
\draw (0,0) -- (2,0) node at (1.5cm,1cm) {A} --  (0,2) --   (-2,0) -- cycle;

(I'm approximating the equivalence of the commands) Let's say for some reason I've ended up with the PGF code above and I want to convert it to TikZ. However I have no idea why the node is inserted in between. If it was coming from a TikZ like code where you have node[midway] I should have some interpolation etc. But this is bluntly inserted.

I can try to convert via the options given above (and many more) but why should I prefer one to another? Well in this example it is obvious that the last one is the most sane one but others are trying to get [pos=x] syntax.

Even worse, TikZ code keeps the settings such as current line width, color etc. local to the object but in PGF code it comes one another as macros. It is almost always a problem that a setting leaks out to whatever that follows until the setting is reset again. For example, remove all the TikZ based drawing commands and check the output. Comment \color{red} and remove the comment from the next line. WTF? It's always fun.

That's why any interpreter would then resort back to primitive building blocks (you can have a look at InkScape2TikZ output, I think it's doing a great job by the way)

\draw (a) -- (b);
\draw (b) -- (c);
\path node at (d) {A};

Even this will not assure that we actually close the path. So nodes should come later if we have a closed path and the adventure begins :)

Second issue is that not every PGF command can be reproducible via TikZ syntax. But that's kind of known and is a subject of many questions including the linked one anyway.

  • Well, I agree with the answer in total; but the example is not correct. The position of a node is calculated differently (\pgftransformlineattime) than of a node that is set explicitly at a coordinate. Even above and right translates to various \pgftransform… macros. More so, \pgfpoint{2cm}{0cm} would be (2cm,0cm) in TikZ while (2,0) would be \pgfpointxy{2}{0} (just add x=2cm to the TikZ options or use \pgfsetxvec{\pgfpoint{2cm}{0pt}}). As I said in my comment, there is a lot going on with TikZ which is lost in the conversion to PGF. – Qrrbrbirlbel Jul 31 '13 at 14:22
  • @Qrrbrbirlbel We are going from PGF to TikZ. So tranformlineattime is not the issue. We are trying to make some sense of arbitrary node placement within the path given as a PGF node. How to convert it to a TikZ \node is the question. You cannot expect a full TikZ equivalent within the PGF code. It will always be different from what TikZ -> PGF conversion result. – percusse Jul 31 '13 at 14:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.