<p>I included this in a previous post but I thought I would start a new one to see if anyone has any work arounds.</p>
<p> </p>
<p>I have a lot of html tags in the data I am using to generate a report. I am using BIRT 4.6.0. I use the separate run and render to generate my report since I have some fields in my headers that are based on variables that get figured out after the run portion. The final output I am looking for is a pdf. So I first run the report to the web viewer and then I export it to a pdf.</p>
<p> </p>
<p>The html tags in my data appear to cause all sorts of problems in the final rendered report. Basically it seems like the html tags although invisible in the rendered report are taking up space, at least when they come at the end of a line. When I have a long row that wraps to the next line and there is an html tag at the very end of a line the row wraps prematurely. In the end what seems to be happening is that there are additional lines on a page and when I export to a pdf using the fit to "auto" option a few lines gets orphaned on a page. Other issues are extra blank lines and orphaned commas, parenthesis marks, semicolons, and periods.</p>
<p> </p>
<p>Since this is difficult to explain I have set up an example using the Classic Models database. See attached report. What this report displays is pairs of rows. The first pair has html tags and second doesn't. I have used underline html tags in this case (i.e. <u> </u>). To make it easy to see this, I placed the words with html and wi/o html in front of the corresponding rows. So run the report to the web viewer and everything looks good. Then go ahead and export to pdf using the fit to "auto" method (I have attached the pdf that result from this here). You will see that for some row pairs they are different (and not just the underlines that result from the html tags). For example on the first page of the report look at the 5th and 6th row pairs (I have circled them in my attached pdf, these are the row pairs that have Jonas Bergulfsen and Susan Nelson as the peoples names). You will see that in the non html tag examples that the data has wrapped sooner than in the example which lacks the html tags. I believe this is the case due to the html tag coming between the semicolon and the text and this acts as a space and since it is at the end of the line the semicolon moves to the next page. I explained this in an earlier thread <a data-ipb='nomediaparse' href='
http://developer.actuate.com/community/forum/index.php?/topic/39938-when-exporting-to-pdf-html-tags-are-acting-like-space-at-end-of-line/'>(see that thread).</a> The bigger issue is that somehow these html tags are also causing what would have been one page to spill over into a second page and orphaning a line or two on page. Again take a look at the attached pdf or the one that you generate. You will see that there are two page ones. The second page one has just a little bit of text.</p>
<p> </p>
<p>For a while I was exporting to a pdf using the fit to "actual size" method. This took care of the orphaned lines on a separate page but then I realized there were problems with the page size. When I compared the page size in my outputted pdf with the page size I had set in the master page within the report they were different. Also I noticed that the page sizes differed from page to page. In my own project I have tons of html tags so the difference in page sizes between pages is dramatic. In the example I created here there is some difference but it is relatively slight. For example I have set the page size in my master report to 5 x 8 inches but the outputted pdf (when exporting to a pdf using the fit to "actual size" method) is 5 x 8.04.</p>
<p> </p>
<p>Anyway, like we figured out in my other thread this appears to be a bug. I filed a bug report (see <a class="bbc_url" href="
https://bugs.eclipse.org/bugs/show_bug.cgi?id=510644" title="External link">
https://bugs.eclipse...g.cgi?id=510644</a>). Still I am in production mode now and need to have this issue resolved. Can anyone think of a work around or can anyone help me get this bug to be looked at. Or what should I do??</p>
<p> </p>
<p>Thanks</p>
