2013-11-21 12 views
5

Ich habe ein Problem mit meinem Jaspis - Bericht, wo eines meiner Textfelder (das letzte in einem Detailband) in der PDF - und PDF - Vorschau abgeschnitten wird, aber nicht in der Interne Vorschaujasper Textfeld wird abgeschnitten

z.B.

Interne Vorschau:

Here is a fake description. It fits 
perfectly, fitting just in the lines. 

PDF Vorschau

Here is a fake description. It 
fits perfectly, fitting just in the 

Jasper ist (scheinbar) einige Algorithmus, um herauszufinden, wie groß das Gebiet sein sollte, ist mein Text kaum passend, dann, wenn die PDF wird generiert, der Text wird umbrochen und verschwindet in der nächsten Zeile.

Ich verwende keine benutzerdefinierten Schriftarten (nur die Standard/implizite "SansSerif"), und keine benutzerdefinierten Stile jenseits Fett/Kursiv. Dieses Verhalten ist sowohl in der PDF-Vorschau von iReport als auch in der von meinem Code generierten PDF unter Windows und MacOS nachweisbar (Linux hat wahrscheinlich immer noch das Problem, aber mein Beispieltext zeigte das Verhalten unter Ubuntu nicht).

Ich habe mit Streckentyp, Positionstyp und Stretch mit Überlauf gespielt, und dieses Textfeld in ein eigenes Band verschoben, aber keine behebt diesen Fehler (und einige von ihnen verursachen andere).

Ich hatte Glück, die Schriftart zu den anderen integrierten Schriftarten zu ändern, aber das sagt mir nur, dass mein Beispiel nicht für diese bestimmte Schriftart funktioniert, nicht, dass ich den Fehler behoben habe.

Alle Tipps würden sehr geschätzt werden.

aktualisieren 1

ich ein Upgrade von Jasper versuchte Berichte 5.2.0 zu 6.2.0 und Jasper Fonts 4.0.0 bis 6.0.0 ... keine Veränderung.

aktualisieren 2

meine src/main/resources/jasperreports_extension.properties und das Hinzufügen von

net.sf.jasperreports.export.pdf.force.linebreak.policy=true 

Bearbeitung Versuchte ... keine Änderung.

(vor allem wenn in meinem Anwendungsfall kann ich nicht isStretchWithOverflow="true" verwenden, so kann dies sein, warum es nicht funktioniert.)

Update 3

Ich habe versucht, die Schrift durch Bearbeitung Einbetten src/main/resources/jasperreports_extension.xml und fügte hinzu:

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> 

... keine Würfel. (Dies half jedoch bei einem Problem, bei dem der PDF-Renderer von Firefox keine fett gedruckten Schriftarten darstellen würde.

)

Update 4

stellte ich fest, daß die Testfälle in alle ich in der Lage war, zu schaffen, dass die erste Linie war leer, so änderte ich die bestimmte Zelle vertical-align oben werden, die arbeitete, aber natürlich machte diese eine Zelle falsch, wenn es nicht viel Text darin gab.

Verschrottet, dass als Lösung, kann aber für jemanden arbeiten.

Update 5

An dieser Stelle hoffentlich ist es klar, ich habe die „echte“ Lösungen ausprobiert und beobachtete, wie sie alle einen schrecklichen Tod sterben. So betreten wir den Bereich der Hack-Lösung. Zuerst versuchte ich @ wmmcis Lösung, aber seine Antwort ändert die Höhe meiner Box (aufgrund der dynamischen Berechnung durch Dynamic Jasper). Ich habe bemerkt, dass alle Beispiele, die ich erstellen konnte, Zwischenwortzeiträume in der Zeichenfolge involvierten, z. "foo ... bar". Das ist vielleicht nicht dein Fall, aber es war für mich. Also injizierte ich einen "Haarraum" (&#8202;) nach Leerzeichen.

Dies ist offensichtlich keine echte Lösung, nur eine vorübergehende Umgehung, bis ich in der Lage bin, weitere Beispiele für den Fehler zu finden.

Update 6

Ich habe und ich habe nicht @ KarolisŠarapnickis die Ausgabe mit dem printOrder. Ah, gut. Ich werde weitermachen. ;-)

+0

Haben Sie gefunden, eine Lösung für dieses Problem? Ich habe das gleiche Problem und es ist so nervig ... es scheint wie Jaspis kann nicht die maximale Anzahl der Zeichen berechnen, wenn es ein Eingabedaten in Fett und dann schneidet es den Rest beim Export in PDF – Jesus

+0

Für zukünftige Referenz, Benutzer Mit diesem Problem sollte überprüft werden, dass [font-Erweiterungen] (https://stackoverflow.com/documentation/jasper-reports/5773/font-extensions#t=201705312048127084075) korrekt verwendet werden –

Antwort

7

Ich hatte das gleiche Problem und ich habe alle möglichen Konfigurationen ausprobiert - hat nicht funktioniert. Als Workaround habe ich ein neues Zeilenzeichen an das Feld angehängt und es funktionierte. So etwas wie: $ F {description} + "\ n"

+0

das ist ein netter Trick. funktionierte für mich :) –

+0

_Any_ erweiterbare Textarea wird dieses Problem haben, so dass Sie den Wagenrücklauf _everything_ hinzufügen müssen. Darüber hinaus wird es auch die Feldhöhe beeinflussen. Immer noch ... Es ist eine brauchbare Lösung für die Verzweifelten (die ich wohl auch bin). – inanutshellus

+0

Arbeitete auch für mich. In unserem Fall wird der Jasperprint auf einem Linux-Server generiert und auf einem Windows-Client angezeigt. Meine Vermutung ist, dass es Linux-Fonts einer etwas kleineren Größe verwendet, um den erforderlichen Speicherplatz zu berechnen, und wenn es dann unter Windows angezeigt wird, passt die Windows-Schriftart nicht. – tobi42

0

Hatte die gleichen Probleme mit Text abgeschnitten und nichts schien zu funktionieren. zum Glück fand ich, dass mein Root-XML-Element aus dem folgende Attribut hatte:

printOrder="Horizontal" 

Entfernen es meine Probleme gelöst.

+0

In meinem Fall habe ich immer noch dieses Problem, aber habe nicht 'printOrder =" Horizontal "' in meinem JRXML-Datei Stammknoten. Hoffentlich hilft das aber jemandem da draußen. – inanutshellus

0

In meinem Fall hatte ich wirklich langen Text in einem einzigen Textfeld. Das Hinzufügen eines Zeilenumbrüchens würde das Problem für einige Zellen lösen, aber nicht für die wirklich langen, die sich über Seiten erstrecken. Um es schließlich zu lösen, musste ich das Textfeld auf RELATIVE_TO_BAND_HEIGHT ausdehnen. Zuvor wurde es auf RELATIVE_TO_TALLEST_OBJECT festgelegt. Meine Vermutung ist, dass RELATIVE_TO_TALLEST_OBJECT falsch berechnet wurde (niedriger als nötig).

Dies hat den Trick:

textField.setStretchType(StretchTypeEnum.RELATIVE_TO_BAND_HEIGHT); 
+0

Ich habe es getan, aber es hat nicht funktioniert – Jesus