Am 09.11.2017 um 16:53 schrieb Volker Lenhardt: > Am 09.11.2017 um 06:56 schrieb Wolfgang Jäth: >> Am 08.11.2017 um 18:48 schrieb Volker Lenhardt: >> >> Hättest Du lieber Angaben in Pixel oder Punkte o. ä. statt mm? >> > > Natürlich nicht, aber ich bin da irgendwie komisch. Wenn ich eine > Ganzzahl eingebe, so erwarte ich auch, dass dieselbe Ganzzahl > gespeichert wird.
0,35 cm /ist/ aber keine Ganzzahl; weder in Millimeter noch in Inch. >> Wenn du beim Obsthändler 1 kg Tomaten kaufst, bekommst du auch nicht >> immer [tm] exakt 1.000,000000000000 g. Und wenn du 350 solcher Käufe >> zusammenwirfst, erhältst du auch einen ganz schön satten >> 'Rundungsfehler'. ;-) >> > > Sicherlich. Daher geht es mir ja gar nicht wirklich um die Berechnung > der Gesamthöhe aller Zeilen (die kann ich - wie schon erwähnt - über die > Differenz der Y-Positionen exakt ermitteln), sondern darum, dass ich > nicht einen Double-Wert von 350.0 als Zeilenhöhe eingebe, sondern exakt > 350. Nein, du gibst "0,35 cm" ein. Das ist keine Ganzzahl. > Wenn intern, was ich natürlich verstehe, der Wert binär etwas > kleiner ist, so wird er doch als niedrigere Ganzzahl verwendet, denn > beim Auslesen des Werts wirkt nicht etwa die umgekehrte Logik. Doch, natürlich; da wird genauso (nur umgekehrt) gerundet, und dir wieder "0,35 cm" angezeigt. > Um in > deinem Beispiel zu bleiben: Wenn ich eine Tomate kaufe, und das zehnmal, > ärgere ich mich, wenn es nur 9 sind. Nein, es sind 10; aber es sind 10 Kleine, die nur das Gewicht von 9 Großen haben. > Ich habe das Ganze einmal durchgespielt. Die tatsächliche Zeilenhöhe > variiert im Bereich von 1 unter dem Eingabewert bis 1 darüber. > > Die Zeilenhöhe spielt für mich insofern eine Rolle, dass ich vermeiden > möchte, dass beim Ausdruck der Gesamtgrafik auf der letzten Seite nur > ganz wenige Zeilen stehen. Daher berechne ich Zeilenanzahl pro Seite und > erhöhe bzw. vermindere die Zeilenhöhe so, dass die letzte Seite nicht > ganz so verloren aussieht. (Die Zeilenanzahl, die Grafikdatei und > weitere Parameter werden über einen Dialog ermittelt.) > > Ich habe nun gelernt, dass ich nach dem Setzen der Zeilenhöhe die > tatsächliche Höhe auslesen muss. Die Differenz beim Vergleich mit der > Seitenhöhe ist dann so gering, dass man damit leben kann. Moment mal; im OP ging es dir darum ein Bild o. ä. exakt in x Zeilen ein zu passen. Was hat das mit der Seitenhöhe oder der Anzahl Zeilen pro Seite zu tun? > Ganz simpel: iRowsPerPage = lPageHeight \ lRealRowHeight > Und: iRowsOnLastPage = iRows Mod iRowsPerPage > Oder was wäre besser? Ich würde lPageHeight um einen minimalen Betrag (z. B. 0,00001 cm o. ä.) ab- und lRealRowHeight entsprechend aufrunden (oder einfach von der Division selbst vor dem Abrunden einen winzigen Betrag fix abziehen), um möglicherweise bereits hier vorhandene Rundungsfehler sozusagen auf die sichere Seite zu schieben. Andernfalls könnte es im Extremfall passieren (wenn nämlich die beiden Werte unglücklich zur falschen Seite gerundet werden, und das Ergebnis auch noch ganz knapp bei einer runden Zahl liegt), dass du als Ergebnis der Division statt z. B. einem (korrekten) 2,999999999 ein (falsches) 3,000000001 o. ä. bekommst; ansonsten kann ich so auf die Schnelle kein nennenswertes Problem entdecken. Aber was hat das mit deinem eingangs angesprochenen Problem zu tun? Wolfgang -- -- Liste abmelden mit E-Mail an: [email protected] Probleme? https://de.libreoffice.org/hilfe-kontakt/mailing-listen/abmeldung-liste/ Tipps zu Listenmails: https://wiki.documentfoundation.org/Netiquette/de Listenarchiv: https://listarchives.libreoffice.org/de/users/ Alle E-Mails an diese Liste werden unlöschbar öffentlich archiviert
