Jump to content
Changes to the Jaspersoft community edition download ×

mg72

Members
  • Posts

    15
  • Joined

  • Last visited

mg72's Achievements

Apprentice

Apprentice (3/14)

  • Week One Done
  • One Month Later
  • One Year In
  • First Post Rare
  • Collaborator Rare

Recent Badges

0

Reputation

  1. Hello, For a long time we have been having problems with printing carry over values. A valid carry over value is essential to many of our customers. As I can see, there are some posts in the forum from 2008 and some bug reports that are still open. To remind you that this problem still occurs, I will attach a sample layout with an xml data source that shows the carry over problem on page 2 of the pdf document. This sample is very simple. In customer installations we have layouts that are much more complicated (more bands with subreports and so on). For printing the carry over value we calculate all necessary values (the current value, the next value and the previous value). The main problem is to decide which value we have to print in the page footer, because at render time we have no information on whether a field is printed on the current page or is moved to the next page in case of an overflow. We were thinking of "minHeightToStartNewPage", but this does not fix the problem in all cases. Another thought was to prevent bands from splitting (set "split allowed" to "false"). But this would end up in printing each position to a single page with much white space at the bottom of the page. So this is not a solution. Having a flag that marks a field as a "carry over field" might be a solution to this problem. The renderer should set this flag if the field is printed on the current page. In this case we may ask the field, that is responsible for our carry over, if it is printed on the current page and are thus able to print the valid value. What do you think? What other possibilities do we have to print a correct carry over value? Does it make sense to open a new feature request/bug report? Regards Marcus
  2. Hello, the value of the Page-Alignment in report-properties is wrong (german user language). I'm not able to test the english user interface because english is not available in my language settings (bug?). So maybe its a wrong translation or a bug in the sequence of the alignment box. If you open the landscape example from jasperreports the layout is correct (and saving the layout creates a correct jasper-layout) but the value of the alignment is portrait!!! Changing from portrait to landscape changes the value of the height and width of the page so that you will get a portrait layout (but the alignment value ist landscape!). Regards Marcus
  3. Hello, iReport 1.3.0 does not save the new break-element in the layout file. You may draw it in the layout but after reloading the layout the break-element is gone!! Regards Marcus
  4. Hi, do not use iReport to create the break-element because iReport-designer does not save the element into the layout-file. Youe may insert the break under the band-tag, e.g.: Code: <band> ..... <break type="Page"> <reportElement x="0" y="17" width="784" height="1" key="element-1"/> </break> </band> Marcus
  5. I've found a solution for the problem! You have to create the BaseFont another way: OLD: com.lowagie.text.pdf.BaseFont bf = com.lowagie.text.FontFactory.getFont( file.getPath() + file.separator + files).getBaseFont(); NEW: com.lowagie.text.pdf.BaseFont bf = com.lowagie.text.pdf.BaseFont.createFont(file.getPath() + file.separator + files + "," + a, com.lowagie.text.pdf.BaseFont.IDENTITY_H, com.lowagie.text.pdf.BaseFont.EMBEDDED); I guess the problem is the encoding of the ttc-file. While reading the ttc with parameter IDENTITY_H opens the font correctly. Hope that helps Marcus
  6. Hello, I've fixed the problem. I rebuild the iReport.exe file on my own by changing the file etc/ireport.jsmooth. I added all the missing <classPath> tags (changed the values to current iReport version). These tags have been removed since 1.2.4! As I said I'm not familar with the jsmoothgen so I've no idea why these tags have been removed ... Now my iReport.exe file for release 1.2.5 works fine again! Greetings Marcus
  7. Hi, with iReport release 1.2.5 I've got problems starting the designer out of an application with the exe file. I've got this error message: Jasper Virtual Machine Launcher Could not find the main class. Program will exit. Release 1.2.4 works fine! Starting the designer from batchfile is ok also. The problem is that I could not use the batchfile because the windows cmd does not support starting applications from an unc path. What has changed to the exe file in 1.2.5? I'm not experienced with "jsmoothgen" so I could not figure out what has changed. Thanks and Regards Marcus
  8. Hi Giulio, the font is still ok (tested with other applications like apache fop). iText might be a problem. I've tried to fix the problem also but had no idea left :( Using a new version of iText (1.4.2) does not help. Please correct the FontListLoader so that the iReport designer does not hang up if loading a ttc font: com.lowagie.text.pdf.BaseFont bf = com.lowagie.text.FontFactory.getFont( file.getPath() + file.separator + files).getBaseFont(); if (bf != null) { java.awt.Font f = fontMapper.pdfToAwt(bf, 10); Thanks Marcus
  9. Hi, I have the same problem. Setting the environment variable doesn't help. It seems that it.businesslogic.ireport.gui.MainFrame.getMainInstance().IREPORT_HOME_DIR in ReportClassLoader does not work properly if you start the iReport designer from shellscript or batchfile. Regards Marcus
  10. Hello, I've got problem starting iReport-Designer if there are TTC-Fonts (e.g. simsun.ttc) in the fonts directory. The splash-screen hangs (loading fonts) and I've got this exception: Exception in thread "main" java.lang.NullPointerException at com.lowagie.text.pdf.DefaultFontMapper.pdfToAwt(DefaultFontMapper.java:185) at it.businesslogic.ireport.FontListLoader.loadTTFFonts(FontListLoader.java:112) at it.businesslogic.ireport.gui.MainFrame.<init>(MainFrame.java:378) at it.businesslogic.ireport.gui.MainFrame.main(MainFrame.java:7110) Any ideas to fix the problem? Regards Marcus
  11. Hello, I'd like to know how the status of this topic is. I've tried to print out tab characters but got only single spaces. I've found this announcement from Teodor but nothing else: 2003-03-25 13:33 Hi, Unfortunately, the engine does not handle tab characters properly for the moment. I'll try to overcome this in the future. I suggest you use a fixed size font and replace the tabs with spaces to see how it works. Thank you, Teodor Thanks a lot, Regards Marcus Post edited by: mg72, at: 2006/07/20 08:27
×
×
  • Create New...