TMG-L Archives

Archiver > TMG > 2006-02 > 1138990361


From: "Teresa Elliott" <>
Subject: RE: [TMG] End of Sentence Codes - a Second Proposal
Date: Fri, 3 Feb 2006 12:17:12 -0600
In-Reply-To: <200623115135.547427@Terry3>


I second.

That sounds really good Terry. It will do what I need it to do.

Teresa Ghee Elliott-IBSSG

-----Original Message-----
From: Terry Reigel [mailto:]
Sent: Friday, February 03, 2006 10:52 AM
To:
Subject: [TMG] End of Sentence Codes - a Second Proposal

I've read over again all the responses to my earlier attempt to state
a proposal for the much-discussed new feature to control how TMG
manages the ending of tag output, and now offer this revised proposal.
I think it addresses all the issues discussed.

The idea is to permit users to optionally suppress the automatic
period TMG now applies to the end of the output of any tag in
narrative reports. Uses might include:
- Joining the output of two or more tags into a single text sentence.
- Constructing special purpose text that ends with punctuation other
than a period, or none at all.
- Constructing tags with exhibits, but no text output.
- No doubt, applications not yet thought of. <g>

My current proposal addresses several functions related to how TMG
creates output text from a tag:

1. Automatic final period:
Add a new code, which I am calling [:NP:], which a) suppresses the
current function which removes any final punctuation supplied by the
user, and b) suppresses the addition of a period. Thus, any
punctuation supplied by the user is output, unchanged.

This code could be placed anywhere in the Sentence, and would apply to
that tag alone.

2. Spaces:
Make no change in the action of existing spacing rules. They are:
a) If conditionals are used, exactly one space is always output
between conditional terms that are included in the output, or between
a conditional term that is included and a non-conditional term.
b) If the final term is a conditional, no space is output at the end
of the output text.
c) Spaces between non-conditional terms are output unchanged.
Note that final spaces in Sentence fields and Memo fields are edited
out when the screen is closed, so none exist in currently entered
data.

Add a new code, which I am calling [:SP:], which creates a single
space in the output, and is not subject to removal by the features
described above. Thus, a user an insure that a space will appear in
output.

When a user intends to "splice" the output of two tags into a single
output sentence, this space code could be placed either at the end of
the first tag, or at the beginning of the second.

3. Capitalization:
Add a new code, which I am calling [:NC:], which suppresses TMG's
currently function that capitalizes the first work of text output from
a tag if the word is not already capitalized. Thus that word would
appear, capitalized or not, as it is entered by the user.

My proposed "rule" is that it applies to the next output word
following the code. Thus, when a user wants to "splice" the output of
two tags into a single output sentence, it could be placed either as
the last code in the first tag's sentence, or as the first entry in
the second tag's sentence. Should that be troublesome to program, I
propose an alternate rule, in which the code would always be entered
as the first entry in the tag whose output is not to be capitalized
(that is, the second tag).

4. Footnotes and Endnotes:
I propose no change in the placement of footnote and endnote
references. Thus, source notes and memos output as notes will generate
reference numbers or symbols after the last text or punctuation output
by the tag (but before any final space). As a result, if the output of
two tags is "spliced" into a single output sentence, the note
reference numbers will appear in the middle of the output sentence.

Note regarding all the new codes: If placed in a Memo, they apply to
the output if the a memo variable incorporates the memo contents into
the tag. If included within conditionals with a variable, they are
applied to the output if the field called by the variable is not
empty. If enclosed in sensitivity brackets, or in excluded text, they
are applied if the report options call for the inclusion of sensitive
or excluded material. I believe this is consistent with how existing
similar codes, such as formatting and carriage return, are processed.

As has been stated before, use of these codes is an advanced
technique, and it would certainly be possible for a user to apply them
in a way that produces unexpected results. My view is that when one
uses advanced techniques, one has to accept responsibility for
applying them in a way that produces the desired results. <g>

Thoughts? Comments? Would this do what users want it to do?

Terry Reigel


==== TMG Mailing List ====
Send all messages and replies to <>.



This thread: