Problems with table position in a PDF using PDF::Table

[Ted Byers]

Here is the relevant part of the documentation:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
$pdf, # A PDF::API2 instance
$page_to_start_on, # A PDF::API2:age instance created with
$page_to_start_on = $pdf->page();
$data, # 2D arrayref of text strings
x => $left_edge_of_table, #X - coordinate of upper left
corner
w => 570, # width of table.
start_y => $initial_y_position_on_first_page,
next_y => $initial_y_position_on_every_new_page,
start_h => $table_height_on_first_page,
next_h => $table_height_on_every_new_page,
....
}

Notice the specification of the meaning of next_y!

Here is what I have in my code:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
$pdf,
$page,
\@table2,
x=>$x,
w=>555,
start_y=>$y,
next_y=>$900,
start_h=> 250,
next_h=>500,
# optional parameters
padding =>2,
header_props=>$hdr_props,
column_props=>$col_propsM2,
);

No matter what values I give next_y or next_h, the continuation of the
table on the second page is ALWAYS placed in the middle of the page.

What I would really like to happen is to always have the continuation
of the table start at the top of the next page and to fill the page if
there is sufficient data. However, I have yet to find the magic
required to make that happen in the documentation for PDF::Table (the
package I am using for this).

Can anyone tell me either what I missed (is there relevant information
elsewhere than the man page for PDF::Table) or how I might fix or work
around this?

Thanks

Ted

 

[sln]

Here is the relevant part of the documentation:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
$pdf, # A PDF::API2 instance
$page_to_start_on, # A PDF::API2:age instance created with
$page_to_start_on = $pdf->page();
$data, # 2D arrayref of text strings
x => $left_edge_of_table, #X - coordinate of upper left
corner
w => 570, # width of table.
start_y => $initial_y_position_on_first_page,
next_y => $initial_y_position_on_every_new_page,
start_h => $table_height_on_first_page,
next_h => $table_height_on_every_new_page,
...
}

Notice the specification of the meaning of next_y!

Here is what I have in my code:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
$pdf,
$page,
\@table2,
x=>$x,
w=>555,
start_y=>$y,
next_y=>$900,
start_h=> 250,
next_h=>500,
# optional parameters
padding =>2,
header_props=>$hdr_props,
column_props=>$col_propsM2,
);

I don't know this package. But, do you notice that
you have an ODD number of parameters passed to
$pdftable->table ??

Usually, a package writer parses such input in pairs.
Unless say after \@table2, he is taking optional @args in pairs.
ie:

sub table
{
my ($self,$pdf,$page,$arrayref,@args) = @_;
}


sln

 

[Ted Byers]

Here is the relevant part of the documentation:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
     $pdf,               # A PDF::API2 instance
     $page_to_start_on,  # A PDF::API2:age instance created with
$page_to_start_on = $pdf->page();
     $data,              # 2D arrayref of text strings
     x  => $left_edge_of_table,    #X - coordinate of upperleft
corner
     w  => 570, # width of table.
     start_y => $initial_y_position_on_first_page,
     next_y  => $initial_y_position_on_every_new_page,
     start_h => $table_height_on_first_page,
     next_h  => $table_height_on_every_new_page,
...

}

Notice the specification of the meaning of next_y!

Here is what I have in my code:

  ($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
                 $pdf,
                 $page,
                 \@table2,
                 x=>$x,
                 w=>555,
                 start_y=>$y,
                 next_y=>$900,
                 start_h=> 250,
                 next_h=>500,
# optional parameters
                 padding =>2,
                 header_props=>$hdr_props,
                 column_props=>$col_propsM2,
  );

No matter what values I give next_y or next_h, the continuation of the
table on the second page is ALWAYS placed in the middle of the page.

What I would really like to happen is to always have the continuation
of the table start at the top of the next page and to fill the page if
there is sufficient data.  However, I have yet to find the magic
required to make that happen in the documentation for PDF::Table (the
package I am using for this).

Can anyone tell me either what I missed (is there relevant information
elsewhere than the man page for PDF::Table) or how I might fix or work
around this?

Thanks

Ted

A new observation related to this.

On increasing the amount of data to stress the code, and playing with
the mouse wheel, I noticed that the top of the table in question when
it is continued on the second page is precisely in line with the top
of the table as it appears on the first page, almost as if the next_y
parameter is ignored.

While I wait for a response, I will look into the code for PDF::Table,
much as I hate to debug someone else's code, to see if I can spot a
problem there.

I will report back here if I find something.

Cheers

Ted

 

[Ted Byers]

I don't know this package. But, do you notice that
you have an ODD number of parameters passed to
 $pdftable->table ??

Usually, a package writer parses such input in pairs.
Unless say after \@table2, he is taking optional @args in pairs.
ie:

sub table
{
        my ($self,$pdf,$page,$arrayref,@args) = @_;

}

sln- Hide quoted text -

- Show quoted text -

Yes, but that is the way he documents this package to work.

It seems clear to me that the first three arguments are required in
the order provided and that the remaining arguments are held in a
hash. His documentation wouldn't make sense otherwise. While I have
not yet looked at his code, my guess is that he strips off the first
three arguments and then places the remaining arguments in a hash.

Thanks

Ted

 

[Jim Gibson]

Here is what I have in my code:

($end_page, $pages_spanned, $table_bot_y) = $pdftable->table(
$pdf,
$page,
\@table2,
x=>$x,
w=>555,
start_y=>$y,
next_y=>$900,

Is that really '$900' in your code? That is probably undefined (unless
you have a very long regular expression in your code.)

 

[sln]

[snip]
Yes, but that is the way he documents this package to work.

It seems clear to me that the first three arguments are required in
the order provided and that the remaining arguments are held in a
hash. His documentation wouldn't make sense otherwise. While I have
not yet looked at his code, my guess is that he strips off the first
three arguments and then places the remaining arguments in a hash.

Or, splice the array by 2's, which is easier to control for name
manipulation and to aviod even'es hash requirements.

sln

 

[sln]

Is that really '$900' in your code? That is probably undefined (unless
you have a very long regular expression in your code.)

$900, holy cow..

 

[Ted Byers]

Is that really '$900' in your code? That is probably undefined (unless
you have a very long regular expression in your code.)

Yes. A typo. I am surprised, though, that it went undetected given
that the first line of the script is "use strict;" Is that a fluke,
or are there times when use strict won't catch an undeclared variable?

Thanks for spotting that.

Ted

 

[Uri Guttman]

TB> Yes. A typo. I am surprised, though, that it went undetected given
TB> that the first line of the script is "use strict;" Is that a fluke,
TB> or are there times when use strict won't catch an undeclared variable?

strict will detect undeclared vars. that $900 is as jim said a very
large numbered grab variable which never needs declaring. it would be
undef which is valid as a hash value. now if you interpolated it or did
some other stuff it would trigger a warning if warnings were enabled.

uri

 

[Ted Byers]

  >> >                  next_y=>$900,
  >>
  >> Is that really '$900' in your code? That is probably undefined (unless
  >> you have a very long regular expression in your code.)

  TB> Yes.  A typo.  I am surprised, though, that it went undetected given
  TB> that the first line of the script is "use strict;"  Is that a fluke,
  TB> or are there times when use strict won't catch an undeclared variable?

strict will detect undeclared vars. that $900 is as jim said a very
large numbered grab variable which never needs declaring. it would be
undef which is valid as a hash value. now if you interpolated it or did
some other stuff it would trigger a warning if warnings were enabled.

uri

--
Uri Guttman  ------  (e-mail address removed)  --------  http://www.sysarch.com--
-----  Perl Code Review , Architecture, Development, Training, Support ------
--------- Free Perl Training ---http://perlhunter.com/college.html---------
---------  Gourmet Hot Cocoa Mix  ----  http://bestfriendscocoa.com---------

Ah, OK. Learned something new today.

Thanks

Ted