teodord

Hi,
This is indeed a regression after the modifications we made to improved bulleted/numbered lists support in the HTML markup processor.
It should now be fixed by this commit:
https://github.com/TIBCOSoftware/jasperreports/commit/b884e0355759d7dd5b4c1315485c81af57170e0b
Thank you,
Teodor

Hi,
No, this is not possible and we don't plan to support it.
The fact that styles can be isolated into external style templates offers enough flexibility to change them at runtime. It would be too much trouble to support such expressions in style properties.
Also, note that the style properties at element level can have dynamic values using these custom properties:
http://jasperreports.sourceforge.net/config.reference.html#net.sf.jasperreports.style.fontSize
I hope this helps.
Teodor

Hi,
JRL uses a forked version of iText 2.1.7 in which we implemented a custom feature to deal with fonts that have ligatures. We stayed with iText 2.1.7 under the terms of the MPL.
JRL built-in PDF exporter would not even work with newer iText, because they changed the package names when moving to iText 5+.
Thanks,
Teodor

Hi,
Jaspersoft products use and distribute iText 5.5 under LGPL, in accordance with a contract signer with iText Software.
The contract provides that the LGPL terms apply only for as long iText functionality is accessed only through Jaspersoft API calls and not directly.
So as long as you use iText through Jaspersoft functionality, meaning you are exporting reports to PDF, you are fine with the LGPL terms we are shipping iText 5.5 under.
I hope this helps.
Teodor

Hi,
 
Instead of using two text fields, one with evaluationTime=Now and the other with evaluationTime=Report, you could use only one text field with evaluationTime=Auto.
In order for this to work, you need to use in your expression two variables that have different resetType levels.
The build-in PAGE_NUMBER variable is good for the total number of pages. But for the current page number, you need a custom made variable, let's call it CRT_PAGE_NUMBER, which has calculation=Nothing and resetType=Page, which copies the value of the PAGE_NUMBER variable in its expression.
I hope this helps.
Teodor
 

Hi,
 
Are you talking about reports exported to PDF format? What is the file format you are producing?
Did you look at the /demo/samples/unicode sample shipped with the JR Library source package?
 
Thank you,
Teodor

Hi,
I'd say you could use a custom made SQL query executer that performs a callback and gives you the ResultSet object once it has obtained it. Such a custom query executer could be a subclass of our own JRJdbcQueryExecuter in which you overide the createDatasource() method to put the JRResultSetDataSource instance into the report parameters map for retrieval.
You need a custom query executer because scriptlets would not help in this case. By the time the first scriptlet event is called, the report would have already consumed the first record in your result set.
If once you have obtained the result set, you don't want the report to continue, you could have the query executer return an emtpy data source and the report would have nothing to iterate on and thus stop.
I see that we don't have a getResultSet() method in our JRResultSetDataSource, but we could add it if you log a RFE on trackers. In the meatime, you could add it yourself to get on with your coding.
I hope this helps.
Teodor

Hi,
JasperReports 5.0.4 released recently addresses this issue. Let me know if you tried it.
Thanks,
Teodor
 

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

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
 

Hi,
 
This has nothing to do with JasperReports.
It has to do with how you manage your objects on the sesssion.
The problem is in your application and you just need to debug it.
 
I hope this helps.
Teodor
 

Hi,
 
No, the markup attribute solves a different requirement.
It is about the ability to include HTML formatted text into a text field. Indeed, the HTML snippet put into a text field can have CSS information, and it should work.
 
But the mentioned class attribute would allow using CSS styles to apply inside a JRXML template as a whole and it still not possible today.
 
Note that JasperReports is not a HTML oriented tool.
CSS works probably in HTML alone, but JasperReports exports documents to PDF, RTF, XLS, ODT too. How would CSS work in those formats? Oh, maybe you are not interested in those formats.
OK, then the solution for you is to come up with a better HTML exporter that would not use in-line styling for the various content elements and instead rely on custom properties attached to the elements in the generated document that point to CSS classes introduced by the HTML_HEADER exporter parameter.
The only missing piece in this approach are the custom properties at element level. In JRXML, we allow attaching custom properties to individual elements, put they are not preserved in the generated document.
This came up as a request for enhancement in the past, so it is probably something we are going to do soon.
 
But I repeat, this is something that would be solved by implementing your custom HTML exporter. I will let you know when custom properties in generated documents are available so that you can make use of them and solve this problem.
 
Thank you,
Teodor

Hi,
 
This is usually the result of some font mismatch problem.
Make sure that the fontName and pdfFontName point to the same font file, with the same font metrics.
The most probably cause of font problems is that you designed your report on a machine where the fontName existed and was installed properly and then you deploy the report on a server machine that does not have those fonts and some other default font with different font metrics is used at report fill time.
 
I hope this helps,
Teodor