Storyline ist wirklich mühsam zu debuggen - der Export sieht ja jedesmal syntaktisch verschieden aus (alle IDs sind jedesmal neu, alle Mediendatei bekommen jedesmal neue Name, ... )
vorab:
zuerst das Problem wirklich verstehen - das ist der wirklich schwierige Teil - nicht zu früh von Symtomen auf Ursachen schließen (das passiert einem dauernd)
alle Tests mehrfach mit Varianten machen, immer wenn man glaubt eine Lösung zu haben, unbedingt Fehlerfall wieder provozieren
Erst dann kann man entscheiden, ob mit der dann reduzierten (fehlerfreien) Funktionalität das Projekt noch machbar ist.
und jetzt konkret:
DPI sollte vollkommen egal sein, es zählen im Browser nur die realen Pixel
alle Test mit einem frischen leeren Storylinefile (Fläche etwa so große wie Testbilder, sonst greift u.U. Storyline wieder ein: starkes Resize -> automatische Neuberechnung der Bildes)
vor jedem Export auf eine Slide (doppel)klicken (nicht direkt auf Publish, das ist zur Zeit - oder auch schon lange - in Storyline fehlerhaft !!!)
nach jedem Publish Storyline schließen, ggf Datei sichern und neu starten - dann sind die Tests representativ (weil Storyline dann sein Caches löscht)
diese Erkenntnis hat mich bei der letzten großen Fehlersuche in Storyline etwa 2 Tage Tests gekostet, Storyline ist wirklich sehr eigen
Tests
- liegt es am Bild oder daran das es das zweite plazierte Bild ist
-> Storyline generieren Slide 1 verwendet Bild 1 / Slide 2 das gleiche Bild 1
-> Storyline Slide 1 Bild 1 / Slide 2 Bild 2
das wäre meine Testreihenfolge für Bildformate (liegt es am Format ?)
- jpg (echtes Photo) ca 1600x1200 Pixel oder kleiner, schwach komprimiert
- jpg wie oben, start kompromiert
- jpg mit/ohne eingebundenes Farbprofil
- PNG mit Alpha-Kanal (32 Bit)
- PNG ohne Alpha-Kanal (24 Bit)
- ggf. gif (ohne Animation)
- ggf. svg mit eingebettetem PNG (wird dann als Javascript Datei importiert)
- ggf. funktioniert Video mit Standbild (das wäre noch eine Notlösung)
Jürgen