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 the table setup commands to avoid 
some level of replication? Or is there a better 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 Engineering (CACE)
Advanced Computing Systems (ACS) Research Program
Laboratory for Physical Sciences (LPS)
443-654-7878
ke...@lps.umd.edu
Visiting Research Professor
Electrical and Computer Engineering
United States Naval Academy
r...@usna.edu

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

Rudd, Kevin schrieb am 09.09.2020 um 00:30:
Thanks. The immediate goal is to make a �quad chart� w/ different pains in 
the four (2x2 => 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 point I'd thought of 2x2+1 having a spanning block for publication 
references per slide but decided a separate publications slide was a better 
idea visualy..

If they have to see an end command, would before/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 panes.
2. was going to have inner frames (i.e. + frame for 2x2 which was trivial to 
specify in TABLE) to separate the panes
3. other than wanting the + frame, inner margins &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 there 
is a new row.

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

Wolfgang

___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________

Reply via email to