Besonderheiten

Für PDF-Ausgabe werden durch den PDF-Standard 3 Schriftarten (Fonts) definiert, welche systemübergreifend und unabhängig von installierten Fonst funktionieren; Helvetia (Aril), Times, Courier.

Die Verwendung von Linked Fonts funktioniert auf LINUX- und Windows-Maschinen. Hierbei wird auf die im System installierten TTF-Fonts zurückgegriffen. Es muss aber darauf geachtet werden, dass ein Linked-Font auf dem Client-Computer installiert sein muss.

Embedded Fonts funktionieren aktuell noch nicht.

Die direkte Datumsausgabe in Berichten ist bei bestimmten Mono-Versionen aufgrund eines Fehlers in NET-ODBC (OdbcDataReader.cs) auf 64bit-Linux-Systemen nicht möglich. Der Fehler ist nicht im Report Manager-Runtime begründet und auch nicht im PostgreSQL-ODBC-Treiber.

Ein Datumsfeld im rückgelieferten Datensatz führt unter NET/ODBC-Umgebung zu einem Fehler, siehe ODBC unter Linux. Als Ausweg, kann das Datumsfeld mittels SQL-Abrage in ein Textfeld konvertiert werden. Weil dies seitens des SQL-Servers passiert, wird das Datum seitens ODBC als normaler Text behandelt und im Report ausgegeben.

to_char(org_person.BirthDay,'DD.MM.YYYY') AS BirthDay,

SQL-Befehle in RM-Reportvorlagen, die über ODBC gesendet werden, müssen Umlaute kodieren. Dazu wurd die Excape-Vorschrift des jeweiligen DB-Systems verwendet.

Ä

Ö

Ü

ä

ö

ü

ß: \u00DF

Kodierung erfolgt nach ISO 8859-1 (Latin1), siehe Zeichensätze und Kodierungen.

Lange Texte, die Zeilenumbrüche (\r\n) enthalten, werden von der orginalen NET-Engine (Reportman.Drawing) nicht korrekt umgebrochen und es verschwinden z.T. einzelne Zeichen. Das Problem liegt offenbar daran, dass \r\n (entspricht \0x0d \x0a bzw. CR LF) Zeilenumbrüche (Windows-Konvention) von Reportman.Drawing nicht korrekt verarbeitet werden, sondern nur \0x0a erwartet wird. SQL-seitig ließ sich \r\n > \n nicht ersetzen. Möglicherweise hängt das mit ODBC oder PostgreSQL zusammen.

Lösung für manuelle Umbrüche (Originalversion Reportman.Drawing)

Als Ausweglösung können in der SQL-Anweisung im Report die manuellen Zeilenumbrüche um ein Non-Break-Space (Unicode \xc2\xa0) gefolgt von vielen Spaces ersetzt werden. Diese Sequence "schiebt" umzubrechenden Text weit nach rechts und führt dadurch zu einem Zeilenumbruch.  

REPLACE(Text,'\r\n','\xc2\xa0                                         ') AS Text,

Die Anzahl der folgenden Spaces richtet sich nach der Breite des Ausgabefeldes. Die Ausgabebreite der Spaces sollte die Breite des Ausgabefeldes haben. Die Menge ist aber auf 92 begrenzt (ansonsten Fehlermeldung: Der Index war außerhalb des Arraybereichs.). Damit ist die Breite des Ausgabefeldes auch begrenzt (etwa 8cm bei Schriftgrad 10), in der diese Lösung sauber arbeitet.

Reportman.Drawing (1.0.3436.27313)

Lösung durch Patchen von Reportman.Drawing

Durch einen Patch der Reportman.Drawing werden \x0d Zeichen entfernt. Damit kann das Problem komplett gelöst werden.

• download von http://reportman.cvs.sourceforge.net/viewvc/reportman/reportmannet/ als tar.gz
• entpackt mit ubuntu804
• kopiert auf Windows
• Reportman.Drawing2.csproj: rpinifile.cs falsch verlinkt, wurde korrigiert
• kompiliert und in Distributionen ersetzt

Reportman.Reporting ließ sich kompilieren, meldet aber Fehler (String-Identifier nicht gefunden). Inkompatibilitäten mit Designer2_8 ??? Deshalb nur Reportman.Drawing ersetzen!

Dynamische Bilder werden bei der Reporterzeugung (zur Laufzeit) durch die Engine aus externen Bilddateien in den Report gerendert. Die Pfade der Bilddateien werden über Reportparameter, über die Datenbindung bzw. durch eine Kombination bereitgestellt.

Beim Report Manager können für dynamische Bilder leider nur bestimmte Bildformate verwendet werden:

• jpg, das Format ist insbesondere für Fotos geeignet. Bei Grafiken (Logos) können Qualitätseinbußen eintreten, welche man durch die Qualitätseinstellung der jpg-Datei klein halten kann.
• bmp, hier ist zu beachten, dass die Ausgabekompression bei der Reporterzeugung aktiviert ist. bmp-Dateien sind im Regelfall nicht komprimiert und dadurch sehr groß. Ebenso werden die PDF-Dateien sehr groß.

Einige Formate sind NICHT verwendbar. Bei dem Versuch diese Formate auszugeben, wird vom Acrobat Reader kein Bild sichtbar und eine Fehlermeldung angezeigt. Ob es hier Abhängigkeiten vom Server (Windows/Linux) oder von der Acrobat Reader Version gibt, ist noch nicht untersucht worden. Wir empfehlen, folgende Formate nicht zu verwenden:

• png
• gif

Beim bmp-Format gibt es weiterhin ein Problem, wenn PDF-Reports mit PdfSharp nachverarbeitet werden sollen, was wir in einigen Produkten auch tun (SMACC-PostProvider). PdfSharp gibt eine Fehlermeldung aus. Deswegen empfehlen wir, grundsätzlich das jpg-Format zu verwenden. Qualitätsverluste bei grafischen Darstellungen können durch die Komprimierungseinstellung von JPG eliminiert werden.

Bild in bestimmter Größe darstellen

Beeinflussung der Bildgröße und Bilddarstellung durch Änderung der Bild-Eigenschaften 

• Zeichenstil
• Auflösung(dpi)

Zeichenstil

Durch die Eigenschaft Auflösung(dpi) des Bildes in Pixel pro Zoll und die tatsächliche Pixel-Größe des Bildes wird die endgültige Größe des Bildes erzeugt, in Abhängigkeit von der Zeichenstil-Eigenschaft.

Beispiel: Will man ein 4,7 cm breites Bild und geht man davon aus, dass ein Bild in einer Pixel-Größe von 800 Pixel Breite vorliegt, dann muss man ca. 430 Auflösung (dpi) einstellen und die Zeichenstil auf Full setzen.

Rechnung: Auflösung(dpi) = 800 Pixel * 25,4 / 47mm = 432 dpi

Weicht das Bild von der Pixel-Größe 800px ab, erscheint es größer oder kleiner im Report. Wenn man eine definierte Größe im Report braucht, braucht man scheinbar auch eine definierte Pixel-Größe. Die muss durch die Applikation/Bildarchiv sichergestellt werden.

Bisher keine andere Lösung gefunden, um Bildgröße Report automatisch (ungeachtet der Pixel-Größe) einzuhalten

Problem mit Parameterübergabe PostgreSQL.

Parameter wird $1 gehalten. 

Wird der Parameter nicht als Variable sondern als Wert in die Abfrage zum Unterbericht eingegeben, dann funktioniert auch der Designer am PC. (Zum Testen)

• In der Engine bewirken Anführungszeichen der Art „Bachelor of Science“ einen Leerraum nach dem Absatz. Vermutlich wird Höhe falsch berechnet. Im Designer-Vorschau ist der Effekt nicht da.
• In Designer-Vorschau können lange Text nicht ausgegeben werden (etwa > 1000 Zeichen).
  "Der Index war außerhalb des Arraybereiches". In der Engine werden lange Texte ausgegeben, siehe oben.
• Debian Mono 2.6.7: In der Engine werden Umlaute an Position 255 (und eventuell weitere) eines Textelementes als ?? ausgegeben. Vermutlich kommt es zu einer Unterbrechung des UTF8-Streams an der ODBC-Schnittstelle oder in der Engine. Eine Lösung besteht darin, durch Umformulierung oder Leerzeichen diese Position zu vermeiden. Die Wahrscheinlichkeit ist sehr gering, aber dennoch ein unschöner Bug.
• Zentrierter Text in Feldern, die mehrzeilig sind, werden nicht korrekt dargestellt. Die Zeilen beginnen in der Mitte, nur die letzte Zeile wird korrekt zentriert angezeigt.

Zentrierter Text in Feldern, die mehrzeilig sind, werden nicht korrekt dargestellt. Die Zeilen beginnen in der Mitte, nur die letzte Zeile wird korrekt zentriert angezeigt.