[GERMAN]Hilfe zu Design & Print: Auswertung von Variablen

[wolboe]

Zur Platzierung  von Bildern in optimal passende Container möchte ich mit {File.Width|cast:int;math:div,{File.Height|cast:int},2} oder {File.AspectRatio} das Seitenverhältnis der Bilder abfragen und mit dem Ergebnis den richtigen  Container, auch mit richtiger Ausrichtung, auswählen.
Mit meinem laienhaften Ansatz nach dem Muster {File.AspectRatio|is: 3:4, TV,FV} .... komme ich nicht zum gewünschten Ergebnis.
Meine Vorstellung ist so etwas wie:
{File.Width|numformat:int,;NumComp:gt,{File.Height|numformat:int,},0,;NumComp:lt,{File.Height|numformat:int,},1,;NumComp:eq,{File.Height|numformat:int,},1,}
Hier wird aber nur zwischen Hoch-, Querformat  sowie Quadrat unterscheiden – ich möchte aber das tatsächliche Seitenverhältnis auswerten und damit z. B. im Hochformat zwischen  16:9 und 3:4 unterscheiden.
Kann mir jemand helfen?

Translated with DeepL:
Help for Design & Print: Evaluation of variables
To place images in optimally fitting containers, I would like to use {File.Width|cast:int;math:div,{File.Height|cast:int},2} or {File.AspectRatio} to query the aspect ratio of the images and use the result to select the correct container, also with the correct alignment.
With my amateurish approach following the pattern {File.AspectRatio|is: 3:4, TV,FV} .... I do not get the desired result.
My idea is something like:
{File.Width|numformat:int,;NumComp:gt,{File.Height|numformat:int,},0,;NumComp:lt,{File.Height|numformat:int,},1,;NumComp:eq,{File.Height|numformat:int,},1,}.
But here it only differentiates between portrait, landscape and square - but I want to evaluate the actual aspect ratio and thus differentiate between 16:9 and 3:4 in portrait format, for example.

Can anyone help me?

Danke!
Wolfgang

[Mario]

{File.AspectRatio} liefert das Seitenverhältnis als Konstante, oder, wenn keine Konstante passt, als Näherungswert. Siehe Variables.
Je nach Art deiner Bilder und dem Beschnitt musst Du also ggf. mit 3, 5 oder einem Dutzend Werten umgehen. Das ist viel zu kompliziert.
Vielleicht ist dein Layout super-komplex, aber ich denke, die meisten Anwender kommen mit den vorhandenen Fill/Fit-Modi aus. Container anhand des Seitenverältnisses auswählen ist wirklich sehr speziell.

Eventuell einfach die Bilder vorher nach SV in Kategorien sammeln und dann anhand von Gruppen für jede Kategorie ein anderes Seitenlayout?

Oder, vielleicht wäre die Verwendung eines ein DTP-Programms, InDesign, Microsoft Publisher, Scribus, Affinity Publisher und ein manuelles Layout sinnvoller. Design & Print ist mächtig, aber nicht allmächtig. Es ist auch eines der am wenigsten genutzten Features in IMatch, weshalb es nur eine geringe Prio für Weiterentwicklung hat.

[wolboe]

Hallo Mario,
Dank für die wie immer schnelle Antwort.
Hintergrund und Beispiel:
Erstellen eines Bilderbuches vom Urlaub oder Ähnlichem: meine Bilder sind nach der Bearbeitung sowohl im Hoch- als im Querformat überwiegend in den Formaten 16:9; 3:4; 2:3; 1:1 oder annähernd dem jeweiligen Verhältnis; die chronologische Reihenfolge soll erhalten bleiben – deshalb ist ein ,,Vorsortieren" nach Seitenverhältnis und/oder Ausrichtung m. E.  nicht sinnvoll.
In einem dynamischen Layout lege ich mir auf einer Seite eine Gruppe von vier Containern an, die unterschiedliche Größen haben und auf der Seite optimal platziert werden können. Die Bilder sollen ,,ihren" Container durch entsprechende Einträge  unter  Hide ,,selbst finden".

Mit {File.Width|cast:int;math:div,{File.Height|cast:int},2} und between könnte ich die Zuweisung über einen Bereich vornehmen, ohne explizit jedes exakte Verhältnis vorgeben zu müssen.
Für das bessere allgemeine Verständnis, wie die Variablen genutzt werden können, kommt es mir hier auch erheblich auf die genaue Syntax für dieses Beispiel an.

Als DTP nutze ich sehr gern Affinity Publisher mit seinen enormen Layoutmöglichkeiten – aber: Metadaten aus den Bildern (Descrption ... usw) können nicht ausgelesen werden und müßten für jedes Bild manuell kopiert/eingetragen werden – und genau diese Übernahme ist mit  IMatch perfekt möglich.

Wolfgang

[Mario]

Ich weiß nicht genau, was Deine Frage ist.

[wolboe]

{File.Width|cast:int;math:div,{File.Height|cast:int},2}|between:1,30  ,1,40,TV,FV} – Das ist offensichtlich falsch – wie ist die richtige Syntax?

[thrinn]

Probiere es einmal mit:

Code Select Expand

{File.Width|cast:real;math:div,{File.Height|cast:real},2;between:1.30,1.40,TV,FV}

Ein paar Anmerkungen:
cast:int ist keine gute Idee, weil dabei die Nachkommastellen abgeschnitten werden - Integer eben. Damit kann das Ergebnis nie zwischen 1.3 und 1.4 liegen.
Dann muss man bei Gleitkommazahlen an dieser Stellen die amerikanische Notation, also Dezimalpunkt statt -komma, verwenden. Das Komma dient ja zur Trennung der Parameter einer Formatierungsfunktion.

In deinem letzten Beispiel war auch noch eine geschweifte Klammer zu viel, glaube ich.

[Mario]

Das wird momentan nicht unterstützt. Das Komma dient als Trennzeichen für Funktionsparameter. Dann gibt es noch das sowohl . als auch , in unterschiedlichen Ländern als Dezimaltrennzeichen eingesetzt werden. Oder als Tausender-Trennzeichen.

Bei einem Anwender in den USA wird math beispielsweise 0.67 returnieren, bei Dir aber 0,67.
Du nutzt , als Dezimalkomma bei between, aber das Komma trennt Funktionsparameter. Also müsste IMatch hier eine Logik implementieren, z.B. bei between für Fließkommazahlen immer . verlangen. Was aber ist, wenn dein Anwender aus DE statt Konstanten Variablen einsetzt, und diese Werte wie "2,000.50" liefern? Das war mir zu kompliziert zu dem Zeitpunkt. Und da sich seit der Einführung von between vor Jahren nie jemand beschwert hat, habe ich das vergessen. Keine Arbeit in Funktionen stecken, die niemand verwendet.

Vielleicht wäre ein zwangsweiser Dezimalpunkt für float parameter für numcomp und between sinnvoll. . 
Ich schaue mir das mal an, wenn ich das nächste Mal was an den Variablen ändern muss.

Dann wäre Dein Ausdruck sowas wie

{File.Width|cast:int;math:div,{File.Height|cast:int},2;between:0.5,0.85,TV,FV}

[wolboe]

Danke für Eure Geduld.

Heute komme ich nicht mehr dazu, weitere Versuche zu unternehmen, habe aber noch eine letzte Idee:
Um in Marios Codevorschlag {File.Width|cast:int;math:div,{File.Height|cast:int},2;between:0.5,0.85,TV,FV} das leidige Problem Dezimalkomma/punkt zu umgehen, könnte man das Ergebnis der Division mit den störenden  2 Nachkommastellen mit einer an den Code angehängten  Multiplikation mit 100 in eine ganze Zahl verwandeln.

Da dieses Thema offensichtlich einen absoluten  Einzelfall darstellt, verstehe ich es aber auch, wenn hier Euer Interesse und die Hilfe aufhören.

Wolfgang

[Mario]

I have resolved this problem by changing numcomp and between to expect a decimal comma for floating-point (real) numbers.
See #01573 in the Release Notes

[wolboe]

Perfekt!
Es gibt wohl kaum ein Problwem, dass Du nicht löst!
Danke!
Übrigens- wann bist Du mit der Quadratur des Kreises fertig?

Wolfgang

[Mario]

Das sind wenig genutzte Funktionen, und vermutlich noch weniger genutzt mit Dezimalzahlen. Und die Änderung betrifft nur Nutzer aus Ländern mit Dezimalkomma (DE usw.).
Das macht es relativ ungefährlich, diese Änderung einzuführen.