-
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
Security Advisories
Downloads
Posts posted by Teodor Danciu
-
-
Hi,
The SF.net based Maven repository you mentioned is now somewhat deprecated and no longer updated.
We instead use this newer repository for JRLib dependencies:
http://jaspersoft.jfrog.io/jaspersoft/third-party-ce-artifacts/
I hope this helps.
Teodor -
Hi,
You are probably aware that after version 2.1.7, iText has changed its open source license and can no longer be used in commercial applications.
We cannot use newer iText version with our open source project because the new iText license would not allow it to be used everywhere JR Lib can be used.
Most likely you need a commercial license from iText, and in that case, you would also need to create a PDF exporter for JR Lib, based on that new version of iText.
I hope this helps.
Teodor
-
Hi,
I think we first need to agree on the terminology.
My understanding is that here we are talking about hidding "crosstab row group headers cells".
These cells are the ones that constitute the columns that appear on the left, and contain the row group header information, helping to identify different row groups.
The easiest way to solve this is by enhancing our crosstab definition model to accept a printWhenExpression for row group header cell definitions.
If my understanding is correct and you still need this, please log a RFE on the trackers.
Thanks,
Teodor -
Hi,
We are not aware of any issue with running JasperReports Library on Java 8. Not sure about iReport, which is an EOL product for many years now.
With JR Lib, at some point we needed to upgrade the JDT compiler to support Java 8, but after doing so, there were no other issues we know about.
Thanks,
Teodor
-
Hi, Hitoshi
I have unintentionally transformed your absolutely valid answer into your question. I'm sorry about that, as there is no way to revert it now.
Can you please share with us the solution you mentioned about the overlapping elements? How exactly did you solve it on your side?
Thanks,
Teodor -
Hi,
This was solved in 6.2.1, soon to be released.
The missing package was added to the OSGI exported packages in the manifest file of the JR Lin JAR.
Thanks,
Teodor
-
Hi,
We do have these artifacts in a Jaspersoft public repository at:
I hope this helps.
Teodor -
Hi,
Can you explain what is the reason for forking JR Library at GitHub?
Have you made there fixes that we denied including in the main distro? Can you provide us with the list of fixes or improvements?
JR Lib is already hosted on Git, but at Sourceforge.net.
https://sourceforge.net/p/jasperreports/code/ci/master/tree/
So what exactly is the reason to go for GitHub instead of SF.net?
Thanks,
Teodor -
Hi,
In the upcoming JR 6.2.1 release, there will be a new export configuration property called net.sf.jasperreports.export.html.embed.image, which can be set globally, at report level or per element, to force the exporter to Base64 encode the image into the src attribute of the img tag.
I hope this helps.
Teodor -
Hi,
What version of JR Lib are you using?
Thanks,
Teodor
-
Hi,
I'm afraid this is expected behavior and we are not going to change it soon.
You see, the removal of empty or non-printable elements is the last operation performed during container layout.
Which means that by the time we calculate how much space each element has to expand, the white space is not yet reclaimed.I understand your sample report is just a hypothetical case, to show us the issue, but these situations can be worked around usually by putting collapsible content in separate bands.
Note that certain report sections such as detail and group headers and footers are multi-band sections, which give you more flexibility on restructuring large sections into separate bands, that collapse independent of one another.I hope this helps.
Teodor -
Hi,
The solution in such cases is to split large band in smaller bands.
The region of a large band that is supposed to print conditionally and collapse when not printing, should be isolated in a separate band.
The main report sections such as the detail, the group headers and footers, are multi-band sections, making this easy.
But the summary section is not a multi-band section. However, splitting the summary in multiple bands is fairly easy as the summary can be simulated with a dummy group footer of a group that breaks only once per report. Such a group can be one with constant expression, including a group that does not have expression at all. Its footer section appears at the end of the report, just as the summary and can be made of multiple smaller bands that have printWhenExpression at band level.
I hope this helps.
Teodor
-
Hi,
Not sure if a bug tracker was created as a result of this message thread, but there is one probably describing the same problem, which has now been fixed for upcoming JR Library release:
http://community.jaspersoft.com/jasperreports-library/issues/3725
Thanks,
Teodor -
Hi,
There was indeed a special exception thanks to an agreement between Jaspersoft at the time and iText.
But with Tibco taking over of Jaspersoft, we were not able to guarantee that the agreement could be continued in its present form, so to avoid any legal problems we have returned to iText licensed under MPL 1.1.
If an agreement is reached again between Tibco and iText, we'll make sure our community benefits from it right away. Until then, we are back to iText 2.1.7 distributed under Mozilla Public License 1.1.
Thanks,
Teodor
-
Hi,
There was indeed a special exception thanks to an agreement between Jaspersoft at the time and iText.
But with Tibco taking over of Jaspersoft, we were not able to guarantee that the agreement could be continued in its present form, so to avoid any legal problems we have returned to iText licensed under MPL 1.1.
If an agreement is reached again between Tibco and iText, we'll make sure our community benefits from it right away. Until then, we are back to iText 2.1.7 distributed under Mozilla Public License 1.1.
Thanks,
Teodor -
Hi,
Can you attach the JRXML that produces the output seen in the screenshot?
You attached some Barcode4J specific XML syntax, but there is not much we can do with that in JR.
Thanks,
Teodor
-
Hi,
Note that the built-in SQL query executer of JR Library, is only able to execute queries that return a ResultSet through JDBC call.
This is usually the case with SELECT statements.
If the sequence of SQL statements you have cannot be executed through the executeQuery() of the PreparedStatement interface of JDBC, then it would not work with JR's built-in SQL query executer and you would either have to wrap them in a stored procedure call, or implement your own query executer for JR.
http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html#executeQuery%28%29
I hope this helps.
Teodor -
Hi,
I don't fully understand what you mean when you say "but all the records are not getting printed. the parts of records are getting printed."
I would have to see a screenshot or a scan of what you get onto the printer, to compare it with the PDF version, which you say looks OK.
Thanks,
Teodor -
Hi,
Please upgrade to JR 6.0.3 released yesterday. We had to make a second release this week due to a regression bug in the ODS exporter of 6.0.2.
Thank you,
Teodor
-
Notice the header in the license file here:
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,
I think here we have two columns that need to collapse independent of one another.
The only solution that I can see right now is to isolate the content of those two columns that run side by side in two separate subreports.
This is because only subreports allow you to have content bigger than the subreport element height itself.
We are working on a modification of layout code to allow frame elements to be smaller than their declared content height.
The frame would stretch to display all its content, even if the initial frame height declared at design time is smaller.
It would allow you to isolate the two columns in two separate frames, side by side, instead of having to use subreports.
Thanks,
Teodor
-
Hi,
This has been solved in JR 6.0.0 release with the introduction of report templates made of parts instead of bands.
Please check the /demo/samples/book and /demo/samples/tableofcontents samples shipped with the JR distro.
Thanks,
Teodor
-
Hi,
Can you send us your JRXML file?
Thanks,
Teodor
Prevent page break between elements
in Products
Posted
Hi,
Starting with version 6.4.3, groups have a new boolean attribute called preventOrphan.
In addition to this, groups also have a new property called minDetailsToStartFromTop, which would help make sure groups do not start too low on the page and at least a specified number of detail records fit into the remaining space.
I hope this helps.
Teodor