mreis

hi, does jasperreports support letter-spacing [1] - we would need something similar to xsl:fo's letter-spacing attribute [2] ... kind regards & many thanks markus [1] http://en.wikipedia.org/wiki/Letter-spacing [2] http://www.w3.org/TR/xsl/#letter-spacing

I filed a bug for that - please vote for it -> http://jasperforge.org/plugins/mantis/view.php?id=5368

Under Extras -> Options -> iReport -> JasperReport Properties (tab) one can add, modify, and remove jasperreports properties or restore their "default" values. I thought that these entries were taken from ireport/modules/ext/jasperreports-<version>.jar, but when I modifed the default.jasperreports.properties directly in this jar, restarted iReport, and checked Extras -> Options -> iReport -> JasperReport Properties (tab) I couldn't find my changes. Could you please tell me where iReport takes these entries from and where/how changes are stored. We'd like to use the same default.jasperreports.properties in iReport as well as in our batch jobs ... kind regards & many thanks markus

Matt - after quite some research - I fully agree with you that we should avoid using the pdfFontName property for every <font> definition (using a different font for the fontName and pdfFontName property seems completely wrong). On the one hand pdfFontName is a deprecated property and should thus be avoided, on the other hand a fontName (with corresponding fonts in the jasper font extension jar) overrides the pdfFontName anyway. using a font extension jar should further eliminate all my cross-platform problems. one last negative aspect is that I couldn't eliminate the Helvetica font from the pdf - this topic can be found here: http://jasperforge.org/plugins/espforum/view.php?group_id=102&forumid=103&topicid=74379&topid=89864 I think I should file a bug for this ... regards, markus

I've searched the bug tracker for a corresponding bug, but couldn't find one. Is this already fixed in JasperReports and if yes from which version on (I use 3.7.4 and the bug still exists)?

Our reports contain text elements defining a font using <font fontName="Arial" size="12" isBold="false" isItalic="false" pdfFontName="Helvetica-Bold" isPdfEmbedded="false"/> We defined the pdfFontName attribute for every <font> tag (using either Helvetica or Helvetica-Bold as the value). Due to the fact that our JVM (IBM V9) doesn't define a mapping for Arial, I get the following warning: "Font 'Arial' is not available to the JVM." Nevertheless the pdf report is successfully rendered - the fonts that this pdf contains are Helvetica and Helvetica-Bold (as expected). Then I created a fonts-extension jar including some metadata and the arial*.ttf font files. Now JasperReports finds Arial and doesn't bring out the warning .So far everything works as expected. The resulting PDF however now contains the following fonts: ArialMT and Helvetica. My question is why (in the second case with the fonts-extension.jar) the resulting PDF doesn't contain Helvetica and Helvetica-Bold as its fonts (but instead ArialMT and Helvetica)? I'd like to find a way to eliminate the warning, and also get a PDF that contains Helvetica and Helvetica-Bold. kind regards & many thanks, markus

OK, so the problem was actually in jasperreports rather than in ireport -> http://jasperforge.org/scm/viewvc.php/tags/jr-3-5-3/jasperreports/src/net/sf/jasperreports/engine/xml/JRXmlConstants.java?root=jasperreports&view=log (rev. 2973) giulio, could you double-check with lucianc and then close this bug?

hmmm ... couldn't find any getAlignmentMap methods in 3.6.0 ... cdeal, could you please point us/me to the class(es)/method(s) where the problem was fixed? many thanks, Markus

Giulio - are there any relevant/related changes from 3.5.2 to 3.6.0 that may fix this problem or is this rather a "mere guess" (based on the experencies reported by lcourtin on 10/15/2009 12:46 in mantis item 3789)? We actually wanted to wait until the "Winter 2009" release of JasperReports (http://jasperforge.org/projects/jasperreports/tracker/roadmap) and the corresponding iReport release for our next upgrade, but probably we can use 3.6.0 in our test environment in parallel in the mean time ... cheeers, Markus

and it also happens with java 1.6.0_07 .... ... so I really begin to doubt that this is a general java bug/problem. probably it's somehow related to the netbeans infrastructure/environment ...

Hi, we're currently evaluating iReport 3.5.2 with the goal to migrate from iReport 2.0.5 to iReport 3.5.2. A lot of our problems (e.g. barcode integration, compile button, etc.) have already been solved from 3.5.1 to 3.5.2. Nevertheless there's still one major problem with the preview mode/tab. When we switch from Designer or XML to Preview the application becomes quite slow (i.e. doesn't respond quickly if you click on an UI item). I already tried to increase the initial and max heap size, but without any effect (the application only uses around 50 MB of memory). Is there any chance to improve this situation? Is this a known problem and will this be addressed in the next release? many thanks & kind regards, Markus

Hi, is there some kind of built-in "parameter" that represents an absolute (or relative) file path to the current jasper report that could be used in report expression (e.g. in order to reference sub-reports for on-the-fly compilation)? kind regards & many thanks, Markus

Hi, we'd like to use the JRPrintServiceExporter functionality in order to directly print a jasper report on a network printer. Following the corresponding sample code everything works out fine, except for some parts/texts with special fonts that are obviously not known to the printer (by default). When we produce a PDF from the report everything works fine and the PDF can be printed correctly. Is there a way to tell the JRPrintServiceExporter to somehow "embed"/use the fonts that are embedded in the PDF version of the report or is it possible to produce PDF and then print it (using javax.print or similar)? many thanks & kind regards, Markus Code:<staticText> <reportElement .../> <box> <topPen lineWidth="0.0" lineStyle="Solid" lineColor="#000000"/> <leftPen lineWidth="0.0" lineStyle="Solid" lineColor="#000000"/> <bottomPen lineWidth="0.0" lineColor="#000000"/> <rightPen lineWidth="0.0" lineStyle="Solid" lineColor="#000000"/> </box> <textElement textAlignment="Left" verticalAlignment="Top" rotation="None" lineSpacing="Single"> <font fontName="GI16-Medium" pdfFontName="GI16Med.ttf" size="30" isBold="false" isItalic="true" isUnderline="false" isPdfEmbedded ="true" pdfEncoding ="Cp1252" isStrikeThrough="false" /> </textElement> <text><![CDATA[bausparvertrag]]></text></staticText>

Hi, I already tried "solution one" which is really simple and pragmatic and works great - unfortunately it is limited to one image/logo per master report ... The second solution sounds very interesting, although there's the overhead costs in writing our own custom query executor. Still I think, that this may be a good solution and should help in other problem areas as well. Are there any other examples of custom query executors except from those already included in the jasperreports distribution? Anyway - many thanks ... I think I have now a clear picture how caching works with blobs fetched from db and further I'll now investigate how query executors work and which benefits we can get from writing our own. many thanks & kind regards, Markus

Hi, OK. The next question would then be - How can we use image blobs in our reports using the caching mechanism? Do we need to use subreports which only contain the image based on a query that returns exactly one result (e.g.: SELECT image_blob FROM my_image_blob_table WHERE image_blob_id=1)? Given the requirement that caching for image blobs must work, can those subreports only be embedded in header or footer or could they also be embedded in the detail section? Using image blobs from db is crucial for us, since we use the same reports in different environments on different servers and platforms, but all accessing the same database. If we'd use/embed images from the file system or via the classpath we'd have to duplicate the images which leads to a maintenance nightmare. kind regards & many thanks, Markus