When generating a PDF from collected data, the bottom of a page can be split much differently on Windows vs Ubuntu Linux

[matt.wright_1]

I'm using JasperReports 6.4.1 for this.  Odd things happen due to stretch with overflow being turned on between a linux and windows render of the same report information.

It is a complicated subreport of which this part is the actual content.  The page contains multiple bands and two separate group by specifications as well.

The field being rendered is an html textfield in its own band and the text placed into this field has limited html encoding (e.g. paragraph and list item types may be included).

A subset of the release notes line of text to render in a pdf is this (only paragraph types are in the html, I include the first <p> but truncated the actual text for brevity)  :

"<p>...Optionally, the group can be limited to a single market or commodity. A single hedge position can be in multiple hedge action groups. The Excel Uploader includes the following new worksheets to support this functionality: HedgeActionGroup; HedgeActionGroups.</p>" 

On our production Ubuntu Linux server the following is rendered:

'limited to a single market or commodity. A single hedge' (this text between the ticks is rendered on the last line of a page, note the report engine decides to split the line and stretch almost exactly in the middle for some reason)

The next page then contains the following text looking just like the below (between ticks):

position can be in multiple hedge action groups.

The Excel Uploader includes the following new worksheets to support this functionality: HedgeActionGroup; HedgeActionGroups.

On my laptop or our test windows server the following is rendered for the same report:

'limited to a single market or commodity. A single hedge position can be in multiple hedge action groups.' (this text between the ticks is rendered on the last line of the page generated on the windows system, note the text is all on one line)

The first line of the next page from the windows report is:

'The Excel Uploader includes the following new worksheets to support this functionality: HedgeActionGroup; HedgeActionGroups.' (between the single ticks)

 

Font is SansSerif on both systems, configuration of the jrxml is identical.  Here is the jrxml for this last band in the Content.jrxml detail section:

        <band height="20" splitType="Stretch">
            <printWhenExpression><![CDATA[$F{release_notes} != null && !$F{release_notes}.equals("")]]></printWhenExpression>
            <textField isStretchWithOverflow="true" isBlankWhenNull="true">
                <reportElement stretchType="ContainerHeight" x="20" y="2" width="515" height="16" isRemoveLineWhenBlank="true" isPrintWhenDetailOverflows="true" forecolor="#000000" uuid="25bf43f6-ef30-47c2-982d-ec4b43af073d">
                    <printWhenExpression><![CDATA[$F{release_notes} != null && !$F{release_notes}.equals("")]]></printWhenExpression>
                </reportElement>
                <textElement markup="html">
                    <font fontName="SansSerif"/>
                    <paragraph lineSpacing="Single" lineSpacingSize="1.0" firstLineIndent="0" leftIndent="0" rightIndent="0" spacingBefore="0" spacingAfter="0" tabStopWidth="40"/>
                </textElement>
                <textFieldExpression><![CDATA[$F{release_notes}]]></textFieldExpression>
            </textField>
        </band>
 

This setup with Fix Relative to Top and Container Height are just my last attempts at seeing any different (and better) rendering on our linux server.  Original setting was Float and No Stretch with the same results.

I have looked at some older references that are somewhat similar but, none of them were very recent and, after changing various configuration parameters with no luck, have run out of ideas of what else to look at.

Anyone have any ideas what else to look at in the configuration?

[matt.wright_1]

Hi all, this turned out to be an instance where JasperReports didn't complain as to the font being used (Sans Serif) but, it wasn't doing the right thing.  When I switched to DejaVu Sans or DejaVu Serif, this worked just fine.