when exporting to pdf html tags are acting like space at end of line

I am not sure which forum this post belongs in the "Integrating with BIRT Runtime" forum or this forum. I posted to the former and have not gotten a reply so I am now trying it on this forum.
 
I am using BIRT 4.6.0. My browser is Firefox 50.1.0
 
In my report I am using data that has html tags, in particular and . So I insert a dynamic text element and have the content type set to HTML. The data in the field is long enough that it wraps to another row.
 
When I am ready to print the report I first View report in web viewer. From there I export report using the PDF format and set the Fit To field to actual size. Although view report as pdf replicates the issue I am having.
 
The Web Viewer report works as expected. But when I export to the pdf there seems to be an issue. The issue is that when the end of a row of data happens to come where an HTML tag occurs this HTML tag appears to be interpreted as a space. Normally this isn't an issue. But I have some commas separating text and these end up getting forced to the next line when the HTML tag is at the end of the line. Therefore the comma is isolated on its own line. This doesn't show in the web viewer but does in the pdf.
 
This is difficult to explain so I am attaching a report that uses the sample Classic Models database. I have created two data fields, one with html tags and one without html tags. I am also attaching a pdf of the results. In the PDF note how the data associated with Michael Frick displays. In the line that doesn't use html tags you can see the last "USA," of the row gets pushed into the next row. In the line that uses html tags the "USA" remains on the last line and the "," gets pushed into the next row creating an isolated comma.
 
Is there some way I solve this problem? Thanks.

Find more posts tagged with

Comments

jfranken

I tried a few iterations of adding different tags and styles to try to prevent wrapping between the word and the comma. None of them had an effect on the PDF output. I can think of a couple of other options:
- Look at third party emitters and see if any of them wrap text differently in PDF.
- Move the tags to surround all of the text including the commas. You could have one set enclose the entire string. That would make the commas bold which might not be ideal, but it might be better than the current result.
 
Regards,
Jeff

David1000

Thanks for giving this a try Jeff. Do you have any suggestions for a third party emitter?
 
Thanks too for the suggestion of the work around. I am currently using that work around. It is better than having the isolated commas but not ideal.
 
Thanks again,
David

jfranken

Hi David,
 
The third party emitter that I have used is the Spudsoft emitter. I used it for a case involving an Excel output. I checked to see if Spudsoft has an emitter for PDF. Unfortunately they don't. The only option might be for you to submit this issue as a bug if nobody else has a suggestion.
 
Regards,
Jeff

David1000

Thanks Jeff. I am working on getting permission so that I can file this as a bug.
 
David

David1000

So I did go ahead and file a bug report. See <a data-ipb='nomediaparse' href='https://bugs.eclipse.org/bugs/show_bug.cgi?id=510644'>https://bugs.eclipse.org/bugs/show_bug.cgi?id=510644</a> 
Now I am finding out that this bug is causing some other bigger issues. The bigger issues have to do with pagination. I have modified my last test report so that it is even easier to see these issues. I have attached it here. I explain the further problems that this bug is causing me below but my question is how do I get this bug dealt with? It doesn't look like anyone has touched the bug report I filed about a month ago now. I am in production stage and I really need to deal with this issue. Thanks for any help anyone can provide. 

The new issues I am noticing is that due to the html tags being perceived as a space when they end up at the end of line (and perhaps elsewhere), they end up causing additional rows per page which in turn causes uncalled for page breaks which then leaves a row or two orphaned on the next page.
 
Take a look at my test2 report and the corresponding pdfs. I have attached two separate pdfs. One comes from exporting from the web viewer as fit to "auto" and the other comes from exporting from the web viewer as fit to "actual size". If you take a look at the fit to "auto" pdf you will see these issues I mentioned above. In fact take a look at the page numbers I placed in the footer. You will see there are two page 1's. The fit to "actual size" will not show these issues because the pdf is exactly replicating the web viewer. So this seems like it could be a work around. But if you take a look you will see that in the fit to "actual size" pdf the page size (check the properties) is not what it should be. In this case I have the page size set to 5 x 8. Also if you look closely you will see that some of the pages are actually different sizes. In this test2 report for the pdf with fit to "actual size", the difference from what the page sizes should be and the different size of each page is slight but in my actual report where I have a lot of html tags the page sizes vary dramatically.
 
This is difficult to explain so please let me know if you need more clarity. And again my big question is how can I get this bug dealt with? Thanks.