teodord
-
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 teodord
-
-
Hi,
If you have a JRXML with a big Base64 image in it that used to work in 6.12.2 and no longer works in 6.20.6, please share it with us.
Thank you,
Teodor
-
Hi,
JasperReports release 7 is months away. Not sure if it will be out before the end of this year. Work is in progress because it is not only about Jakarta migration, but also separation of various optional extensions to optimise and restructure our dependencies system.
You can try the latest 7.0.0-SNAPSHOT artifacts from our public Maven repo at:
I hope this helps.
Teodor -
Hi,
Are you migrating your application to Jakarta? I am asking because JasperReports already works with Java 17, so you don't need to wait for version 7.
Thank you,
Teodor
-
1
-
-
Hi,
Achieving this behaviour means customising the way word break policy occurs in Java/AWT.
It is not trivial and this can only be done in the context of a request for enhancement, as it is not considered a bug.
It would have been easier if word wrap would have been disabled altogether, but what we are talking about here is custom word break policy.
It is not even clear how such custom word break policy would be configured. Would it be about establishing a list of characters that should or should not cause word breaks?
Definetly not trivial.
Thank you,
Teodor
-
You did not clarify it for me. So let me ask it differently:
If there is a space character somewhere, would you want the word after it to be moved onto next row or should it be cut in the middle?
For example, if there is a space between the BBBs and the CCCs, should it look like this:
AAAAAAA%BBBBBB CCCCCCC
CCCCC
Or should it look like this:
AAAAAAA%BBBBBB
CCCCCCCCCCCC
So I understand that special characters cause unwanted breaks for you, but should we prevent all word breaks, including the classical white spaces and tabs? No word wrap anymore, just break anywhere element width dictates?
-
Hi,
What we see here is standard Java word break/wrap policy and not the result of something we implemented ourselves.
It is not clear what exactly you are looking. Are you looking for changing the list of characters that can trigger word breaks, or would you rather have any word cut in the middle if it does not fit? Are you looking to change the way words break/wrap, or are you looking for disabling word break/wrap altogether and simply cut text wherever the text element width occurs?
Thank you,
Teodor
-
Hi,
The JSS CE 6.20.6 version released recently is shipped with Java 17.
Thank you,
Teodor
-
1
-
-
Hi,
pom.xml files can have a parent. and our has one.
I hope this helps.
Teodor
-
The JRCsvExporter has a setter that accepts SimpleCsvReportConfiguration. And this class has a setExporterFilter(ExporterFilter) method.
-
Hi,
The only solution I see involves post-processing of JasperPrint objects/documents using the JasperReports library API, prior to their final export to PDF or the targeted export format.
This means writing custom code.
For example, the two subreports could be run normally, one after the other, but once the JasperPrint document obtained, the Java API could be used to reorder the pages inside it and maybe even change the page number in the page footers, if needed.
I hope this helps.
Teodor
-
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,
This was a regression introduced in 6.19.0 that has been solved since 6.20.1.
https://community.jaspersoft.com/jasperreports-library/issues/14466I hope this helps.
Teodor
-
If you want to use the JasperReports functionality from a non-Java application by making REST calls, I suggest to give a try to the JasperReports IO product:
https://community.jaspersoft.com/project/jasperreports-io -
Hi, Marcilio
I think what you mean is "elements that stretch should not print again when their band overflows".
Because, contrary to what you said, elements that stretch, most of the time do overflow.
The problem here is that it not necessarily the object that stretches, which is marked as isPrintWhenDetailOverflows=true.
In Fabio's example, it is indeed the case, but that's because he prepare for us the most basic of examples, with minim number of elements involved.
But I can very well remove the reprinting flag from the list element and put it on some other element that does not itself stretch, the effect being the same.
I hope you see that the complexity of the behaviour is hard to predict and validate upfront.
Thank you,
Teodor
-
Hi, Fábio,
From the description of the problem, it appears you already understand what the cause is. Indeed, setting isPrintWhenDetailOverflows=true is the cause of the problem, coupled with the fact that the detail band overflows with white space. At the bottom of you detail band, under the frame with the list component, you have 26 pixels of white space.
So now let's think about it: do you really want your frame with the list to be rendered again in case the detail overflow onto a next page? What do you want the engine to do with the 26 pixels at the bottom of the detail? Didn't you put them because you wanted them to be kept? Or do you expect the engine to ignore them? If you want the engine to ignore them, why did you put them in the first place? The engine does not ignore the 26 pixels of white space and it just happens that the page break occurs when this white space "needs to be rendered". This is why I say "it overflows with white space".
If you put JasperReport aside for a moment and try to run the report in your head, considering the way it is expected to work as explained above, dont you enter an infinite loop in your head trying to create a new page for the remaining white space while having to render the list again, which would cause a new page break due to the white space of the bottom and then on that page you need to render the list again which would cause the page break again and again and again and again?...You might also ask: why isn't the engine able to understand it has entered an infinite loop? Well, this is some sort of generic theoretical question of software programming that I encourage you to try find an answer for, but I hope it is not about using a counter or something. Are we in an infinite loop if 1000 pages have been created?
Or maybe you ask: why isn't the engine able to tell me my report is incorrect or inconsistent when I design it? It can't because as you see the situation depends on the runtime data. It just happens that because of the number of records in the list and maybe the values themselves, the page break occurs in the worst possible place, so this cannot be known at report design time.
And now to come back to the initial questions: is this something you really need? The list to render again when detail overflows? Do you really need that white space in the same detail band as the list, or can you preserve that white space by using a second empty detail band of height=26?
I am trying to give you report design options, because this infinite loop problem is not going to be solved any time soon. In the past we've done our best to detect infinite loop situations, but some cases are simply not solvable.
I hope this helps.
Teodor
-
Hi,
The HTML component has never been part of the core JasperReports library jar and was always a separate jar, which can be built using Maven from the /demo/samples/htmlcomponent folder of the JRL project distribution package:
https://github.com/TIBCOSoftware/jasperreports/tree/master/jasperreports/demo/samples/htmlcomponent
When you say that the new version excludes the HTML component, you are probably referring to Jaspersoft Studio or some other product that used to ship this experimental component. But you are not saying exactly where do you see it being removed.
You also do not say which Maven repository is not working. You use a lot of exclamation marks and upper case text, but do not provide information that would help us help you.
Thank you,
Teodor
-
-
Hi,
JasperReports Library executes SQL queries only for the purpose of retrieving data source records and iterate through them.
In your case, you want to execute an SQL query just to fetch an image, which probably requires some custom code.
But one way to leverage JRL ability to fetch images from the database is to use a master report just for the background.
The master report would have the query to fetch the image as a dataset field and put it in the background section.
The actual report content is included in this master as a subreport.
This approach would solve the page margins issue you raised on a separate thread.
I hope this helps.
Teodor -
Hi,
I don't know what you are talking about. JasperReports is a Java library. You probably talk about some other product.
Thank you,
Teodor
-
Hi,
One way to achieve this is to use a master report without page margins, just for the background and include the actual report into it as a subreport.
The subreport could be placed in the title or summary section of the master report that has whenNoDataType="AllSectionsNoDetail", while it passes all the parameter values to the subreport using something like:
<parametersMapExpression><![CDATA[new HashMap($P{REPORT_PARAMETERS_MAP})]]></parametersMapExpression>
I hope this helps.
Teodor -
Hi,
This has been fixed and will be part of the next release.
Thank you,
Teodor
-
Hi,
Not sure what are the reasons for your limitation, but Digester 3 is only 1 year younger than Digester 2, both having their latest releases more than a decade ago. The reason we did not move to Digester 3 is because despite being an almost complete rewrite of Digester 2, as their authors say, it only had 3 releases in a short period of 6 months back in 2011. With an older history and more releases, it appears to us that Digester 2 is more stable and since there was never a CVE reported against it, we never had any reasons to upgrade.
I hope this helps.
Teodor
-
Hi,
Conditional styles support has been added to the master branch and will be part of the next release.
It relies on a limitation which says that in a JRTX conditionExpression you can only use simple/single $P, $F and $V references, because these external report expression are not actually going to be compiled.
So you can basically only point to boolean parameters, fields or variables in the external conditional styles expressions.I hope this helps.
Teodor -
As long as the JRXML is working with JasperReports Library, JasperReports IO, Jaspersoft Studio, iReport or JasperReports Server, you should not worry about it.
The fact that IntelliJ does not understand the XSD definitions, it is not a concern for us.
Maybe you want to check that with IntelliJ.
Large Image Handling - Troubles Base64
in Products
Posted
Hi,
There seems to be no variable called "streamBackground" in the "a" JRXML. Maybe I'm missing something...
When the "b" and "c" reports fails on your side, what is the error you have in logs for each of them?
Can you provide the stack traces of these errors?
Thank you,
Teodor