Thanks, but alas, that didn't work for me when I tried to make the columns a different width. On my system, to make your code run, I had to provide a width to the table, in your call to table's constructor. That aside, the colours and aliognment worked fine, regardless of the presence or absence of the leading hyphens. And while it seems easy to make the columns equal width, there seems to be no way to make the right column consistentlly to take one fifth of the table width and the left column to take the rest.

But to get a better test, try making the values in the left column arbitrary strings of variable length, and the right columns random currency values from $0.00 up to $999,999.99, and have three or four tables that use the same column properties, similar variability in the length of the strings in the left column but order of magnitude differences in the currency values between the tables (i.e. if in the first table the values are of the order of $10,000, make those in the second table of the order of $10, and those in the third of the order of $100,000). What you will see is that the layout of each table adapts to the data it is presenting, instead of the specs in the column properties. It is late, but I will work up an example of this sort in the morning, unless someone beats me to it.

Thanks again

Ted

Comment on Re^2: PDF::Table seems to ignore column properties when there are but two columns

What you will see is that the third table gets a right column that is bigger than the rest, and then the fourth gets a right column that is narrower than the rest. What is required is that the table actually respect the properties specified in col_props, so that I can adjust the width of the right column so that it will always accomodate the largest currency value I know exists in my data, and use that in all tables using a given col_props variable.

But I did notice that if I use a single instance of 'balance' in the fourth table, the table uses what looks like the same widths as those in the third table. Does the function 'table' actually modify col_props in those cases when it has the temerity to over-ride the values I coded? If so, what can be done about that?