Moin!

Ich habe verschieden lange FM-Dateien in einer Buchdatei - strukturiertes Authoring.
Sobald eine FM-Datei mindestens eine Grafik (JPG, 100-200kb) beinhaltet, und ich in dieser Datei scrollen will, entstehen jedes Mal längere Ladezeiten, wenn ich an der Grafik "vorbei komme".
Auch wenn ich schon mal drüber gescrollt habe und es schon eine Ladezeit gegeben hat. Beim anschließenden wieder hoch scrollen, läd FM wieder bis zu 10 Sekunden.
Ich verstehe das nicht ganz, weil...
a) die Grafiken sind mit der angegeben Größe echt nicht sonderlich groß
b) FM stellt ja die Grafiken auch nochmals reduziert dar (verpixelte, reduzierte Grafik)

Jetzt ist mir die Frage, ob es in FM irgendwo eine Einstellung gibt, die Grafik so zu laden, dass man flüssig über sie hinweg scrollen kann oder diese Ladezeiten sonst irgendwie vermeiden kann?

Oder liegt das hier an meiner etwas älteren Hardware?
Würde mich jedoch wundern, da Text und Grafiken von normaler Größe für einen Rechner mit einem Pentium 4 mit 2,8 GHz und 2gb RAM eigentlich nicht so das Problem sein sollten, sodass dauernd nervtötende Ladezeiten entstehen.

Besonders intensive Wut und Gewaltphantasien dem Rechner/Software gegenüber entstehen natürlich, wenn man 20 Grafiken hintereinander hat und dauernd zwischen den Seiten hin und her springen muss. Jedes Mal läd FM unverständlicher Weise 10 Sekunden lang irgendwas herum... bei jeder Grafik.

Es wäre von außerordentlicher Nettigkeit, wenn mir da jemand helfen könnte. :)

Moin erda,

das »Problem« (welches natürlich keines sein sollte) mit JPG ist die Komprimierung. Bei jeder Anzeige muss die Grafik dekomprimiert werden (denn sonst kann man nicht sehen) nur um dann wieder für die Anzeige runterskaliert zu werden. In Verbindung mit Netzlaufwerken wird das teilweise mehrfach unangenehm, da FrameMaker in manchen Topologien unverständliche mehrfache Dateizugriffe macht (es ist nicht bekannt, woran es liegt).

Um zu unterscheiden, ob es am Dateizugriff oder an der Komprimierung liegt, könntest du zwei Dinge testen:

* Die Anzeige der Grafiken ausschalten (Darstellung > Optionen)
* In einer Datei einmal nicht-komprimierte Bilder (z.B. TIF unkomprimiert) verwenden.

- Michael Müller-Hillebrand

servus erhier,

sind die Grafiken refernziert (Import durch Referenz) oder eingebunden (Datei in Dokument kopieren)? Letzteres ist der bessere Weg.

Grüße,
Thomas

Antwort auf [ ktedo ]

Letzteres ist der bessere Weg.

Hallo Thomas,

das ist eine zu pauschale Aussage. "Besser" wirklich nur im Hinblick auf mögliche Such- und Ladezeiten. Ansonsten tooooootal unbesser, weil a) die Dateigröße der FM-Dokumente mit den Bildern erheblich wächst, b) der Kontakt zu den Originalbildern verloren geht (Aktualisierungen/Änderungen) und c) noch nicht mal das Schnelligkeit garantiert, wenn die FM-Dokumente selbst im Netzwerk (anstatt lokal) liegen.

Grüße,
Bernd

uuups, sorry, ich habe mich verwechselt ;-|

Natürlich hast Du recht Bernd!

Selbstverständlich meinte ich dass referenzierte Bilder besser sind! Zumindest bei meinen nahezu ausschließlich verwendeten EPS-Grafiken. Mit jpg habe ich außerdem recht schlechte Erfahrungen machen müssen - selbst beim Referenzieren. Was wohl an der Vorschaugrafik bei EPS liegen dürfte....

Grüße, Thomas

Danke für eure Antworten!

Antwort auf [ michaelmh ]

In Verbindung mit Netzlaufwerken wird das teilweise mehrfach unangenehm, [..]

Jep, es handelt sich um FM-Dateien und Grafiken, die auf einem Server liegen. Unangenehm sowas. Vielleicht wäre es auch ein Versuch wert, sich jedes mal morgens den Ordner mit dem FM-Dateien lokal auf den Rechner zu ziehen und Abends nach getaner Arbeit wieder auf den Server zu schieben. Ist ansich Daten- und Backuptechnisch nicht Sinn der Sache ... aber naja.

Antwort auf [ michaelmh ]

Um zu unterscheiden, ob es am Dateizugriff oder an der Komprimierung liegt, könntest du zwei Dinge testen:

* Die Anzeige der Grafiken ausschalten (Darstellung > Optionen)
* In einer Datei einmal nicht-komprimierte Bilder (z.B. TIF unkomprimiert) verwenden.

Bei ausgeschalteter Ansicht der Grafiken sind wie zu erwarten keine Ladezeiten feststellbar.
Beim Einbinden von TIF-Dateien scheinen die Ladezeiten auch verschwunden zu sein. Manko bei der Sache allerdings, dass aus den ~150kb-JPG-Bildern leider ~5,5mb-TIF-Dateien werden, wenn ich beim Umwandeln keine Kompression zulasse. Das ist speicherplatz-technische für den Server nicht akzeptabel bei uns. Mach ich da irgendwas falsch, oder müssen die TIF so riesig sein?

Antwort auf [ ktedo ]

sind die Grafiken refernziert (Import durch Referenz) oder eingebunden (Datei in Dokument kopieren)? Letzteres ist der bessere Weg.

Dass letzteres der bessere Weg sei, mag auf das Problem bezogen zutreffen. Aber prozesstechnisch muss ich die Bilder referenzieren, da ich an den Grafiken öfter noch was nachbearbeiten muss, und dann viel Arbeit hätte, wenn ich sie überall neu einbinden müsste.
Edit: Ah, während ich am Tippen war, habt ihr darüber schon diskutiert. Somit hinfällig...

Antwort auf [ erhier ]

Jep, es handelt sich um FM-Dateien und Grafiken, die auf einem Server liegen. Unangenehm sowas.

Da Thema haben wir hier auch. Tatsächlich ändert sich auch die Wahrscheinlichkeit für den FrameMaker-Sekundenschlaf abhängig von der Anzahl der laufenden FM-Arbeitsplätze, die irgendwas auf dem Server tun (wohlgemerkt: in grundsätzlich völlig verschiedenen Ordnern).

Wenn ich am Wochenende oder abends hier alleine wurstle, passiert das fast nie. Sobald hier Leben in der Bude ist, häufig. Wobei KEIN linearer Zusammenhang oder proportionales Langsamwerden hergestellt werden kann, nur die Wahrscheinlichkeit erhöht sich.

Ich habe schon versucht, mit dem Windows Taskmanager und gleichzeitig der Apple Aktivitätsanzeige herauszufinden, ob da irgendein aktiver Prozess klemmt, aber da ist NIX. Weder in Windows noch am Mac. Windows ist zu 90+X% "idle" (Leerlaufprozess), während FM klemmt. Es ist scheinbar wirklich ein FrameMaker-Special.

Unsere Bilder sind übrigens zu 95% EPS-Dateien, selbst die Pixelbilder. Historisch so gewachsen, zwecks RGB-Vermeidung (was mittlerweilen auch mit TIFF geht). Ich habe allerdings ein Manual, das von vorne bis hinten voll mit TIFFs ist, und hier gemischt unkomprimierte und LZW-komprimierte, und da SCHEINT mir das Problem nicht oder äußerst selten aufzutreten. Wäre evtl. einen Test mit LZW-TIFFs wert.

Grüße,
Bernd

Danke für die Antwort.

Dann werde ich wohl auf EPS umstellen.
Die meisten JPGs sind hier bisher von einem EPS exportiert. Hat den Hintergrund, dass die JPGs auch in Word-Dateien verbaut werden können, was ab und zu mal vorkommt.
Und dass auch Non-Grafikprogramm-User die Grafiken öffnen können, ohne ein EPS-fähiges Programm besitzen zu müssen.

Dass das dann in dem Punkt nicht mehr so ist, kann ich verantworten, hauptsache meine Nerven werden geschont und FM läuft so man es erwarten kann. Dann spar ich mir sogar den Export-Schritt. :)

Antwort auf [ erhier ]

Dann werde ich wohl auf EPS umstellen.

Nur kurz angemerkt: auch EPS erzeugt hier Denkpausen. Vielleicht hatte ich das zu unklar geschrieben. Die einzige (noch ungeprüfte) Annahme meinerseits hinsichtlich einer Besserung des Scroll-Verhaltens bezog sich auf TIFF in LZW-komprimierter und unkomprimierter Form.

Grüße,
Bernd

auch bei mir gibt es Ladezeiten beim ersten Öffnen. Allerdings erscheint mir diese als vernachlässigbar im Vergleich zur Schilderung. Selbst bei richtig großen EPS-Datein kann ich das (obwohl ich bei solchen Dingen eher sehr ungeduldig veranlagt bin) recht gut erwarten.

Grüße
Thomas

Antwort auf [ ktedo ]

auch bei mir gibt es Ladezeiten beim ersten Öffnen.

Hallo Thomas,

ja, beim ersten Öffnen ist das normal, da FM üblicherweise gleichzeitig sämtliche QVs, referenzierte Bilder usw. prüft. Das merkt man zum Beispiel daran, dass das Öffnen eines bestimmten Kapitels eines unserer Manuals (über 200 Seiten mit hunderten von Bildern) durchaus mal Minuten dauern kann. Öffnet man aber mit Hilfe eines FrameScript-Befehls ("alle Dateien des Buches öffnen (ohne Meldungen)") dieses und weitere 10 Kapitel gleichzeitig, geht das in Sekunden vonstatten.

Der Fehler scheint wirklich die beiden Bedingungen "Blättern/Scrollen" und "Netzwerk" gleichzeitig vorauszusetzen. Öffnen ist unproblematisch.

Grüße,
Bernd

Antwort auf [ erhier ]

Manko bei der Sache allerdings, dass aus den ~150kb-JPG-Bildern leider ~5,5mb-TIF-Dateien werden, wenn ich beim Umwandeln keine Kompression zulasse. Das ist speicherplatz-technische für den Server nicht akzeptabel bei uns. Mach ich da irgendwas falsch, oder müssen die TIF so riesig sein?

Nur der Vollständigkeit halber: Die Frage muss lauten: Warum können JPGs so klein sein? Die o.g. Relation von 40:1 liegt relativ hoch, d.h. die JPGs waren recht stark komprimiert.

Nehmen wir einmal 3000 × 2000 Pixel, im RGB-Modus würden hier für jedes der 6 Millionen Pixel drei Byte benötigt, um die drei Farbwerte als 8-Bit-Zahlen zu speichern, das macht also 18 MByte ohne Komprimierung. Je nach Komprimierung schrumpft das, mit verlustbehafteten wie JPG natürlich weiter als mit einer LZW-Komprimierung, die im Kern nur identisch gefärbte Pixel zeilenweise zusammenfasst.

Wenn die Ausgangsgrafik eigentlich eine Vektorgrafik ist, möglicherweise sogar mit Text, dann sind Pixelformate vollständig verboten.

Schöne Grüße,

- Michael