Jump to content
We've recently updated our Privacy Statement, available here ×

Teodor Danciu

Members
  • Posts

    5,346
  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Profiles

Forum

Events

Featured Visualizations

Knowledge Base

Documentation (PDF Downloads)

Blog

Documentation (Test Area)

Documentation

Dr. Jaspersoft Webinar Series

Downloads

Posts posted by Teodor Danciu

  1. Hi,

     

    Can you tell which subreport is supposed to be there the missing area? You sent several subreport templates which are linked from the master in a dynamic way. Can you tell which one is supposed to appear there and it is not appearing?

     

    Furthermore, is there any particular reason for which you used a table component but just to put a subreport in it? Using table components as subreport containers does not make much sense. Keeping templates as simple as possible make easier to debug scenarios like this.

     

    Thanks,

    Teodor

     

  2. Hi,

    I suggest you put all subreport elements everywhere on your JRXMLs to stretchType="NoStretch".

    The subreports always stretch, because that is their nature. You don't need to control this behavior with their stretchType attribute. I would edit JRXML using a text editor and simply remove the stretchType attribute from all subreport elements.

    Then try again and see if it works any better.

    I hope this helps.
    Teodor

     

  3. Hi,

    Can we see your JRXML report template? I suspect it is about a layout inconsistency that coupled with the specifics of the data you are having in the larger file causes JR to enter an infinite loop trying to create new pages just because some content never seems to fit a new page.

    In any case, this is not related to how you fill the reports, to files, streams or whatever.

    Thanks,
    Teodor

  4. Hi,

    This is still not supported, or at least it is not part of the functionality we deliver by default.

    But I think you should attempt to do it on your own by implementing a generic element handler.

    You could look at our generic element handlers that allow us to embed Flash into PDF. You could create a similar one that embeds PDF into PDF. If succesful, you could actually contribute back to the project.

    Thanks,
    Teodor

     

  5. Hi,

    First of all, the library used to render chart is not different depending on the export type, ex PDF. Regardless of what document format you target, we use the same charting package to render the chart.

    In JR, you can integrate any charting or visualisation package you want, but in order to do that, it means you are going to call that graphic rendering API directly from your report. With our built-in charts, you just configure a chart element and you normally you are not concerned about the JFreeChart API, unless you want some customizations.

    If you want to achieve the same simplicity of use, but rely on a different charting library behind the scenes, you would need to implement a JR custom component for it. Just like at Jaspersoft we did with the FusionCharts package, which is available as a JR component in the comercial version of JR Pro.

    But if you download the JR project source tree, you can find several samples that show you how to use different charting packages:

    /demo/samples/openflashchart

    /demo/samples/jcharts

     

    I hope this helps.
    Teodor

     

  6. Hi,

    Yes, it's true that in JR project we do not have actual unit tests. We always thought about duing them but there was never enough time to make it a priority.

    So indeed we rely on those numerous samples we have in our distro to spot problems when they appear.

    What exactly do you want to test for the JSON data source? Do you have troubles using it?

    Thanks,

    Teodor

     

  7. Hi,

     

    You should make it easier for people to help you by attaching some relevant files to your post, such as the JRXML and maybe even the PDF. Note that in JR, changing the Page Orientation does not change the page size of your report design. The page orientation is just a hint used by some printers, to know the need to change the direction of printing.

    You need to change page width with page height and make your report design landscape, as seen in the /demo/samples/landscape sample shipped with the JR library source package.

    http://jasperreports.sourceforge.net/sample.reference/landscape/index.html#landscape

    I hope this helps.
    Teodor

     

  8. Hi,

     

    It would be easier to understand your problem if you would upload some screenshots or drawings to explain.

    However, if I understood correctly, you want text fields from the right of the page to move towards the left, depending on the length of some string in between.

    This kind of movement is not possible in JR. Elements keep their declared width and their width cannot be dynamic. Instead, depending on the lenght of their content, text fields can grow in height. We call this stretching, to accomodate longer text that wraps on multiple lines. But I guess this is not what you need.

    A possible workaround for you would be to simply concatenate the several text involved in a single text field, using + in the text field expression.

     

    I hope this helps.
    Teodor

     

  9. Hi,

     

    The problem comes from the fact that the iReport compatibility mode does not work for components such as the table component.

    Basically, using iReport 4.6.0, you are not able to save the table component in a JRXML format that would correspond to JR 4.5.0.

    The UUID attribute in JRXML is a new attribute added to table component and when saving from iR 4.6.0 there is no way to suppress it. Unless you remove it manually using Notepad or some text editor.

     

    You are creating and modifying JRXML using the latest iReport, but you are deploying in an application that uses older JR.

    The best solution would be to upgrade your application to use latest JR as well. If this is not possible for some reason, you should at least stop compiling JRXML files at runtime in your application.

    In the code you sent, we can see you are using the JasperCompileManager to compile a JRXML file that is basically static. This is not needed:

    http://jasperforge.org/uploads/publish/jasperreportswebsite/trunk/faq.html#FAQ22

    From iReport, you  should save your reports in *.jasper format. This way you might workaround this UUID problem in the first place, as the JRXML would no longer be parsed by your application.

    I hope this helps.
    Teodor

     

     


  10. JasperReports Library 4.7.0 Change Log
    ===================================

    - improved rendering performance for the table component;

    - enhanced interactive report viewer APIs;

    - new "net.sf.jasperreports.export.pdf.size.page.to.content" export configuration property added
    to allow for variable page size in PDF documents, by adapting page size to page content size;

    - better control over memory footprint in large XLSX exports, by allowing the temporary files buffer size
    to be configured locally through report custom properties;

    - minor bug fixes and improvements;
     

  11.  
    JasperReports Library 4.6.0 Change Log
    ==========================================
     
    - improved JasperReports configuration infrastructure by the introduction of a JasperReportsContext, 
    an new interface from where JR configuration properties are read and JR extensions are loaded.
    This allows different configurations of the JR engine to exist simultaneously in the same JVM;
     
    - improved JasperReports Web Framework which now features a centralized controller to dispatch
    actions triggered by end user interactions in the report viewer. Actions are backed by atomized 
    commands that modify the report metadata on-the-fly, with support for undo/redo operations, 
    to reflect changes in the report output;
     
    - introduction of reusable Web report viewer APIs, featuring configurable report viewing servlets,
    and built-in Javascript modules that can be used to create custom interactive report viewers in Web
    applications embedding the JasperReports Library.
    This is demonstrated in the new /demo/samples/webapp-repo sample where two different looking versions
    of the same build-in JR interactive report viewer are used to displays interactive reports;
     
    - enhanced interactivity in the table component, with support for column formatting, hiding, resizing,
    moving, sorting and filtering, all leveraging the new action-based JR Web Framework controller and its 
    interactivity supporting report viewer Javascript APIs;
     
    - introduction of a data caching API that helps avoid re-querying the report's data source, 
    for performance reasons, while interactively viewing the report using an interactive report viewer
    created based on the new JR Web Framework;
     
    - added new page related events in the asynchronous report filler to support asynchronous page display
    in interactive report viewers;
     
    - added support for message providers that can be plugged into JR as extensions, to allow 
    internationalization of interactive custom components UIs;
     
    - minor bug fixes and improvements;
     

  12. Hi,

     

    Our documentation needs to be updated.

    We are going to make it more clear to our users that we are going to keep compatibility with JRE 1.6.

    Note that 1.5 has reached End Of Life years ago. If you still need to use it, then you'll need to use old JR as well, or adapt newer versions to 1.5. on your own.

    "Java SE 5.0 is in its Java Technology End of Life (EOL) transition period. The EOL transition period began April 8th, 2007 and will complete October 8th, 2009, when Java SE 5.0 will have reached its End of Service Life (EOSL)."

     

    Thank you,

    Teodor

     

  13. What you missed is something I missed too and only became apparent when testing the thing myself.

     

    The extensions JAR present in iReport is not packaged as a true JR extension because it does not contain a jasperreports_extension.properties file in its root package.

    So although it brings to the classpath the required classes, it does not register them with JR.

     

    The solution was to register the xpath2 language with a line in the jasperreports.properties file that sits in the root package of your application classpath. If you don't have one, you should create it and add this line to it:

    net.sf.jasperreports.query.executer.factory.xpath2=com.jaspersoft.jrx.query.JRXPathQueryExecuterFactory

     

    This was also explained on the tracker.

    Sorry for not testing the extension JAR before indicating it, but I'm not an expert in iReport.

     

    You also mentioned some documentation spelling errors that made you waste time. If you could point them to us, we would be happy to fix them.

    After all, that's all open source is about.

     

    Thanks,
    Teodor

     

  14. What we can see here is a unit test that you have in your code, called com.curema.test.xml.creation.TestCreatePDFwithdatasource, in which you call the JasperCompilerManager to compile a report.

    JR Library raises an unchecked exception in the form of a JRRuntimeException, when no query executer is registered with the specified query language in the report. The condition is serios and prevents JR from continuing because it is similar to missing a JAR in the classpath or something.

    In JR, we raise an exception. JR is open source. Can you point us to the place in the JR source code where we spit exceptions on the stack trace?

    Since when raising unchecked exception is considered bad practice and what exactly are these standards you have set for yourself that we do not meet? We'd like to learn.

    If you run your unit tests from Eclipse, where else would you want exceptions to be logged if not in the Eclipse console view? In your project that contains these unit tests, do you use any of the available logging libraries? If you do, why don't you configure them so their output be sent where you expect it to be sent?

    Thanks,
    Teodor

     

  15. Hi,

     

    Please take a moment and read about JR Extension support in the JasperReports Ultimate Guide which is available for free here:

    http://jasperreports.sourceforge.net/JasperReports-Ultimate-Guide-3.pdf

    and is also shipped with the source code package in latest JR releases.

     

    Query executers can be added very easy simply by adding a JAR to classpath. The fact that your reports have a query language called xpath2 seems to indicate they were created with iReport, which is an optional query executer for Web Services that is registered to this xpath2 custom defined query language.

    If you indeed used iReport, than the only thing you should have done is to take the JAR containing this custom query executer from iReport and add it to the classpath of your application, without making any further configurations. The JAR is called jasperreports-extensions.jar.

     

    The documentation you cited is for those who want to implement custom query executers on their own. But if you are just using the one that comes from iReport, or any other custom query executer provider, you just need to take the JAR from them and that's all.

    If the xpath2 query executer is not from iReport, then those who provided it to you should have given you a JAR containing that custom query executer and you should have added it to your application classpath.

    You had all these exceptions because your reports made use of a pluggable custom query executer that you did not add to your application classpath. It's as easy as that.

     

    Your decision to compile JRXML reports at runtime comes with the drawback of your reports running a bit slower, just because they are compiled at runtime, without any particular reason. But if you want them to run slower, it is up to you.

     

    I hope this helps.
    Teodor

     

  16.  
    JasperReports 4.5.1 Change Log
    ===================================
     
    - the JSON data source and the respective JSON query executer were moved  
    from the samples folder to the core library;
     
    - support for macros added in XLS and XSLX exporters;
     
    - the repository APIs were enhanced with support for pluggable persistence  
    services to load and store resources in the repository;
     
    - the "net.sf.jasperreports.export.pdf.force.linebreak.policy" configuration  
    property is un-deprecated, as a partial revert of the changes made in 4.1.1 with  
    regards to PDF text rendering; These changes were partially reverted as they affected  
    the performance of the PDF exporter when dealing with simple texts. The AWT-based text  
    rendering is now performed only on complex text fields that contain tab characters  
    for tab stop alignment or contain multiple paragraphs, with variable paragraph styling.
     
    - minor bug fixes and improvements;



    Post Edited by teodord at 03/05/2012 12:02
  17. Hi,

     

    Such infinite loops are caused by an inconsistency in the report design itself. The problem is that we cannot detect those situations are report designt time, as they are dependent on the actual data being fed to the report (such as a long text causing a page break with repeating group headers that would cause the page break again and again and again...)

    The theory says that you cannot write a program that detects it entered an infinite loop itself:

    http://en.wikipedia.org/wiki/Halting_problem

     

    We could help investigate further if you send your JRXMLs over.

     

    I hope this helps.
    Teodor

     

×
×
  • Create New...