[Date Prev][Date Next][Thread Prev][Thread Next][Date index][Thread index]

Re: st: Copy table--how to consistently get correct tab stops

From   "David Elliott" <>
Subject   Re: st: Copy table--how to consistently get correct tab stops
Date   Tue, 10 Jul 2007 16:58:21 -0300

I am relieved Chinh found my speculative analysis of the process Stata
uses to parse a block of table text to be correct.

In another thread ( )I have
been discussing Notetab, a programmable text editor that I use as a
development environment companion to Stata.  Two of the text
processing macros ("clips" in Notetab parlance) I have created will
attempt to parse a block of table text into tabbed output.  This
tabbed output can subsequently be pasted into a Spreadsheet or
Wordprocessor as a table.  I find it generally more faithful to the
original layout than Stata's Copy Table feature.  My routine does not
tabulate on single spaces, only 2+ spaces so is not as likely to trip
up on column titles.  However, it will fail in densely compact tables
with single spaces between columns.

For example, using the table in Chinh's post:

 Mileage |                   Repair Record 1978
   (mpg) |         1          2          3          4          5 |     Total
      12 |         0          0          2          0          0 |         2
      14 |         0          1          2          2          0 |         5
      15 |         0          0          1          1          0 |         2
      16 |         0          1          2          1          0 |         4
      41 |         0          0          0          0          1 |         1
   Total |         2          8         30         18         11 |        69

This is the result: (I'm not sure if the tab formatting will withstand
the eMailing process)

Mileage		Repair Record 1978
(mpg)	1	2	3	4	5	Total
12	0	0	2	0	0	2
14	0	1	2	2	0	5
15	0	0	1	1	0	2
16	0	1	2	1	0	4
41	0	0	0	0	1	1
Total	2	8	30	18	11	69

(This can be directly pasted into Excel, Word, WordPerfect to create a table)

- - -

I've been doing some thinking around how SMCL might be employed to
handle tabular output.  However, the basic nature of output would have
to be changed.  Remember, SMCL outputs to the results window only in
line mode and each line is independent of previous or following lines.
In paragraph mode, SMCL can affect the formatting of subsequent lines
and has {p2colset # # # #} which can be used to create a two column

I can envisage an extension to SMCL that would allow a paragraph-like
mode for results and some new commands that set up the cellular
structure of a table.  Imagine something like:

di "{tabon:{col 15:%15s}{dup 3:{col 8:%6.0g}}}"

to set up the cellular structure for a table. {tabon: opens tabular
mode and then the {col} command specifies cell width and format, aided
by {dup} to set up multiple identical columns.

di "{hdr:Variable{c |}||{span 3:Columns}}"
di "{hdr:`varname'{c |}||col 1||col 2||col 3||}"
di "{tabline}"
//imagine a forvalues or foreach loop here
di "{`level`i''{c |}||`val1_`i''||`val2_`i''||`val3_`i''||}
di "{taboff}"

{hdr} would overrule the numeric cell formats when writing header rows
and {tabline} would create a horizontal rule (perhaps even
intelligently joining with box drawing characters on adjacent lines)
and so on to create a hypothetical table:

    Variable |        Columns
     Foreign | Col 1   Col 2   Col 3
    Domestic |  17.3   136.2     0.4
     Foreign |  23.2    95.0     1.8

This uses familiar SMCL syntax construction with || as a column
delimiter.  One nice thing is that, once set up, there is a separation
of presentation and content in that one only need generate the cell
values without need for additional formatting.  I've included the
box-drawing {c |} in the SMCL, but perhaps the linedrawing around
cells could be part of the initial table setup.

Of course, the devil is always in the details.  Syntax and internal
consistency checking, handling overflow, creating defaults, checking
for proper closing of the {tabon} statement and so on would all be

Note that in this model, the cellular structure would be explicit and
Stata would "know" the alignment of the column tabs and be able to
retain them in any copy table process.

I really hope the development team keeps this high on the wish list.
There are a number of table languages out there (HTML TEX/LATEX) so
the structural terms and relationships of the components are well
know.  The trick is to turn it into a familiar syntax parseable within
an expanded SMCL engine.

Enough of my rambling, but just let me finish by saying I appreciate
that Statacorp is monitoring this and jumped into the discussion.

*   For searches and help try:

© Copyright 1996–2014 StataCorp LP   |   Terms of use   |   Privacy   |   Contact us   |   What's new   |   Site index