Home Analytics Designing reports
The community of Analytics developers are invited to follow and participate in the developer network.
OpenText technical experts collaborate with supported customers and partners in the Magellan product area.

Birt doesn't seem to acknowledge the "rendered size" of HTML content

In Birt I have pagination set up, but when there is HTML content that spreads over multiple pages, the pagination doesn't occur as it would normally in onPageEnd

If I have say 100 Lines of the word "Hi
" in Auto format then the pagination works correctly as it spreads over the pages. But if I format it as HTML, then in preview mode it completely disregards the report size and just displays on the first page stretched beyond the limit (A4 Landscape), in PDF mode, it spreads over multiple pages but the pagination just stays at 1

I suspect it is related to the fact that when you see the HTML item in the report designer, it truncates the content to like 2 lines. I suspect the pagination/birt is treating it as this size for the pagination despite it being rendered over multiple pages.

I've attached a report example as described above, simply changing the content type of the Text between auto and HTML will show the problem I'm encountering

Anyone any ideas?


  • Note: There is a HTML line break markup after "Hi that got formatted in the post, noticed too late to edit

  • edited July 24, 2019

    Hi Joel,

    When formatting as HTML and exporting to web, I wouldn't expect there to be any page breaks. The concept of page breaks doesn't exist in web pages. The PDF emitter is a different story. The PDF page count not working in this scenario is a known issue.

    Could you describe your use-case in more detail:
    How is the HTML formatting added (i.e. data from database is pre-formatted with HTML tags, static data with manually added tags, etc.)?
    Why HTML formatting instead of report styles?
    Is it possible to use a table with each line of data in a detail row instead of using a Text element?

    There might be options to workaround the page count issue.

    Jeff F.
    Customer Support Engineer I
  • Hi jfranken,

    The data is being retrieved from an SQL Database where it's stored as preformatted HTML. It is editable on our software in a Rich text editor and then stored in the database as HTML. This is then retrieved via a script function which queries the database. Hence the inability to use report styles or lines of data in the detail row. In the real use case for this issue, there is a mix of grouped data (which paginates correctly with groups) and these HTML snippets which the user can edit on the server. So if these HTML snippets end up going overleaf then we encounter the pagination issue.

    Need anything else more specific I'll do my best but obviously I can't go into too much detail due to the sensitive nature of the work

  • Given the information you provided, I recommend creating a Scripted Data Set to get the data into the report. There must be delimiters inside the HTML data that indicate where to break the data. Otherwise breaking up the data will not work. You can break up an HTML string arbitrarily putting the individual sections on different pages, but there is virtually no chance it will display correctly with arbitrary breaks. In the example you provided, the <br/> tags could be used to break the data into individual rows in the Data Set.

    Add a table to the report to display the data. Replace the Data element in the table with a Dynamic Text element. Dynamic Text elements are designed to display HTML formatted data. One piece of information I don't have is your Designer build ID, but Scripted Data sets and Dynamic Text elements are available in all recent versions of OS BIRT and commercial OpenText BIRT.

    Jeff F.
    Customer Support Engineer I
  • Something else that may help is if you enable the "Repaginate when rendering to PDF" export option. The current page field will show correctly in PDF. It will not correct issues with the the total pages field if you are displaying that.

    Chad Montgomery
    Sr. Technical Support Specialist
Sign In or Register to comment.