Re: D3 Output processor macros

Mark,

Thanks a bunch!!! The .read is what I may need (At least in the future)

Actually I'm creating a pretty good looking report with OP. With only a few
quirks to work around in order to get a real fancy-dancy report. Two quirks
that I found has to do with the .TCL command. The first was if in the OP
document two .TCL commands are to be executed and the second does not
produce anything to output, the information from the first .TCL command is
repeated. This duplicated data was fixed by running a .TCL command between
the two that really just prints a blank line. The other quirk was the the
..TCL command was inserting 'extraneous' form-feeds in the middle of the
page. And this was handled by ensuring the terminal depth was set to zero
when generating the report.

I find some of the power in the OP quite useful if the tricks can be found
to exploit the features. I've got a big report being generate with two
small OP items that produce a third OP item that creates the final report.
(Ya, I know... trying to follow along with that can be tricky) The first
sets the page settings and .chains to a second the .chains back to itself.
These two OP items together actually produce a third OP item that produces
the final report. I used this method because I haven't found a way of
having a .READNEXT work inside a .TCL command. This sort of operation I
expected as I don't expect too much in the way of some sort of recursive
interpretation of the commands. That would be kind of heavy programming on
someone elses part to try and keep everything straight. Thank goodness
someone gave the OP processor the ability to change the override character.

Here are my OP items that produce the third OP item:

LIB.DETAILED.DOC.HDR.TEMPLATE
001 .lm 0 .rm 0 .heading
002 _.oc ` _.tp 6 _.lm 0 _.rm 0 _.heading "'t' 'c' Library Document
Revision Listing 'xcj' Page: 'pl'"
003 .CHAIN LIB.DETAILED.DOC.TEMPLATE

LIB.DETAILED.DOC.TEMPLATE
001 _.lm 0 Book Number: .readnext Media: .readnext
002 Book Description: .readnext
003 _.lm 5 Document ID: .readnext Supplier: .readnext
004 Document Description: .readnext
005 _.tcl list lib.document.file ' .readnext' with ld.revisions
ld.revisions ld.rev.medias ld.rev.types ld.rev.dates ld.dates.rev.
rcvd heading " Current Revisions" (ihb
006 _.tp 6 _.tcl dlb.print.line
007 _.tcl list lib.document.file ' .readnext' with ld.del.revisions
ld.del.revisions ld.del.rev.medias ld.del.rev.types ld.del.rev
.dates ld.del.dates.rev.rcvd ld.ts.rev.deleted.date heading "
Superceded / Deleted Revisions" (ihb
008
009 .chain LIB.DETAILED.DOC.TEMPLATE


End of OP items

These two items are processed thought OP into a hold file, and then the hold
file is run through the OP processor for the final report.

It works great.

Regards,

Dale



"Mark Brown" <mbrown@xxxxxxxxxxxxx> wrote in message
news:IM3Re.7368$UE2.5834@xxxxxxxxxxxxxxxxxxxxxxx
> If all you're trying to do is insert additional, formatted text into an OP
> document, you probably should use the .READ command. Typically, my OP
> documents look like this:
>
> CBW
> .line length 76 .lm 0
> .read face
> .heading CBWindows v9.0 08/05'l'
> .footing 'l'Copyright 1985, 1994, 2000 by CMARC All rights reserved.
> Page 'p'
> .pn 1
> .read intro
> .read quick
> .read 1
> .read 2
> .read 3
>
> Where "face" looks like this:
>
> .bp
> .sk20
> .c .bf CBWindows
> .sk 1
> .c CMARC Basic Windows .xbf
> .sk 3
> .c Programmer/User Manual
> .bp
> .sk 48
> .c Copyright 1985, 1994, 2000 as a work in progress.
> .c All rights reserved.
> .c No portion of this work may be copied, disclosed, transferred, adapted,
> .c incorporated or modified in any way mechanical or electronic, without
> .c the express written permission of CMARC
>
> then I just OP DOC CBW and I get a formatted lead ***. The CBW
document,
> all 245 bytes of it, produces a 34 page users manual.
>
> The only thing I can think of is that since there was already a .READ
> command to insert data from the same or a different file, the .MACRONAME
> command must have been intended for just that: macros, things that don't
> typicaly contain data, sush as setting margins, page sizes, etc. If you
do
> that often enough within the document, then it makes sense to make it into
a
> macro that can be inserted anywhere with identical results. If you are
> documenting examples, you might make a .SMALLFONT macro to change font,
> indents, margins, etc, and then another .LARGEFONT to set it back.
>
> Other than that, it's probably a bug and should be reported, ala Tony G
(who
> really IS right about rattling the cage).
>
> Mark Brown
>
> "Dale Benedict" <dale_knowspam_benedict@xxxxxxxxxxxxxx> wrote in message
> news:Sr%Qe.219974$HI.188889@xxxxxxxxxxx
> >I agree that there should not be any extra data being included when
calling
> > in a macro, but I'm finding that a multi-line macro gets put on one line
> > without regard to the number of lines in the macro. Here's an example:
> >
> > mainopitem
> > 001 This is a test of calling in macros
> > 002 .calledmacro
> > 003 Now that we are back in the main OP item.
> >
> > .calledmacro
> > 001 I'm entering several lines in this macro
> > 002 to see how a multi-line macro
> > 003 looks when inserted into
> > 004 the main OP item.
> >
> >
> > [405] 2 items listed out of 2 items.
> > Min:library:op dlb.bp mainopitem
> > Page 1 dlb.bp: mainopitem 09:07:56 30 Aug
2005
> >
> > This is a test of calling in macros
> > I'm entering several lines in this macroto see how a multi-line
> > macrolooks when inserted intothe main OP item.
> > Now that we are back in the main OP item.
> >
> > End of example
> >
> > Now looking at the final output note that where there was an attribute
> > mark
> > in the macro, the output show the attributes place on the same line
> > without
> > even a space. I would have expected a <cr><lf> to place line one under
> > another just as shown in the macro.
> >
> > Am I expecting the wrong thing here?
> >
> > Regards,
> >
> > Dale
> >
> >
> >
> > "Mark Brown" <mbrown@xxxxxxxxxxxxx> wrote in message
> > news:G_OQe.7494$HR5.5923@xxxxxxxxxxxxxxxxxxxxxxx
> >> The Output Processor is basicly Runoff on steroids. It's got a ton of
> > stuff
> >> Craig Nuttle wrote for adjusting font sizes, centering with
proportional
> >> fonts, etc.
> >>
> >> Macros are just intended to insert data without having to actually
enter
> > it
> >> into the item. Therefore there is no "automatic" insertion of spaces
or
> >> anything else.
> >>
> >> Mark Brown
> >>
> >> "Dale Benedict" <dale_knowspam_benedict@xxxxxxxxxxxxxx> wrote in
message
> >> news:YnJQe.209608$9A2.59275@xxxxxxxxxxx
> >> >A few questions here:
> >> >
> >> > 1. Does anybody use the output processor? This is my little
survey..
> >> >
> >> > 2. Is the standard operation for using macros meant only for one
line
> > of
> >> > text? I ask this because when I try to use a multi-lined macro in
an
> >> > output file, the macro is crammed onto one line with zero spaces
where
> > the
> >> > attribute or value marks are in the original macro file.
> >> >
> >> > Regards,
> >> >
> >> >
> >> > Dale
> >> >
> >> >
> >>
> >>
> >
> >
>
>


.