Date: prev next · Thread: first prev next last
2017 Archives by date, by thread · List index


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: users+unsubscribe@de.libreoffice.org
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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.