HTML vs PDF output

[bbtresoo]

HI guys,

I'm looking for some tips to avoid some output issues when converting one format to another . For instance when I convert report from HTML to PDF I found out that some tables , blocs set up can harm the output in the PDF and not in the HTML. For instance I still don't understand  how come I can manage to display Pagecount() function on the page footer in the PDF output and not in the HTML output. You can give it a try it's surprising, some behaviors are different may be some advices and tips exist , thanks for sharing .

Cognos Version 10.2.1

[intrepid402]

To display the page count in the PDF and not in HTML, make a variable with expression ReportOutput() with values HTML, PDF

Now in the footer, make two tables. One table having values/text that you need for HTML and another for PDF. Render each table using 'Render Variable' and for appropriate values.

[intrepid402]

Also, if you need the whole page rendered differently, like the list, crosstabs and everything in the report, you may try creating a new page and render the pages based on ReportOutput() and render the PDF page only for pdf output.

[navissar]

Right, this is one of my favourite topics (Isn't that sad...), so let's get right down to it:
Let's start with the basics. There are three main differences one should keep in mind when designing a report between HTML and PDF:
1. PDF is static, HTML is dynamic. That means that object such as prompts, javascript and so on are not rendered in PDF.
2. PDF has a predefined, set page size (usually A4). HTML doesn't really have "pages", since you can scroll through gazillions of rows and columns. Pagination is dynamic and based on the developer's selection. This means that a report which looks great on screen might break horizontally on PDF, or that a report with no pages might paginate on PDF.
3. PDF reports pull out all of the data, HTML reports only pull the data they need to display in current page. So, running a report in PDF which returns a 100 rows will return all 100 rows, and on HTML it will only return the first n rows as selected in page properties (Default 20).
Combine the three together and you'll know why page count doesn't work on HTML: When running the report in HTML, we only return the first n rows, so we don't know how many more rows are there. We do not render all the data, and page size is dynamic, so there's no real way to count the pages before running through all of them. In PDF, the output has to contain the number of pages, so we can count them.

So that's the basic stuff, and if you memorize that you should be good to go and know what to look for. But here's another thought I find not often do developers pay attention to. Why would users post their reports to PDF? It's a static format, so it doesn't allow manipulation. It's not as comfortable as browser data (Where scrollbars respond better). The only reason I found to export to PDF is in order to print. So, whenever possible, I try to make the PDF version of a report (Using a variable with "reportOutput()") as printer-friendly as possible - no colours, no big headers, repeating necessary data like prompt values on all pages and so on, so that the printed output may look nothing like the HTML version, but it makes better sense once out the printer...

[bdbits]

PDFs are sometimes required for a variety of reasons. For example, the report has to be submitted to a regulatory body, or archived in a document management system. Or, the report is to be put on a public web site but Cognos is not available to present the report outside the local network.

It's not always about printing.  8)

[bbtresoo]

Hi Guys,
Tks a lot for your different responses, now it makes a lot of sense to me   ;D

[bbtresoo]

Right, this is one of my favourite topics (Isn't that sad...), so let's get right down to it:
Let's start with the basics. There are three main differences one should keep in mind when designing a report between HTML and PDF:
1. PDF is static, HTML is dynamic. That means that object such as prompts, javascript and so on are not rendered in PDF.
2. PDF has a predefined, set page size (usually A4). HTML doesn't really have "pages", since you can scroll through gazillions of rows and columns. Pagination is dynamic and based on the developer's selection. This means that a report which looks great on screen might break horizontally on PDF, or that a report with no pages might paginate on PDF.
3. PDF reports pull out all of the data, HTML reports only pull the data they need to display in current page. So, running a report in PDF which returns a 100 rows will return all 100 rows, and on HTML it will only return the first n rows as selected in page properties (Default 20).
Combine the three together and you'll know why page count doesn't work on HTML: When running the report in HTML, we only return the first n rows, so we don't know how many more rows are there. We do not render all the data, and page size is dynamic, so there's no real way to count the pages before running through all of them. In PDF, the output has to contain the number of pages, so we can count them.

So that's the basic stuff, and if you memorize that you should be good to go and know what to look for. But here's another thought I find not often do developers pay attention to. Why would users post their reports to PDF? It's a static format, so it doesn't allow manipulation. It's not as comfortable as browser data (Where scrollbars respond better). The only reason I found to export to PDF is in order to print. So, whenever possible, I try to make the PDF version of a report (Using a variable with "reportOutput()") as printer-friendly as possible - no colours, no big headers, repeating necessary data like prompt values on all pages and so on, so that the printed output may look nothing like the HTML version, but it makes better sense once out the printer...

Tks for the detailed explanation, sounds logical now but tell me one thing, how come the behavior of PageNumber function is different depending on the output( HTML and PDF). I tried it in a conditionnal formating it works fine in the HTML not in the PDF. tks for your feedback