True. There is also a

\define\continuePaneRow{\eTD\bTD}

definition as well for that reason but that = wasn't necessary for the MWE to (fail while) embed(ing) TABLE elements in macros.

Is it the case that I can bundle at least th= e table setup commands to avoid some level of replication? Or is there a be= tter way to creat the various table begin--end pairs that is cleaner?

Thanks,

---K

Kevin W. Rudd, Ph.D.

CAPT, USN (Ret)

Computer Architecture & Computer Enginee= ring (CACE)

Advanced Computing Systems (ACS) Research Pr= ogram

Laboratory for Physical Sciences (LPS)

443-654-7878

kevin@lps.umd.edu

Visiting Research Professor

Electrical and Computer Engineering

United States Naval Academy

rudd@usna.edu

From: Wolfgang Schuster <= ;wolfgang.schuster.lists@gmail.com>
Sent: Wednesday, September 9, 2020 1:57:36 AM
To: Rudd, Kevin <kevin@lps.umd.edu>
Cc: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: [NTG-context] problem embedding TABLE macros within wra= pper macros "to reduce repetitive complexity")

Rudd, Kevin schrieb am 09.09.2020 um 00:30:

Thanks. The immediate goal is to make a =EF=BF= =BDquad chart=EF=BF=BD w/ different pains in the four (2x2 =3D> NW, NE, = SW, SE) quadrants. It seemed that the concept was scalable to any NxM (even= with multi-cell spreads---useful for larger structured posters) based on TABLE. But I'd settle for 2x2 at the moment; at one poin= t I'd thought of 2x2+1 having a spanning block for publication referenc= es per slide but decided a separate publications slide was a better idea vi= sualy..

If they have to see an end command, would befo= re/after tags work around a framedtext or buffer structure?

1. 2x2 panes, layout order not important, all = panes independent; no flow (like Framemaker used to do) requiredbetween pa= nes.

2. was going to have inner frames (i.e. + = frame for 2x2 which was trivial to specify in TABLE) to separate the panes<= /div>
3. other than wanting the + frame, inner m= argins &c. for panes wsn't an issue either way.

When you need one than single block per line this definition

\define\startPaneRow{bTR\bTD}

\define\stopPaneRow{\eTD\eTR}

doesn't make sense because you limit yourself and after each table cell the= re is a new row.

While you can write code which moves your blocks around you should ask your= self the question is it worth it. When you have only two or three posters i= n this format use the extra commands for table rows and cells because it ta= kes more time to write something which does the work.

Wolfgang

--_000_DM5PR15MB19296DAB6D8A68F8A9095B37F1260DM5PR15MB1929namp_-- --===============5096514920548540622== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KSWYgeW91ciBxdWVzdGlvbiBpcyBvZiBpbnRlcmVz dCB0byBvdGhlcnMgYXMgd2VsbCwgcGxlYXNlIGFkZCBhbiBlbnRyeSB0byB0aGUgV2lraSEKCm1h aWxsaXN0IDogbnRnLWNvbnRleHRAbnRnLm5sIC8gaHR0cDovL3d3dy5udGcubmwvbWFpbG1hbi9s aXN0aW5mby9udGctY29udGV4dAp3ZWJwYWdlICA6IGh0dHA6Ly93d3cucHJhZ21hLWFkZS5ubCAv IGh0dHA6Ly9jb250ZXh0LmFhbmhldC5uZXQKYXJjaGl2ZSAgOiBodHRwczovL2JpdGJ1Y2tldC5v cmcvcGhnL2NvbnRleHQtbWlycm9yL2NvbW1pdHMvCndpa2kgICAgIDogaHR0cDovL2NvbnRleHRn YXJkZW4ubmV0Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCg== --===============5096514920548540622==--