Re: [de-users] Calc Makro: Rätselhafte Zeilenhöhe

Hallo Volker,

ich mische mich erst verspätet in die Diskussion ein, in späteren Mails 
als der, auf die ich diese Antwort schicke, ist schon vieles gesagt, 
insbesondere Thomas Krumbeins Hinweis auf "ma" oder "twips" - findest du 
auch etwas ausführlicher in seinem Buch über Makros - bringt den 
eigentlichen Kern des Problems herein, nämlich die Notwendigkeit der 
Umrechnung in geräteabhängige Maßeinheiten. Aber die Mail, auf die ich 
antworte, ist für mich der Kern der Fragestellung.
Die Gleichsetzung der Eingabe eines ganzahligen Wertes mit dem 
abstrakten Konzept einer Ganzzahl ist nicht schon nicht ganz ohne. Das 
sieht so aus, weil die zugehörige Maßeinheit z.B. 1/100 mm ist, aber ist 
das dann eine saubere Ganzzahl? In welchem Kontext? Ganze Zahlen kommen 
meiner Meinung nach vom Zählen, und von da zum Messen von Abständen, 
wofür du ja die Gannzahl verwendest, ist ein weiter Weg. Bedenke: wir 
sind hier mit praktischen Dingen beschäftigt und nicht mit Theorie (ich 
bin selbst Mathematiker!), und man muss immer den Kontext bedenken. Du 
könntest sagen, es sei eine Dezimalzahl mit z.B. 3 fixen 
Nachkommastellen, das sei fast das gleiche. Das Problem ist, dass du 
diese Zahl meist mit einer anderen in Beziehung setzen musst (schon wenn 
du z.B. eine Tabelle mit drei Spalten auf einer Seite darstellen willst, 
da hast du gleich ein Verhältnis mit einem unendlichen, wenn auch 
periodischen Dezimalbruch, auch im Binärsystem, und den kann man nicht 
mit endlich vielen Nachkommastellen darstellen, die es einfach braucht 
wenn man ein allgemein verwendbares System bereitstellen will), und 
damit bist du sebst bei der vereinfachenden Annahme, dass alles im 
metrischen System läuft, schon beim Problem von Rundungen und den daraus 
folgenden Ungenauigkeiten, mit denen du rechnen musst.  Mag sein, dass 
man ein geschicktes System für die Behandlung von Brüchen mit EDV 
entwerfen könnte, aber dann brauchen wir ja auch mal Quadratwurzeln und 
sonstige algebraische Zahlen und mit Sinus u.ä. auch transzendente 
Zahlen, und dann landen wir pragmatisch wieder bei Annäherungen durch 
endliche Brüche.
Hinzukommen die Berücksichtigung unterschiedlicher Maßsysteme (Zoll!) 
und die schon genannten Geräte-spezifischen Anforderungen.
Die Programmierer müssen all das berücksichtigen, und wenn sie das mit 
Double-Variablen tun, nützen sie den Typ, der die höchste Präzision 
hergibt. Das funktioniert ja auch annähernd bzw. ziemlich genau, und wer 
mehr will, muss sich selber bemühen. Du weißt das ja auch und tust das 
entsprechend, mir geht es nur darum, ein Verständnis für die 
Schwierigkeiten zu wecken, die in dem Thema stecken. Dabei ist das auch 
nur eine Außenansicht, ich bin in diesen Themen nicht aktiv, ich 
versuche nur, die Prinzipien nachzuvollziehen.

Gruß

Gerhard

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. Aus weit entfernten Assemblerzeiten erinnere ich 
> mich an entsprechende Befehle :-)
>
> > ... es wird auch nicht
> > absichtlich o. ä. abgerundet sondern das ist lediglich die beste
> > *Annäherung* an den betreffenden Dezimalwert. Mehr kann man IMHO nicht
> > verlangen.
> >
> > 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. 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. Um 
> in deinem Beispiel zu bleiben: Wenn ich eine Tomate kaufe, und das 
> zehnmal, ärgere ich mich, wenn es nur 9 sind.
>
> 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.
>
> Ganz simpel: iRowsPerPage = lPageHeight \ lRealRowHeight
> Und:         iRowsOnLastPage = iRows Mod iRowsPerPage
> Oder was wäre besser?
>
> Schöne Grüße
> Volker


--
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