Re: Filter input/parsing timing

[Nathan Bell]

I'm trying to create a barcode using the GNU barcode library. I've got a 
program that gives postscript suitable for being embedded (ie it takes 
the xsize and ysize that @Graphics generates and makes a barcode that 
fits those contraints).

When calling my procedure manually I can generate any barcode to any 
size. When I call it from within a larger procedure (in my case a page 
header) I can still size the barcode at will, but the passed-in variable 
gets printed out. In other words when I pass in 17830-363 I get a 
barcode that scans as 17830-363, but when I pass in a variable 
@PurchaseOrder with a value of 17380-363 I get a barcode that scans as 
@PurchaseOrder.

We generate hundreds of postscript documents using a lout definition 
file as a the style and a set of pieces of lout code as templates for 
different parts of the documents. For example, one of the steps in 
fulfilling a purchase order is assembling the different pieces of our 
product into the final product. We give the header procedure a set of 
named variables (like part name, purchase order number, date it's due to 
be shipped, etc). We want to expand the header to include a barcode of 
the purchase order in order to alleviate some human mistakes in writing 
down the number for other uses. For the rest of the assembly notes we 
use a database of note definitions that generate a complete lout 
document based on which parts are needed for a specific order.

I used the sort function as an example of how filter doesn't work as 
anticipated as the sort function is used as the example of how to create 
a filter in the Expert's Guide to the Lout Document Formatting System. 
Everything would work fine if there was some way to change the variables 
to the values they represent.

Jeff Kingston wrote:
> > Is there a way to force lout to analyze the value of @a, @b, and @c
> > before it passes them along to the filter?
> >     
>
> No. Filter input comes straight from the input file in every case.
> This is what it's for: to bypass the Lout parser in cases where
> the input format doesn't conform to any Lout grammar, such as
> computer programs and the like.
>
> There is no way to insert user-defined functions into the object
> evaluation process, other than functions defined in Lout; and Lout
> is not a fully-fledged programming languages, so there are things
> you can't do in it, such as the sorting of your example.
>
> If you tell us what you are actually trying to achieve, there
> might be another way.  At the moment your email is artificially
> constraining the discussion to one method of solution, which is
> not working.
>
> Jeff
>