last line of isStretchWithOverflow not shown

[2004 IR Help]

By: John Pollard - johnnypoll

last line of isStretchWithOverflow not shown

2005-02-04 06:55

Unless I tack a + "n" onto the end of the contents of my isStretchWithOverflow blocks, the last line is not displayed.

 

These reports have been working fine, the problem appeared following a s/w upgrade from Mac Jaguar to Panther and from Java1.3 to Java1.4.

 

I have moved to the latest jasper 0.6.4 and itext 1.0.1 but nothing seems to help. I'm sure I remember a similar problem with jasper from way back, but I can't dig out the info.

 

The only slightly strange thing I do is to serialise my filled reports to get them from the server and deserialise them on the client. But again this has always worked fine before.

 

Thanks

John

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-02-05 04:14

Hi Teodor,

An example textField where I have the problem is as follows. I have inserted the + "n" just to force the last line of this stretchy field to show.

If I didn't have the + "n" then my viewer doesn't show the last line of stretched fields, yet generating a PDF from the same JasperPrint does cause the line to appear; i.e. the generated PDF is fine, even when there is no n

I'm not using jdt-compiler.jar; I only noticed this when recently upgrading and had a problem when including it so decided to leave it out for now.

Also, my viewers are quite old code (as I customised my viewer), but I don't think that matters does it because it is the underlying engine code that generates the viewable content.

 

<textField isBlankWhenNull="true" isStretchWithOverflow="true">

<reportElement x="0" y="2" width="87" height="13"/>

<textElement/>

<textFieldExpression class="java.lang.String">

$F{Item} + "n"

</textFieldExpression>

</textField>

 

Cheers

John

 

 

 

 

By: msa - amysore

RE: last line of isStretchWithOverflow not sh

2005-03-25 16:29

Hi,

 

I have the same problem too. The last line is not displayed.

 

I am using Jasper Reports 0.6.5 and a CustomDataSource. I have a report with 4 text fields. I use isStretchWithOverflow="true" with all the text field elements. It works fine if I add the "n" . Thanks John for the tip.

 

Does anyone know how to resolve this without the "n"

 

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-04-21 12:36

Reviving this old problem, I still have to add "n" to any fields which stetch with overflow to get the last line to display. This isn't just on my Mac, but also on a Win XP PC with the latest Java 1.5 installed. It does however only seem to happen when my JasperPrint is passed over a network from server to client for display.

 

I serialise as follows on the server side as follows:

 

ByteArrayOutputStream out = new ByteArrayOutputStream();

ObjectOutputStream objectOut = new ObjectOutputStream(out);

objectOut.writeObject(jasperPrint);

NSData data = new NSData(out.toByteArray());

 

The NSData is an Apple WebObjects Foundation class to hold a byte array. This is returned to the Java Client by an Apple distribution framework.

 

On the client it is unpacked as follows:

 

NSData jasperPrintData = (NSData) reportData;

ByteArrayInputStream in = new ByteArrayInputStream(jasperPrintData.bytes());

ObjectInputStream objectIn = new ObjectInputStream(in);

JasperPrint jasperPrint = (JasperPrint) objectIn.readObject();

 

If anyone has any idea how this serialise/deserialise may have caused the stetchy fields problem, I would love some help as it is really hampering my use of Jasper - my fields are expanding too much due to the extra "n" I have to add to fields.

 

 

 

 

By: Franck Andriano - altern

RE: last line of isStretchWithOverflow not sh

2005-04-22 02:51

Mmmh... i saw that... just a problem CR LR (Carriage Return/Linefeed) in template .jrxml (Devolppment in Windows... production in Linux)

 

Transform your template .jrxml window/dos in Linux format...(or inverse) or compile your .jasper in your product platform.

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-04-25 04:21

Thank you for these ideas altern.

 

I'm developing and deploying to Mac OS X UNIX. I can edit the xml template using vi on the deployed server and compile the report on that platform too, but the problem persists. I would have thought that carriage returns and line feeds in xml files should not impact on the filled report provided the XML parser can parse the file.

 

I've done more testing and the problem is not introduced during serialization / transfer of the JasperPrint from server to client as I wrongly thought before; the JasperPrint generated on the server side has the fault prior to being sent anywhere.

 

If I instead pass the report data from client to server and fill the report on the client side the problem goes away. But I swear I'm using the same jasper and itext jars in each case (itext 1.01 and jasper 0.6.4) so it is something else about my deployed environment that introduces the problem.

 

Note also that the same faulty report looks fine if saved to PDF from Jasper Viewer and then viewed as a PDF - then that hidden last line of a stretched field reappears within the PDF viewer. But Jasper Viewer isn't itself under suspicion because of the various circumstances described earlier where the report appears fine. Somehow the report is being filled wrongly on my deployed servers (both deployed servers have the same problem).

 

 

 

 

By: Teodor Danciu - teodord

RE: last line of isStretchWithOverflow not sh

2005-04-25 05:03

 

Hi,

 

I think this has something to do with the line separator

characters on the machine that performs the reports filling.

I suspect that you are generating documents using

text data stored inside your database. The text data

already contains line delimiters like "n" or "rn".

Depending on the operating system you are running,

the line break behavior could be different.

 

I would try to interogate the "line.separator" system

property on the machine that fills the report and also

on the machine that displays the document.

If they do not match, then we have some clue.

 

I hope this helps.

Teodor

 

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-04-26 02:30

Thanks for ideas Teodor,

 

I have output the line.separator property unicode values on the server and client boxes. They both show that line.separator is a single n character, unicode value = a

 

Mac OS X is UNIX based as you know and I have read that a single n is as expected for UNIX as a newline.

 

Both Mac OS X boxes obtain the data from mysql, but I am fairly sure that the data doesn't itself have embedded newline characters - I assume that stretchy fields are not expecting a newline of whatever variety at the end.

 

When I add the "n" to all fields they do stretch, presumably because they expect to show a blank line under the field - so the stretching is happening, but the last line of wrapped text just remains invisible (until saved to PDF when it reappears).

 

John

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-04-27 01:48

I had a thought that this may be related to headless operation, since my servers are running with no desktop user logged in and though I don't understand the implications of this I've seen a resource location problem relating to this which was solved by running the application as root.

 

In this case I am already running as root and I additionally tried setting -Djava.awt.headless=true in the program args but it didn't help. That last line of my stretchy fields still shows up as blank despite the stretching happening ok.

 

 

 

 

By: tec_ak1 - tec_ak

RE: last line of isStretchWithOverflow not sh

2005-04-29 02:13

I had the same problem. My solution was to remove the useless Attribute "printOrder="Horizontal"".

 

 

 

 

 

 

 

By: tec_ak1 - tec_ak

RE: last line of isStretchWithOverflow not sh

2005-04-29 02:15

not useless but unused attribute ;-)

 

 

 

 

By: Ethan Kayes - ebkayes

RE: last line of isStretchWithOverflow not shown

2005-05-09 09:38

We have the same issue in our reports on Sun Unix. All is fine if we use Courier. If we pick Helvetica, Arial, Times we have problems.

 

Does anyone understand the root cause of this problem? This is quickly becoming a show stopper for us.

 

Regards,

 

Ethan

 

 

 

 

By: Ethan Kayes - ebkayes

RE: last line of isStretchWithOverflow not shown

2005-05-12 08:08

Hi,

 

We the cause and solution for this problem.

 

1. On our Sun boxes. Not all fonts requried for JR are loaded or the user does not have access to the directory or rights to the files.

 

Solution. We created a font directory for JR on with all of the fonts we support at present. The chmod for these files is set to 777. We repointed JR to user this new font dirctory. This solution has passed our unit testing and is now in a QA process.

 

Regards,

 

Ethan

 

 

 

 

By: Teodor Danciu - teodord

RE: last line of isStretchWithOverflow not sh

2005-02-04 22:42

 

Hi,

 

Can you provide me with a report template in which

the text content is hardcoded?

 

teodord@users.sourceforge.net

 

Thank you,

Teodor

 

 

 

 

 

By: C-Box - c-box

RE: last line of isStretchWithOverflow not sh

2005-05-12 12:57

Seems to be the same problem here like I posted today: https://sourceforge.net/forum/forum.php?thread_id=1282938&forum_id=113530

 

there I posted the files in design and output and also the text that causes the error.

 

hoping for your help

C-Box

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-04-27 04:54

At last, I've found the source of the problem - it relates to fonts. If I use the following in the report template:

 

<reportFont name="Normal" isDefault="true" fontName="Arial" size="9" pdfFontName="Helvetica" pdfEncoding="Cp1252" isPdfEmbedded="true"/>

 

then the last stretched line is not visible, but if I use Courier:

 

<reportFont name="Normal" isDefault="true" fontName="Courier" size="9" pdfFontName="Courier"/>

 

then it works.

 

Verdana fails in the same way as Arial, but the logical font Sans-serif appears to work, so I will try to follow that line and see if any problems arise.

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-05-27 06:17

I apologise that I was mistaken, Sans-serif does not resolve this stretchy field problem in my circumstances. I was fooled because some client/server scenarios do work.

 

If I fill the report on a (Mac) server and display using Jasper Viewer on a different platform (WinXP PC for example), the stretchiness fails, chopping off the last row of text.

 

Courier, Helvetica and Arial all suffer the problem.

 

I have found one set up where a particular Mac server filling in Arial will stretch ok on the client. However, I have no idea why this Mac can fill ok in Arial when others can't.

 

Does the 0.6.7 release of Jasper do anything that might help?

 

I'm guessing that I am seeing these problems because of filling and displaying on separate boxes and that most people are not running distributed applications?

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-05-27 09:11

Jasper version 0.6.7 doesn't help with this problem. I will focus on the fact that I have one server that can fill using Arial resulting in successful display on the client (though not Helvetica or Courier which I find odd).

 

The pdf version of the poorly displayed reports always seems to look fine. Can anyone explain the implications of this? I think at least I can discount itext/pdf font settings from the problem.

 

So I'm looking at how Java picks up font info, specifically on Mac OS X.

 

 

 

 

By: John Pollard - johnnypoll

RE: last line of isStretchWithOverflow not shown

2005-05-31 11:54

I have a solution, this time I hope it stays fixed.

 

First I printed out what fonts were available to my app using:

 

Font[] fonts = GraphicsEnvironment.getLocalGraphicsEnvironment().getAllFonts();

for(int i=0; i<fonts.length; i++)

{

System.out.println("Font family: " + fonts.getFamily() + ", name: " + fonts.getName());

}

 

This showed me that the Macs I am running on had different sets of fonts.

 

I then read on the net somewhere that Geneva is the Mac equivalent of Arial and is always available on Macs. I used Geneva and my stetchy fields always show correctly on PC and Mac clients.

 

John