CCed to ConTeXt mailing list. On Tue, 21 Jul 2009, Mojca Miklavec wrote to pgf.user list:
Hello,
I noticed that a large number of \begin{tikzpicture} \draw (0,0) -- (5,1); \end{tikzpicture} breaks at line end while \starttikzpicture \draw (0,0) -- (5,1); \stoptikzpicture just generates an infinitely long line.
Is there any simple way to fix the behaviour in ConTeXt?
Don't know.
I also don't like the behaviour in \placefigure{title}{\starttikzpicture ... \stoptikzpicture} that has to be surrounded with \hbox{\starttikzpicture ... \stoptikzpicture} else the figure gets placed at the beginning of line instead of being centered.
This is what is happening. The pgf code basically boils down to this. \starttext \newbox\pgfpic \setbox\pgfpic\hbox to 10pt\bgroup abc \egroup \placefigure {testing box placement} {\leavevmode\raise-2pt\box\pgfpic} \stoptext Now since \placefigure internally places its contents in a \vbox, this boils down to a differnce beween \hbox to \textwidth {\hss \vbox{\hbox{abc}} \hss} \hbox to \textwidth {\hss \vbox{\leavevmode\raise-2pt \hbox{abc}} \hss} So, the solution is to either patch \placefigure so that \def\setlocalfloatdimensions#1% {... \global\setbox\floatbox\hbox% was \vbox ....} or redefine \pgfsys@typesetpicturebox to \def\pgfsys@typesetpicturebox#1{% .... \hbox{\leavevmode\raise-\pgf@x\box#1}%\hbox added } The redefinition at ConTeXt will break some existing documents (i.e., the authors will have to manually add a \vbox where there was none earlier). The redefinition at tikz end will make all pgf code run slightly slower (an extra hbox for each typeset pgfpicture) If neither of these is acceptable, then we can have a simple wrapper around \start-stop tikzpicture: \def\startTIKZcode{\hbox\bgroup\starttikzpicture} \def\stopTIKZcode {\stoptikzpicture\egroup} which will only affect ConTeXt code. Aditya
Aditya Mahajan wrote:
Now since \placefigure internally places its contents in a \vbox, this boils down to a differnce beween
that will not change .. (being in vmode also has advantages with regards to spurious spaces)
The redefinition at ConTeXt will break some existing documents (i.e., the authors will have to manually add a \vbox where there was none earlier). The redefinition at tikz end will make all pgf code run slightly slower (an extra hbox for each typeset pgfpicture)
not that much slower i guess as not much repackaging is needed, just a box flush; in tikz parsing and calculations of the graphic take much more time (just take look at traced output); if you want to optimize tikz there are other tricks
If neither of these is acceptable, then we can have a simple wrapper around \start-stop tikzpicture:
\def\startTIKZcode{\hbox\bgroup\starttikzpicture} \def\stopTIKZcode {\stoptikzpicture\egroup}
which will only affect ConTeXt code.
or just add a \dontleavehmode in front of the picture Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, Jul 22, 2009 at 03:08, Aditya Mahajan wrote:
CCed to ConTeXt mailing list.
(And removed the pgf mailing list? :)
On Tue, 21 Jul 2009, Mojca Miklavec wrote to pgf.user list:
Hello,
I noticed that a large number of \begin{tikzpicture} \draw (0,0) -- (5,1); \end{tikzpicture} breaks at line end while \starttikzpicture \draw (0,0) -- (5,1); \stoptikzpicture just generates an infinitely long line.
Is there any simple way to fix the behaviour in ConTeXt?
Don't know.
I have just noticed that (independent of the second issue) when placing several items of: 1.) \tikz \draw (0,0)--(4,2); works OK in both LaTeX and ConTeXt 2.) \begin{tikzpicture} \draw (0,0)--(4,2); \end{tikzpicture} works OK in LaTeX 3.) \starttikzpicture \draw (0,0)--(4,2); \stoptikzpicture{} works OK in ConTeXt 4.) \starttikzpicture \draw (0,0)--(4,2); \stoptikzpicture creates an infinitely long line in ConTeXt Does that ring a bell to anyone? (It must be something trivial like eating any spaces after \commandsequence, but I don't know what exactly.)
I also don't like the behaviour in \placefigure{title}{\starttikzpicture ... \stoptikzpicture} that has to be surrounded with \hbox{\starttikzpicture ... \stoptikzpicture} else the figure gets placed at the beginning of line instead of being centered.
This is what is happening. The pgf code basically boils down to this.
\starttext \newbox\pgfpic
\setbox\pgfpic\hbox to 10pt\bgroup abc \egroup
\placefigure {testing box placement} {\leavevmode\raise-2pt\box\pgfpic}
\stoptext
Now since \placefigure internally places its contents in a \vbox, this boils down to a differnce beween
\hbox to \textwidth {\hss \vbox{\hbox{abc}} \hss}
\hbox to \textwidth {\hss \vbox{\leavevmode\raise-2pt \hbox{abc}} \hss}
So, the solution is to either patch \placefigure so that
\def\setlocalfloatdimensions#1% {... \global\setbox\floatbox\hbox% was \vbox ....}
or redefine \pgfsys@typesetpicturebox to
\def\pgfsys@typesetpicturebox#1{% .... \hbox{\leavevmode\raise-\pgf@x\box#1}%\hbox added }
The redefinition at ConTeXt will break some existing documents (i.e., the authors will have to manually add a \vbox where there was none earlier). The redefinition at tikz end will make all pgf code run slightly slower (an extra hbox for each typeset pgfpicture)
If neither of these is acceptable, then we can have a simple wrapper around \start-stop tikzpicture:
\def\startTIKZcode{\hbox\bgroup\starttikzpicture} \def\stopTIKZcode {\stoptikzpicture\egroup}
which will only affect ConTeXt code.
Would it affect anyone if TikZ would generate an hbox instead of vbox (at least in ConTeXt)? That means ... instead of \let\starttikzpicture=\tikzpicture \let\stoptikzpicture=\endtikzpicture having \def\starttikzpicture{\hbox\bgroup\tikzpicture} \def\stoptikzpicture{\endtikzpicture\egroup} (I admit that I don't understand all the tiny bits, for example when one would prefer to have vbox, so I might be missing the whole picture.) Mojca
On Wed, 22 Jul 2009, Mojca Miklavec wrote:
On Wed, Jul 22, 2009 at 03:08, Aditya Mahajan wrote:
CCed to ConTeXt mailing list.
(And removed the pgf mailing list? :)
No... it was in the newsroup header (I was replying via gmane interface).
On Tue, 21 Jul 2009, Mojca Miklavec wrote to pgf.user list:
Hello,
I noticed that a large number of \begin{tikzpicture} \draw (0,0) -- (5,1); \end{tikzpicture} breaks at line end while \starttikzpicture \draw (0,0) -- (5,1); \stoptikzpicture just generates an infinitely long line.
Is there any simple way to fix the behaviour in ConTeXt?
Don't know.
I have just noticed that (independent of the second issue) when placing several items of:
1.) \tikz \draw (0,0)--(4,2); works OK in both LaTeX and ConTeXt 2.) \begin{tikzpicture} \draw (0,0)--(4,2); \end{tikzpicture} works OK in LaTeX 3.) \starttikzpicture \draw (0,0)--(4,2); \stoptikzpicture{} works OK in ConTeXt 4.) \starttikzpicture \draw (0,0)--(4,2); \stoptikzpicture creates an infinitely long line in ConTeXt
Does that ring a bell to anyone? (It must be something trivial like eating any spaces after \commandsequence, but I don't know what exactly.)
Try the undocumented equivalent of \begin{...} \end{...} in ConTeXt: \start[tikzpicture] ... \stop[tikzpicture]
I also don't like the behaviour in \placefigure{title}{\starttikzpicture ... \stoptikzpicture} that has to be surrounded with \hbox{\starttikzpicture ... \stoptikzpicture} else the figure gets placed at the beginning of line instead of being centered.
[explanation snipped]
If neither of these is acceptable, then we can have a simple wrapper around \start-stop tikzpicture:
\def\startTIKZcode{\hbox\bgroup\starttikzpicture} \def\stopTIKZcode {\stoptikzpicture\egroup}
which will only affect ConTeXt code.
Would it affect anyone if TikZ would generate an hbox instead of vbox (at least in ConTeXt)?
That means ... instead of \let\starttikzpicture=\tikzpicture \let\stoptikzpicture=\endtikzpicture having \def\starttikzpicture{\hbox\bgroup\tikzpicture} \def\stoptikzpicture{\endtikzpicture\egroup}
This is same as the workaround that I suggested. It should work perfectly fine in ConTeXt. Aditya
participants (3)
-
Aditya Mahajan -
Hans Hagen -
Mojca Miklavec