header and footer: calculating when they have to be printed

sorry, it was not published in the workflow and, of course, you couldnt see it.
now it is public
http://mientrastanto.org/1-las-agencias-de-rating-han-dejado-de-estar-ba...
i attach the view, and i use the display "pdf 1 articulo" for the pdf presentation.

edit since my clients are trying the site, they removed the article.
i attach a html http://drupal.org/files/issues/las-agencias-de-rating-han-dejado-de-esta... .

i upload the bad pdf because i am changing the web.
if i edit with 6.x-1.0-beta5 and save, and then use 6.x-1.0 and dont edit the row style of the pdf fields, it works.
the file was originally made in the beta5... can it have something to do?
but as soon i open and save the row style of the pdf fields, it starts to eat the numbers...
i hope it helps you to debug :)
http://drupal.org/files/issues/483.pdf

i found more information about this issue:

when i reported, i was making pdfs of one article, now i have been doing a magazine and i see that when a field has more than 2 pages, the page in the middle doesnt get the number. the same articles produced with 6.x.4 get the number ok. but i cant use it because has problems with the error that you resolved about theme on the new release.

i hope this helps to you to fix it :)

hello

i created a very simple view to check this bug in style 'PDF unformatted'.
this bug it is not present in 6.x-beta4 and starts in beta5 and it is still in version 1.
i think it is related to "Minimal Space" new option on the user interface, but i can be wrong.

to reproduce: i attach the view and you need to create a node with a body of 3 pages or more:

• the view created in 6.x-1.0 that only has a number field and a body.
• 2 pdf: how it is seen if view is saved in 6.x-1.0 or in 6.x-beta4.

in a node that has 4 pages, what i found is:

• if the view is saved with beta4:
  • the numbers and pages are ok in beta4.
  • beta5 and 1 and no extra pages but only first and last page get numbers. because this i think the problem comes from "Minimal Space".
• if the view is saved with beta5 or 1:
  • the numbers are ok in beta4 and not extra pages.
  • in beta5 and 1, 2 white extra pages are added at the end, only first page has number in place and 6th page gets the number 5 out of place.

i hope this will help to you to find why and make this module even better than it is :)
thanks a lot

i put priority major since a client will not accept a pdf that has not all the numbers... if you think it is not, please change it.

more info:

all before was done in the footer.

with one element in the header and field in several pages: no extra pages but it only renderes in 1st and last page. (if it is in the footer it gets the 2 extra pages).

if you put 2 elements in the header/footer, things get crazzy not only with field more than one page.

and now i go to work in other part of the site, i hope this helps you to solve the problem :) thanks

i think this tittle is better :)

attach for comment #2

since i gave information, i think i can change the status... if i do wrong, please change it :)

my bad english ... :)

hello

since i finished the site but this problem, i come to see if i can help to detect what is going on :)

i downloaded the last dev version since i saw hunziker has renovated it (thanks).
i searched for the place where it is done and compared with the 6.x-1.x-beta4 where the numbers get ok.
i am tired and i didnt find a solution... but i put what i see, in case it helps.

in views_pdf_plugin_row_fields.inc, function render, line 36, the code changes from (first old version):

<?php 
                    if ($options['position']['object'] == 'header_footer') {
          // Set or update header / footer options
          $this->view->pdf->setHeaderFooter($row, $this->options, $this->view);
        }
?>

to

<?php 
       // Set or update header / footer options per row
        // this ensures that we write the last record for each page
        // in the cache.
        $this->view->pdf->setHeaderFooter($row, $this->options, $this->view);
?>

if i replace it, then the extra page disapears, but i get a number only in the first page.

if i mix both, then i am, without the first extra page and numbers at the begining and at the end. (i put the php tags for better reading)

<?php 
        $this->view->pdf->drawContent($row, $options, $this->view, $id);
               if ($options['position']['object'] == 'header_footer') {
          // Set or update header / footer options
          $this->view->pdf->setHeaderFooter($row, $this->options, $this->view);
        } $this->view->pdf->setHeaderFooter($row, $this->options, $this->view);
?>

mm all this is in a loop, and then you render the number out of it

<?php 
 // Reset the row page number
      $this->view->pdf->resetRowPageNumber();

?>

my problem is that i have fields that are 3 or more pages, so shouldnt the page counter be renewed in other way diferent than the number of items since one field can be in more than two pages?
i am not a programer, so for me this is toooo much :))))

i searched in internet an found a function for getting the page number independent of this loop... o.o
just in case that i am in the right direction, i paste it here:
font http://php.net/manual/en/ref.pdf.php bolyde at gmail dot com 12-Apr-2009 07:27

<?php
public function getNumPagesInPDF(array $arguments = array())
{
@list($PDFPath) = $arguments;
$stream = @fopen($PDFPath, "r");
$PDFContent = @fread ($stream, filesize($PDFPath));
if(!$stream || !$PDFContent)
    return false;
   
$firstValue = 0;
$secondValue = 0;
if(preg_match("/\/N\s+([0-9]+)/", $PDFContent, $matches)) {
    $firstValue = $matches[1];
}
 
if(preg_match_all("/\/Count\s+([0-9]+)/s", $PDFContent, $matches))
{
    $secondValue = max($matches[1]);
}
return (($secondValue != 0) ? $secondValue : max($firstValue, $secondValue));
}
?>

hunziker, any tips or ideas? :)

edit someone, in a different project but problems with long fields, say it used
"Print When Expression" set to "$V{PAGE_NUMBER} == 1" which is working,
http://jasperforge.org/plugins/espforum/view.php?group_id=83&forumid=101...

and i tcpdf: there is a variable (this i write for me, that hunziker sure knows :))))

$page (line 121)

* var: page number
* access: protected

and now to bed... let's see if we can solve tomorrow....

my bad english... O.O

my client ask for more changes and i dont find the solution to this bug... :(

bad bad... dont touch code when you are tired and the code is done by other person that knows much more than you... :)
dont do what i made because if a rule calls your view and you use views php, you get your functions duplicated... O.O

today that i can investigate for a while, i will look into views_pdf_template.php, since in line 152 i found this:

  /**
   * This method must be overriden, in the other case, some
   * output is printed to the footer.
   */
  function Footer() {
  
  }
  

also i will learn git.
if i dont get any results... i will have to use other module... what i dont want to since i like this one a lot and i have spent a lot of time learning how to use it...
any results, i will tell here :)

by the way, hunziker, thanks for commenting so well the code :)

i found a solution using the function Footer() while this bug is fixed
i posted it as a new issue to use for documentation
http://drupal.org/node/1255112

@gillarf i didnt answer any of your doubts because i didnt use this module again and i didnt found other solution.
thanks for reporting your solution that i would try if i need this module again (probably).