Teodor Danciu

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: https://jaspersoft.artifactoryonline.com/jaspersoft/webapp/#/artifacts/browse/tree/General/jr-ce-releases/net/sf/jasperreports I hope this helps. Teodor

Hi, Just wanted to let you know that starting with upcoming JR 6.2.2 later this year, there will be "native" support for SVG in image expressions and HTML/XML exporters. This means you no longer need to use the BatikRenderer to load the SVG data, but simply treat SVG files like image files and they will be exported to HTML as-is, since recent versions of popular browsers support SVG very well. Thank you, 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, I had to come back to this fix because the solution adopted at the time was not truly honoring the onErrorType attribute of the image, but merely ignoring the exception. The new fix will be available in the 6.2.2 release (the release after the next one, later in spring). Thanks, Teodor

Changed Resolution from Open to Fixed Changed Status from Acknowledged to Resolved 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, 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

Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi,This has been solved on Git master version and will be available in 6.2.2 release (the release after the next one 6.2.1, that will be made from 6.2.1.x branch).The solution was to change the way element stretch works while introducing new types of element stretch and deprecating existing ones.There will be 4 new types of element stretch:ElementGroupHeightElementGroupBottomContainerHeightContainerBottomRelativeToTallestObject will be deprecated and replaced by ElementGroupHeight.RelativeToBandHeight will be deprecated and replaced by ContainerHeight.If you want to try this out, please check the latest code from Git master branch.Thanks,Teodor

Changed Status from Assigned to Resolved Hi,This has been solved on Git master version and will be available in 6.2.2 release (the release after the next one 6.2.1, that will be made from 6.2.1.x branch).The solution was to change the way element stretch works while introducing new types of element stretch and deprecating existing ones.There will be 4 new types of element stretch:ElementGroupHeightElementGroupBottomContainerHeightContainerBottomRelativeToTallestObject will be deprecated and replaced by ElementGroupHeight.RelativeToBandHeight will be deprecated and replaced by ContainerHeight.If you want to try this out, please check the latest code from Git master branch.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

Changed Status from New to Feedback Requested Changed Assigned User from - to @teodord 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

Changed Status from New to Feedback Requested Hi,I'm afraid the archive of our old forge forums has been lost and in order to solve your issue, we need fresh information.Please attach relevant files that would help us reproduce the problem.Thanks,Teodor

Changed Resolution from Open to No Change Required Changed Status from Feedback Requested to Resolved

Changed Resolution from Open to Fixed Changed Status from Acknowledged to Resolved

Changed Resolution from Open to Works as Designed Changed Status from New to Resolved Hi,This works as designed.The collapse of empty space resulting from elements not rendering is the last operation that occurs when laying out content.By the time the white space is removed for the large text element appearing at the top, all space allocation for the other elements in the same container (band) has been done.The solution to avoid such problems is to separate the elements into different containers.In your example, you can use two detail bands, as the detail section of a report template is multiband.This way, the collapse of the missing first text field would occur before the second band is given the chance to occupy remaining space.By the way you arrange content into bands you control the way white space collapses and optimize layout.I hope this helps.Teodor

Changed Resolution from Open to Fixed Changed Status from New to Resolved Changed Assigned User from - to @teodord Hi,This is hopefully fixed as mentioned in:http://community.jaspersoft.com/jasperreports-library/issues/5586Thanks,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

Changed Status from New to Assigned

Changed Status from New to Feedback Requested Hi,Do you still need this? We were trying to keep design element creation as simple as possible and avoid having too many confusing constructors.Thanks,Teodor

Changed Resolution from Open to No Change Required Changed Status from New to Resolved Hi,Elements can be filtered out depending on type of export using export filters.In your particular case, the column headers can be filtered keeping only their first occurrence using these origin based exporter filters properties:http://community.jaspersoft.com/wiki/how-can-i-suppress-page-headers-and-footers-when-exporting-xlsAnother approach is to use Excel metadata exporter, which relies on markers at element level using custom properties to figure out the data columns that need to be exported, ignoring content layout completely:http://jasperreports.sourceforge.net/sample.reference/jasper/index.html#xlsmetadataexportI hope this helps.Teodor

Changed Resolution from Open to Fixed Changed Status from Assigned to Resolved Hi,The PDF 508C support was revisited in the latest JR 6.2.0 release and is now hopefully fixed.Thanks,Teodor

Changed Assigned User from - to @teodord Hi,What exactly are we trying to achieve with comments here?What is the use case?The above described scenarios can be solved with expressions such as the following:null;// This is a line comment!null/* This is a comment! */Expression tags in JRXML are supposed to introduce valid Java expressions.A Java comment is not a correct Java expression.But again, what is the purpose of this?Thanks,Teodor

Changed Resolution from Open to Unable to Reproduce Changed Status from Feedback Requested to Resolved