Umgebung: LO 6.4 und LO 7.03 auf Linux Mint.
Aktion: in LO-Draw exportiere beliebige Zeichnung als PNG mit gewünschter Auflösung, z.B. 300 dpi
Ergebnis: keine getestete Setzung hat einen Einfluss auf die faktische Auflösung des Bildes
(Test via identify etc.).
Sieht so aus, dass LO-Draw seit 6.4 PNGs nur noch mit einer Auflösung exportiert …
Wenn ja: m.E. ein Bug … oder übersehe ich irgendwas?
Möglicherweise - mit aller Vorsicht - Bug tdf#136707 - Draw export to png: incorrect density and size (der ist aber immer noch im UNCONFIRMED status).
Ah, ja, könnte sein. Passt schon. Habe nur nach resolution und nicht nach density gesucht grummel
Ach ja: Danke! 
LO scheint eine maximale Größe für *.png-Dateien zu haben. Ich habe das gerade für den im ersten Kommentar genannten Bug getestet. Bei 4096 Pixel in die Breite und 4096 Pixel in die Höhe machte die Anlage zu Bug 136707 Schluss. Die Vorlage war 100cm * 100cm. Verkleinere ich die Vorlage auf 20cm * 20cm und versuche mit 300dpi abzuspeichern, so macht mir Draw daraus ein Bild der Größe 2366px * 2366px. Das entspricht den 300dpi. Es dürfte also kein Problem sein, *.png-Dateien zu erstellen, die eine A4-Seite komplett mit einem Bild der Auflösung 300dpi bedecken können.
Das ist übrigens in allen hier getesteten Versionen von LO gleich - seit Version LO 6.1.5.2 unter OpenSUSE 15.1 64bit rpm Linux.
Sowas wollt’ ich auch schon ewig lang wissen, Danke für die Ausführungen! - Ciao
Das ist nicht das Problem: zumindest unter Linux Mint werden ab LO 6.4 die Angaben zur Auflösung (=density = resolution) scheinbar ignoriert. Egal, was ich angebe, LO erzeugt nur 72 dpi … wie identify
sagt.
Die Größe der Datei ist dabei gleichgültig: es geht mit keiner Größe…
Arbeitest Du da mit den Paketen von LibreOffice direkt oder sind das Pakete Deiner Distribution?
Die Pakete habe ich von LO direkt gezogen … aber ich habe nun endlich das Problem besser verstanden.
LO rechnet schon korrekt, skaliert eben per Default so, dass die Gesamtmenge der Pixel konstant bleibt. Damit kann mensch m.E. umgehen, z.B. durch Erhöhung der Abmessungen etc…
Das Problem ist nun, dass Tools (die von Verlagen etc. und mir eingesetzt werden) eine falsche
dpi ausgeben, z.B. identify -format “%x,%y\n” -units PixelsPerInch . Egal, welche dpi ich in LO angebe, stets wirft identity 72 heraus. Das hat sich definitiv von LO 6.1 zu 6.4/7.0 geändert. Wird der png-Header nun anders geschrieben?
Sorry für die Umstände …
Du hast recht, da ist ein Unterschied drin. Ich weiß auch nicht, was da anders geschrieben wird, aber wenn ich eine *.png-Datei aus LO 7 in GIMP öffne, so steht da immer 72 dpi. Erstelle ich eine entsprechende Datei mit 6.1.5.2 (ich habe hier alle möglichen Testumgebungen), dann steht da eine Auflösung von Pixel/mm, die dann übertragen in dpi korrekt die Vorgabe aus dem Export ergibt: 11,831 Pixel/mm ergibt dann 300dpi. Beide exportierten Dateien sind gleich groß und haben die gleiche Pixelanzahl. Mal schauen, ob es dafür auch schon einen Bug gibt.
OK, imagemagicks identify zeigt es.
LO 6.4/7.0:
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 1183x704+0+0
Units: Undefined
Type: TrueColorAlpha
…
LO 6.1:
Format: PNG (Portable Network Graphics)
Mime type: image/png
Class: DirectClass
Geometry: 1183x704+0+0
Resolution: 118.3x118.32
Print size: 10x5.94997
Units: PixelsPerCentimeter
Type: TrueColorAlpha
…
Jetzt wundert mich nicht mehr, dass gimp, identify nur den Default von 72 zeigen. Dem PNG-Standard
kann ich aber auf die Schnelle nicht entnehmen, welche Form korrekt ist.
Tippen wir einmal auf die Form, die die Größe mitteilt. Starte ich nämlich Inkscape und lasse das Bild nach der enthaltenen Auflösung einlesen, dann macht er mir einmal ein Quadrat von 6cm Kantenlänge und bei LO 6.4 und 7.0 dann ein Quadrat von über 20 cm Kantenlänge.
Vielleicht kannst Du ja Deine Beobachtungen an den Bug 132959 mit anhängen.