View Issue Details

IDProjectCategoryView StatusLast Update
0000630FakturamaDokumente (Documents)public2018-02-17 19:58
Reportervanguard Assigned Torheydenr  
PrioritylowSeveritytweakReproducibilityalways
Status closedResolutionfixed 
PlatformPCOSLinuxOS VersionDebian (32bit)
Product Version2.0.0 
Target VersionPipelineFixed in Version2.0.0.1 
Summary0000630: Keine Adressen und Footer-Zeilen in Dokument
Description

Liebe Entwickler,

sowohl in version 2.0,0 als auch in Version 2.0.0.1 werden die durch Libreoffice erzeugten Dokumente
für das Drucken nicht korrekt angezeigt.

In der Vorschau fehlen die Adresse und Adressat, als auch die Footer-Daten (Kontonummer etc.)

Lediglich das Firmenlogo, die Leistungsbeschreibungen und der Begrüßungstext werden angezeigt.

Seltsamerwesie startet auch nicht Libreoffice, (wie vorher) sondern das bereits fertig umgewandelte
PDF-Dokument im vom Anwender gewählten PDF-Betrachter (hier Okular).

Somit kann man mit der neuen Version nicht korrekt arbeiten.

Ich bin daher zur Version 1.9.6b zurückgeschwenkt, dort funktioniert alles einwandfrei.

Ausserdem habe ich mehrfach die alten Daten zu von 1.6.9 zu 2.0.0 konvertiert - ohne Erfolg.

Was kann ich sonst noch tun? Sieht mir aus wie ein heftiger Bug.

Vielen Dank für das Lesen dieses Bugreport.

Hans-J. Ullrich

Mein System: Debian/testing, 32-bit, libreoffice 2.5.4, java9.

TagsNo tags attached.

Activities

rheydenr

2018-02-01 22:58

administrator   ~0000684

Fakturama 2 funktioniert nur mit Java 8. Bitte damit nochmal prüfen. Das fertig gedruckte (ausgefüllte) Dokument wird angezeigt, wenn man den Haken setzt bei "Dokument im separaten Thread drucken" (die Bezeichnung ändere ich hier noch). In diesem Einstellungsdialog kann man auch angeben, welche Art von Dokumenten erstellt werden.

vanguard

2018-02-02 09:02

reporter   ~0000685

Hallo Herr Heydenreich,

ich habe mich noch einmal an den Fehler angenähert. Meine erste Aussage war nicht ganz korrekt, in der Tat hatte ich auch im ersten Bugreport Java 8 verwendet, allerding oracle-java-8. Den zweiten Test nun habe ich mit openjdk-8 durchgeführt, welches das default Javapaket in debian ist. Angeblich sollen beide Javas identisch identisch sein, aber sind sie nicht wirklich. Man merkt z.B. Unterschiede in der Darstellung bei anderen Java basierten Programmen (z.B. tvbrowser).

Jedenfalls habe ich aufgrund Ihres Hinweises beide Haken gesetzt in "Office in eigenem Thread anzeigen" und "PDF nach Druck anzeigen".

Jetzt bekomme ich zwei Vorschauen. Einmal das ODT, welches falsch ist, und einmal das PDF, welches korrekt alle Daten enthält.

Zum ersten Fall ist zu sagen, daß das ODT nicht wie (vermutlich) vorgeschrieben mit Libreoffice angezeigt wird, sondern mit dem vom Desktop voreingestelten PDF-Betrachter (in meinem Fall ist es "Okular"). Ich glaube, daß hier der Fehler liegt. Scheinbar ist eine Verknüpfung falsch.

Im Desktop selbst werden Dateien mit der Endung *.ODT korrekt mit Libreoffice geöffnet, so daß ich von einem Fehler in Fakturama ausgehe.

Im finalen Test habe ich beide Einstellungen mit oracle-java-8 und mit openjdk-8 durchgeführt, bei beiden das gleiche Ergebnis: Die Darstellungen sind identisch, Aufruf von ODT mit Okular.

Ich hoffe, daß meine Ausführungen helfen. Es wäre schön, wenn (wie bei Version 1.9.6) weiterhin die Vorschau über Libreoffice angezeigt werden würde, nicht nur das fertige PDF.

Damit hat man den Vorteil, daß man von dort aus auch in andere Formate (z.B. DOC oder was auch immer) exportieren kann. Das wäre ohne Kosten ein zusätzliches mächtiges Feature.

Vielen Dank für die Mühen.

Hans-J. Ullrich

rheydenr

2018-02-02 09:47

administrator   ~0000686

Ich gebe zu, daß ich es mir beim Öffnen der Dokumente etwas einfach gemacht habe. Dafür wird nämlich einfach der im System registrierte Dateihandler verwendet, d.h. Fakturama sagt dem System, daß es bspw. eine ODT-Datei öffnen soll und überläßt es diesem, wie es das anstellt. Unter Windows funktioniert das über die Registry, unter Linux wird das möglicherweise über Standard-Mimetypes geregelt. Das müßte ich nochmal in Erfahrung bringen. Unter MacOS funktioniert es wohl auch recht gut.

Besteht jetzt eigentlich inhaltlich noch Bedarf für eine Änderung bezüglich des Ausfüllens der Templates? Oder lag das tatsächlich nur am eingesetzten JDK?

vanguard

2018-02-02 10:09

reporter   ~0000687

Das ist von der Denkweise für mich schon ok. Der Dateihandler ist aber so eingestellt, daß daß
bei Dateien mit der Endung ODT Libreoffice gestartet wird, bei PDF Okular.

Ich glaube, daß Ihre Übergabe ODT falsch übergibt, denn das System glaubt, es ist eine PDF-Datei, obwohl es eine ODT-Datei ist. Hier ist auf jeden Fall ein Bug.

PDF-Dateien werden korrekt behandelt (so wie es konfiguriert ist, mit Okular zu öffnen).

Das Problem ist ODT, hier ist, um Ihre Frage zu beantworten, auf jeden Fall noch Bedarf. Denn
es ist ein reproduzierbarer Bug.

vanguard

2018-02-02 10:10

reporter   ~0000688

Unabhängig davon kann der Status von "blocker" aber reduziert werden.

vanguard

2018-02-03 21:49

reporter   ~0000691

Hallo Herr Heydenreich,

ich habe nochmal versucht, die Verknüpfung zu der ODT-Datei mit Libreoffice zu verändern.
Dank Ihres Hinweises bezüglich des MIME-Typs habe ich festgestellt, daß KDE scheinbar bei ODT-Dateien (MIME-Typ ODT) dieses mit Okular betrachten will.

Dateien, mit der Endung .ODT werden im Gegensatz dazu mit Libreoffice geöffnet.

Aktuell bin ich noch auf der Suche, wie ich das ändern kann.

Persönlich fand ich die Darstellung von Rechnungen mithilfe von Libreoffice (wie es bei der Version 1.9.6 war) irgendwie schicker. Vielleicht könnte man das wieder rückimplementieren? Wär cool.

Die neue Funktion, Rechnungen etc. gleich in PDF umzuwandeln und zu zeigen, finde ich persönlich super. Das ist eine prima Funktion!

Meiner persönlichen Meinung nach könnte dieser Thread geschlossen werden, da ich mit dem erzeugten PDF gut zurecht komme.

Es wäre aber trotzdem schön, wenn Sie diesen Bugreport trotzdem ein wenig im Hinterkopf behalten würden, sozusagen vielleicht als Wishlist.

Auf jeden Fall, vielen Dank für die Tips und Hilfe, das hat mir schon weiter geholfen.

Mit besten Grüßen

Hans-J. Ullrich

rheydenr

2018-02-03 22:00

administrator   ~0000692

Cool. Die Bearbeitung in LibreOffice ist ja nach wie vor möglich, wenn die Datei richtig geöffnet wird. Ich habe aber die Kopplung zu Fakturama aufgehoben, da es da ständig zu Problemen kam. Jetzt wird die Vorlage unabhängig vom LibreOffice ausgefüllt und erst die fertige Datei wird angezeigt. Diese kann dann natürlich auch weiter geändert werden.

vanguard

2018-02-17 12:11

reporter   ~0000712

Sehr geehrter Herr Heydenreich,

dank Ihres Hinweises, daß das Dokument aufgrund der Konfiguration des verwendeten Desktops dargestrellt wird, habe ich nochmal den Fehler analysiert.

Grundsätzlich wird auf meinem KDE-Desktop eine .ODT mit LibrerofficeWriter geöffnet.

Fakturama2 öffnet aber eine ODT-Rechnung mit Okular (PDF-Betrachter). Dieses ist bei KDE als ZWEITES in der Liste für ODT aufgeführt.

Nachdem ich Okular vollständig aus der Liste entfernt habe, wird die Rechnung nun korrekt mit Libreoffice bei ODT und Okular bei PDF geöffnet.

Damit ist das Problem gelöst und der Thread kann geschlossen werden.

Für Sie dürfe sich möglicherweise die Frage stellen, warum Fakturama2 nicht den ersten Eintrag des Desktop genommen hat, sondern erst den zweiten. Ich vermute hier ein Timingproblem. Möglicherweise hat Libreoffice zu träge reagiert und dann wurde das nächste in der Liste gewählt (hier Oular). Okular stellt natürlich eine ODT Datei nicht korrekt dar.

So wie es jetzt läuft, läuft es korrekt, allerdings (ebenso wie erforderlich) immer noch mit Java8.

Mittlerweile ist natürlich auch unter Linux Java 9 angekommen, ich meine sogar, Java 10 ist im Anflug.

Wie auch immer, ich bedanke mich ganz herzlich für die schnellen Hinweise und das schnelle Feedback.

Viele Grüße

Hans-J. Ullrich

rheydenr

2018-02-17 19:58

administrator   ~0000713

ok, besten Dank für die Rückmeldung. Leider weiß ich nicht konkret, wie die Auflösung auf Betriebssystemebene funktioniert, das muß ich mir erst nochmal aneignen.
Java 9 ist auf jeden Fall ein Thema, dafür gibt es auch ein Ticket. Allerdings ist das nicht ganz trivial umzusetzen.

Issue History

Date Modified Username Field Change
2018-02-01 12:55 vanguard New Issue
2018-02-01 22:58 rheydenr Assigned To => rheydenr
2018-02-01 22:58 rheydenr Status new => feedback
2018-02-01 22:58 rheydenr Note Added: 0000684
2018-02-02 09:02 vanguard Note Added: 0000685
2018-02-02 09:02 vanguard Status feedback => assigned
2018-02-02 09:47 rheydenr Note Added: 0000686
2018-02-02 10:09 vanguard Note Added: 0000687
2018-02-02 10:10 vanguard Note Added: 0000688
2018-02-03 21:49 vanguard Note Added: 0000691
2018-02-03 22:00 rheydenr Note Added: 0000692
2018-02-03 22:00 rheydenr Priority high => low
2018-02-03 22:00 rheydenr Severity block => tweak
2018-02-05 23:16 rheydenr Target Version => Pipeline
2018-02-17 12:11 vanguard Note Added: 0000712
2018-02-17 19:58 rheydenr Status assigned => closed
2018-02-17 19:58 rheydenr Resolution open => fixed
2018-02-17 19:58 rheydenr Fixed in Version => 2.0.0.1
2018-02-17 19:58 rheydenr Note Added: 0000713