My Crystal report generates this text:
This is to certify that {FullName} has completed the course
where the formula {Fullname} is: Mr. + Name
I want to change {FullName} to remove the title "Mr". I used Find in Formulas on {FullName} and changed the Display String from Mr. + {?FullName} to {?FullName}. But somehow this replaced every lowercase "t" with "ti". So now the static string is changed to:
This is tio certify tihati .... has successfully completied tihe course
How can I correct this? A key note is that this only happens when exporting to PDF. In the Main Report Preview, the report displays correctly.
What you're describing is a really weird bug involving the Calibri font. Certain glyphs aren't handled correctly when exporting to PDF. The solutions I've found are as follows:
A) Avoid using Calibri fonts in Crystal Reports. You might try a more
common True Type font, such as Arial. Again, be sure that font is
installed on every... workstation.
or
B) Downgrade Crystal Reports to use a legacy Microsoft Uniscribe
component (USP10.dll). Here’s the procedure that we’ve used at
Alterity with good results.
Here are advanced instructions for Solution B, but I'd just recommend changing fonts. I'm sure you can find one very close to Calibri without this issue.
Related
I use HP Simplified font in my report. But when I'm trying to export it I get the message.
The selected program does not support the export of one of the functions, which uses
smiling in this report.
The report used partially compatible HP Simplified fonts; Use TrueType font instead of them.
What I need to do, to use this font?
I'm having a font issue with my jasper report where one of my more wordy text fields (the last one in a detail band) is getting cut off in the PDF and PDF Preview but not in the Internal Preview.
e.g.
Internal Preview:
Here is a fake description. It fits
perfectly, fitting just in the lines.
PDF Preview
Here is a fake description. It
fits perfectly, fitting just in the
Jasper is (seemingly) using some algorithm to figure out how tall the field should be, my text is barely fitting, then when the PDF is generated the text wraps and disappears on the next line.
I'm not using custom fonts (just the default/implicit "SansSerif"), and not using any custom styles beyond bold/italic. This behavior is demonstrable in both iReport's PDF Preview and my code's generated PDF on Windows and MacOS (Linux likely still has the issue, but my example text didn't exhibit the behavior on Ubuntu).
I've played with Stretch Type, Position Type, and Stretch with Overflow, as well as moved this text field to its own band but none fixes this bug (and several of them cause others).
I've had luck changing the font to the other built-in fonts, but this just tells me my example doesn't work for that particular font, not that I've fixed the bug.
Any tips would be greatly appreciated.
Update 1
I tried upgrading from Jasper Reports 5.2.0 to 6.2.0 and Jasper Fonts 4.0.0 to 6.0.0... no change.
Update 2
Tried editing my src/main/resources/jasperreports_extension.properties and adding
net.sf.jasperreports.export.pdf.force.linebreak.policy=true
... no change.
(Notably though in my use-case I can't use isStretchWithOverflow="true", so this may be why it didn't work.)
Update 3
I tried embedding the font by editing src/main/resources/jasperreports_extension.xml and adding:
net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasperreports.engine.fonts.SimpleFontExtensionsRegistryFactory
net.sf.jasperreports.extension.simple.font.families.arialFontFamily=fonts/customFontFamilies.xml
customFontFamilies.xml:
<?xml version="1.0" encoding="UTF-8"?>
<fontFamilies>
<fontFamily name="ArialEM">
<normal><![CDATA[fonts/Arial/Arial.ttf]]></normal>
<bold><![CDATA[fonts/Arial/Arial Bold.ttf]]></bold>
<italic><![CDATA[fonts/Arial/Arial Italic.ttf]]></italic>
<boldItalic><![CDATA[fonts/Arial/Arial Bold Italic.ttf]]>/boldItalic>
<pdfEncoding><![CDATA[Cp1252]]></pdfEncoding>
<pdfEmbedded><![CDATA[true]]></pdfEmbedded>
</fontFamily>
</fontFamilies>
... no dice. (Though this did help with an issue where Firefox's PDF renderer wouldn't render bold fonts.)
Update 4
I noticed that in all the test-cases I was able to create that the first line was blank, so I changed the particular cell to be vertical-align top, which worked, but of course made that one cell misalign when there wasn't much text in it.
Scrapped that as a solution, but may work for someone.
Update 5
At this point hopefully it's clear I've tried the "real" solutions and watched them all die a horrible death. Thus, we enter the realm of the hack solution. First I tried #wmmci's solution, but his answer changes the height of my box (due to it being dynamically calculated by Dynamic Jasper). I noticed that all of the examples I could create involved intra-word periods in the string, e.g. "foo...bar". That might not be your case, but it was for me. So I injected a "hair space" ( ) after intra-word spaces.
This is obviously not a real solution, just a temporary work-around until I'm able to find more examples of the bug.
Update 6
I checked and I don't have #KarolisŠarapnickis's issue with the printOrder. Ah well. I shall soldier on. ;-)
I had same issue and I tried all possible configurations - didn't work. Finally as a workaround I appended a new line character to the field and it worked.
Something like this: $F{description} + "\n"
Had the same issues with text being truncated and nothing seemed to work.
luckily I found out that my root xml element had the following attribute:
printOrder="Horizontal"
Removing it solved my issues.
Well, i'm not sure if you're struggeling with the exact same problem i was.
But my solution was setting the property "net.sf.jasperreports.print.keep.full.text" of the field to "true".
In my case, I had really long text in a single text field. Adding a line break would solve the issue for some cells, but not for the really long ones that spanned pages. To finally solve it, I had to set the text field to stretch to RELATIVE_TO_BAND_HEIGHT. Previously, it was set to RELATIVE_TO_TALLEST_OBJECT. My guess is that, RELATIVE_TO_TALLEST_OBJECT was being calculated incorrectly (lower than needed).
This did the trick:
textField.setStretchType( StretchTypeEnum.RELATIVE_TO_BAND_HEIGHT );
Seems like the only working solution is to put some text formating signs as #wmmcii said. Then another text renderer is used (discused here). However the new line \n is not ideal, because there is unwanted influence to the output doc. Better solution seems to put tab sign \t to the end of the line. To avoid additional problems when using Horizontal Alignment = Justified, put also a space prior to tab sign. For example:
$F{my_text} + " \t"
I'm trying to export a formula with fixed characters spacing into a text file.
What is happening is that its a long set of fields that is longer then the report page in crystal can show. When running the report it places the additional fields under and it repeats for all the records. When I try to export it to a text file it is pushing it the same way instead of that one record being one whole line across on the text file like I would like it to be. How can this be done. New to crystal thanks in advance.
Since you're exporting to plaintext, I'm assuming you don't care what the format of the actual report is (since it is merely an intermediate player during the export process). If that's the case, then you can just expand the page size horizontally until it can accommodate all of your fields the way you want them.
Your page size is probably 8.5"x11" by default. Go into your Page Setup ("File" -> "Page Setup") and make it the size that suits your fields.
EDIT: If you're using an older version of CR, you may have to use a dummy printer that can accommodate large paper sizes. See here.
The title of the question pretty much tells it all.
When using the java SDK provided by Crystal Reports to export a report as an Excel spread-sheet. Although the cells grow even now, only the first line is visible in the export XLS.
In the Crystal Reports UI, this is achieved by setting the 'Grow' option from the Report Export options.
What parameter must be set so that the corresponding cell visibly grows to accomodate large/multi-line text?
Given the hugely different nature of the 2 formats, exporting to Excel is always tricky. However, I did do a quick test exporting a dummy report from my CR standalone developer version, and replicated & solved your problem.
In your text fields that you want grown, go into the Format Editor->Common and turn on the Can Grow option. It looks like this activates Excel's Wrap Lines option, but unforunately also adds extra rows to make up for it.
My problem was that the field width was set to the width of the matter it contained. What worked eventually was to have the field-width in Crystal Report set to slightly smaller than the matter it is to contain.
Say, the matter to be written is 'Address Line One'.
Set the field in design view such that only 'Address' is visible.
Then set the field to 'Can Grow' with 0 (no-limit) on the number of lines to grow.
When the report is exported to XLS, the cell in XLS will be resized to display the rest of the body.
I'm trying to export a Crystal Report to a text file, while preserving any Unicode characters that are found within. By default, Crystal Reports seems to export to an ANSI text file.
Here is a highly simplified version of what I'm doing:
Dim objCRReport As CRAXDRT.Report
[...]
objCRReport.ExportOptions.FormatType = 8 'crEFTText
objCRReport.ExportOptions.DestinationType = 1 'crEDTDiskFile
objCRReport.ExportOptions.DiskFileName = "C:\reportInTextFormat.txt"
objCRReport.Export blnPromptUser
Since it creates a file in ANSI format, I lose any special characters that were found within the report. These characters are all fine when you view the Crystal Report directly.
Please note that I am referencing the "Crystal Reports 9 ActiveX Designer Runtime Library" specifically.
I want to point out that I've tried pre-creating a Unicode file with the same name prior to the export, hoping the Crystal code would notice the file, and append to it rather than creating an ANSI file, but unfortunately this is not the case.
I then thought I could get around this problem (ninja style) by just exporting to an RTF file (which preserves the characters), then reading the contents of this RTF (minus the formating). I would then create a Unicode text file myself, writing the RTF contents to it. Unfortunately, to achieve this, I had to look into using a RichTextBox, but encountered a slew of problems with that. I think I'd have more success in VB.Net, but unfortunately I'm stuck with VB6 for this task.
After trying those approaches, I found an article that seems to suggest that Crystal Reports 9 supports exporting to a Unicode Text file, but I have yet to see it work. It mentions that the print engine supports it, so I'm going to look deeper to see if I can invoke it, in case the .export isn't doing so itself (which I doubt).
It turns out Crystal relies heavily on the printer driver for Unicode support, so I decided to look into that. Turns out the printer driver had to support Unicode, and this was the case on my test environment. While this was interesting to find out, it didn't solve my problem - I already had a compatible printer driver.
So, finally: after a few days of trying to find a solution to this, my boss decided it was time to cut our losses, and we instead planned for a re-design of the feature, without involving Crystal Report to Text exports. I am still, however, very interested in how to export to a Unicode text file with Crystal - so please do answer if you know how.