WritePro berücksichtigt bei Bildern den Zoomfaktor (des Bildes) nicht

In einer WritePro-Vorlage wird per Methode (“Arzt_StempelGet”) ein Bild inline eingefügt. WritePro zeigt dieses Bild in Originalgrösse an, obwohl das Bild innerhalb der Methode per Bildoperator “*” mit einem Faktor von z.B. 0,5 multipliziert (gezoomt) wurde. Unter 4DWrite wurde das Bild noch richtigerweise mit der halben Grösse (in x- und y-Richtung) angezeigt.

//Arzt_StempelGet(Arzt:T{;Faktor:R})->Stempel:Bild
$0:=[Betriebsarzt_Stempel]Stempel*[Betriebsarzt_Stempel]Faktor_Stempel

4D : v17.0, 17R4
Product :4D - 4D Server
OS : Windows, Mac

Sie ändern mit dem alten * Faktor, bzw. mit TRANSFORM PICTURE nicht das Bild selbst, sondern nur die Darstellung innerhalb eines 4D Formulars. 4D Write hat “nur” 4D Bilder unterstützt und dies daher 1:1 übernommen, 4D Write Pro hat dagegen erweiterte Bild-Unterstützung, mit eigenen Skalierungsoptionen.

Sie müssen entsprechen 4D Write Pro Attribute anwenden, je nachdem ob das Bild inline, als Hintergrund, Anker, etc, eingesetzt wurde.

Siehe
https://doc.4d.com/4Dv17/4D/17/4D-Write-Pro-Attribute.300-3726323.de.html
(scrollen zu Höhe/Breite)

1 Like

Danke für die Erklärung,
“TRANSFORM PICTURE” erzeugt also keine neue Bildsource
sondern ordnet der original Bildsource nur Darstellungseigenschaften
für 4DForm(+altes4DWrite) zu.
Schön auch das man in neuem4DWritePro eine Bilddarstellung
relativ frei setzen kann (wp+css),
was man so meist dann auch nutzt um Bild-Skalierung ans document anzupassen.
Z.B. Eine Bildsource die auf einer Seite gleich mehrfach verwendet wird,
einmal um das Bild als kleines Icon anzuzeigen und einmal in voller Seitenbreite…

Bei besonderen Anwendungfällen wie z.B. export nach html-document
wäre es doch besser manche Bilder optional nicht in originaler Größe anzuhängen
sondern nur so groß wie sie auch angezeigt werden wenn z.B. Orginal 2MB aber 30kb schon ausreichen würden für die Anzeige.
Wann ein image-ordner beim html-document erzeugt wird und
wann inline base64 codierte bilder direkt im html-source-code landen
hängt wohl vermutlich (?) von der Größe ab (…ein hunderttausenzeiliges base64 Bild würde massiv ausbremsen).
U.a. bei PDF+Druck (oder bei späteren Änderungen am wpDoc) ist ja eine gewisse Reserve in der Auflösung erwünscht…
Möchte man trotzdem in dem wpDoc hingegen nur so große BildSourcen einbauen wie vorausichtlich zur Anzeige ausreichend ist, so könnte man doch z.B… mit “CREATE-THUMBNAIL”
eventuell ein kleineres neues Bild erzeugen (oder tut dieser Befehl auch nur Darstellungseigenschaft der originalen Bildsource ändern)?
https://doc.4d.com/4Dv18/4D/18/CREATE-THUMBNAIL.301-4505321.en.html

Auch weis ich nicht ob beim html-export die Bilder im Bilderordner schon ggf.
verkleinert exportiert werden
oder ob sie in Original-Größe exportiert werden und nur die css-eigenschaft für ihre rein optische Skalierung in der Seitendarstellung sorgt. Ich vermute es werden die Bilder in originaler Größe/Auflösung exportiert.

Meine Fragen sind keinesfalls dringlich,
wollte eigentlich nur auf möglicherweise optionale Alternative “CREATE-THUMBNAIL”
aufmerksam machen für Sonderfälle wo man ein paar Bytes bei den Bildsourcen sparen möchte,
vorausgesetzt der Befehl funktioniert so wie ich vermute.

Richtig. TRANSFORM PICTURE ist in den meisten Fällen nicht destruktiv. Siehe Doku:

Beachten Sie, dass die Operationen bis auf “Beschnitt” und “In Graustufen umwandeln” durch Ausführen der entgegengesetzten Operation oder über die Operation “Reset” wieder umkehrbar sind. So erhält zum Beispiel ein Bild, das auf 1% reduziert wurde, durch anschließendes Vergrößern mit dem Faktor 100 wieder ohne Beeinträchtigung die Originalgröße. Transformationen verändern nicht den ursprünglichen Bildtyp. So bleibt ein Vektor-Bild nach der Transformation weiterhin ein Vektor-Bild.

Will man die Änderung “einfrieren”, kann man entweder crop oder Convert Picture (anderes Format) einsetzen. Dadurch wird ein neues Bild erzeugt und damit geht auch frühere Auflösung/etc verloren.

1 Like