4

I was trying to put an xtable inside a macro, and ran into a bunch of problems, which are documented in other questions. The workaround seems to be to use embeddedxtable instead. This appears to work.

However, I wonder what else is going on when I use an embeddedxtable instead. Am I giving something up? I looked in the source (tabl-xtb.mkvi) and I see a comment about direct buffers being faster (probably negligibly), but I'm not really TeXnical enough to really understand if there are other tradeoffs that I should be aware of.

4

Performance

A minor disadvantage of embeddedxtable is that it's slightly slower than the normal xtable environment but the results from the following example are the worst case. For normal use the difference is much smaller because more time is spent to calculate width and height of the cells which is the same for both environments.

\startbuffer[xtable]
    \startxtable
        \startxrow
            \startxcell
                Dummy
            \stopxcell
        \stopxrow
    \stopxtable
\stopbuffer

\startbuffer[embeddedxtable]
    \startembeddedxtable
        \startxrow
            \startxcell
                Dummy
            \stopxcell
        \stopxrow
    \stopembeddedxtable
\stopbuffer

\starttext

\testfeatureonce
  {10000}
  {\startnointerference
   \getbuffer[xtable]
   \stopnointerference}

\testfeatureonce
  {10000}
  {\startnointerference
   \getbuffer[embeddedxtable]
   \stopnointerference}

\stoptext

The result from the test above can be seen on the command line (below are result from my machine):

system          > starting feature test (n=10000)
system          > 10000 feature tests done (18.584s)
system          > starting feature test (n=10000)
system          > 10000 feature tests done (29.971s)

Limitations

What you're more interested in are the limitations of the embeddedxtable environment compared with the regular environment.

  1. All environments which interperet the end of a line (e.g. \startlines or \starttyping) produce only a single line of text in the output.

  2. Not all symbols can be used in code blocks (e.g. %)or produce unexpected result (double #).

\startbuffer[xtable]
    \startxtable
        \startxrow
            \startxcell
                \startlines
                First line
                Second line
                \stoplines
            \stopxcell
        \stopxrow
        \startxrow
            \startxcell
                \type
                    {%
                     #}
            \stopxcell
        \stopxrow
    \stopxtable
\stopbuffer

\startbuffer[embeddedxtable]
    \startembeddedxtable
        \startxrow
            \startxcell
                \startlines
                First line
                Second line
                \stoplines
            \stopxcell
        \stopxrow
        \startxrow
            \startxcell
                \type
                    {%
                     #}
            \stopxcell
        \stopxrow
    \stopembeddedxtable
\stopbuffer

\starttext

\getbuffer[xtable]

\getbuffer[embeddedxtable]

\stoptext

This is the output for xtable

enter image description here

and this is what you get from embeddedxtable

enter image description here

3
  • Thank you for the details. I was hoping that using \processdatabasefile would save me from the limitations you highlighted, but apparently not. Oh well, I guess I'll have to keep them in mind when preparing the files I'm reading in (especially % and newlines). – Tyler Mar 16 '20 at 20:20
  • @Tyler When you read from external files some limitations don't apply, e.g. typesetfile keeps the line endings for verbatim text. – Wolfgang Schuster Mar 16 '20 at 20:26
  • That's what I was hoping. But I tried it with %, and no luck in this case. Shouldn't be a huge deal though. – Tyler Mar 16 '20 at 21:34

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.