[DEV] Jewel erzeugt fehlerhafte CacheWolf.jar

Hallo!

Bei mir erzeugt Jewel eine fehlerhafte CacheWolf.jar. Ca. 50 Bilder werden nicht richtig verpackt: sie haben eine gepackte Länge von 0. Wenn man die .jar in .zip umbennennt und mit winrar anschaut sieht man es. Man kann dann auch alle Dateien markieren und auf "Überprüfen" klicken, dann zeigt er eine vollständige Liste der betroffenen Dateien.
Es sind ausschließlich Bilder betroffen, sowohl .gif als auf .png
Ich habe bereits folgende Tests gemacht:
1. Das Problem tritt sowohl in der Komandozeile alsauch in der GUI-Version von Jewel auf
2. Es liegt nicht am Dateinamen (Umbennen belässt den Fehler bei dem selben Bild. Auch ein anderes nicht betroffenes Bild so nennen belässt das Bild fehlerfrei)
3. beim Flyingfish taucht das Problem nicht auf, auch nicht, wenn man manuell per jar.exe zusammenpackt (aber das macht keinen Spaß).
4. es scheint daran zu liegen, was das Bild zeigt: Wenn ich das gleiche Bild mit anderer Bittiefe speichere, dann tritt es dennoch auf.

MiK hat schon berichtet, dass er ein ähnliches Problem hat und es nicht lösen konnte. Wie sieht das bei den anderen Entwicklern aus? Tritt es vielleicht nur in Windows auf?
Bei mir hat die 109.png den Fehler, während die 108.png ihn nicht hat.

Gruß,
Pfeffer.

Es scheint u.a. an der Kompression des Bildformats zu liegen. Ich habe mal testweise alle PNGs ohne Kompression abgespeichert - dann sind alle PNGs (bis auf eins) richtig. Allerdings werden die Bilder dann auch deutlich größer.
Ich hab sie jetzt mal mit "schneller Kompression" abgespeichert und eingecheckt - jetzt sind deutlich mehr PNGs korrekt drin als vorher. Die verbleibenden müsste man dann vielleicht ohne Kompression abspeichern.
Um die GIFs hab ich mich jetzt noch nicht gekümmert - da gibts ja auch verschiedene Speicheroptionen.

Grüße,
Engywuck

Ihr wollt nicht im Ernst jetzt die Kompressionsrate der Bilder
verringern, nur um um einen Windows-Bug rumzuwerkeln,
und dann fixt der Würgaround nichtmals ALLE von den Bildern?

*kopfschüttel*

Außerdem wird CW dadurch viiiel größer.

Mirabilos:
- Das Zertifikat für »herc.mirbsd.org« ist vom unbekannten Zertifikatsausteller »CA Cert Signing Authority« unterzeichnet. Es kann nicht festgestellt werden, ob dies ein gültiges Zertifikat ist.

mirabilos schrieb:

Ihr wollt nicht im Ernst jetzt die Kompressionsrate der Bilder
verringern, nur um um einen Windows-Bug rumzuwerkeln,
und dann fixt der Würgaround nichtmals ALLE von den Bildern?

Zum Vergrößern anklicken....

Als besseren Workaround könnte man die Bilder in einem zweiten Verzeichnis duplizieren, in dem dann die verringerte Kompression verwendet wird. Dieses Verzeichnis wird dann nur bei der Erzeugung der jar-Datei verwendet. Auf dem PC ist die Größe ja nicht so spannend...

Grüße,
Engywuck

Ich bin auch dagegen an der Kompression etwas zu ändern. So lange es auf flyingfish korrekt erstellt wird, hat das keine Eile und wir können versuchen den Fehler zu finden und müssen ihn nicht umgehen.

Ich würde also vorschlagen diese Änderung rückgängig zu machen.

Äh. Öh.
Seltsam.
Grad mal geschaut:

Vor geänderter Komprimierung:
183608 Byte in Ordner ressources

Nach geänderter Komprimierung:
153964 Byte in Ordner ressources

(jeweils ohne .svn und attributes)

Ich würde vorschlagen, die Änderung zu belassen ;-)

Engywuck

Engywuck schrieb:

Mirabilos:
- Das Zertifikat für »herc.mirbsd.org« ist vom unbekannten Zertifikatsausteller »CA Cert Signing Authority« unterzeichnet. Es kann nicht festgestellt werden, ob dies ein gültiges Zertifikat ist.

Zum Vergrößern anklicken....

Das nervt wirklich etwas.

Ich kann sie ja mal mit Kompression 9 basteln, oder so.

@Engywuck: gehst Du zu http://www.cacert.org/ und ziehst dir deren
Root-CA-Zertifikat und importierst das im Browser. Und _bitte_ beim
Browserhersteller beschweren, gerade Firef*x (M*zilla) ist da extrem
konservativ, selbst Micr*s*ft hat schon (wenig) mehr Bereitschaft ge-
zeigt, das zu integrieren).

mirabilos schrieb:

Ich kann sie ja mal mit Kompression 9 basteln, oder so.

Zum Vergrößern anklicken....

Aber bitte testen, ob es an dem Problem etwas ändert. Es ergibt keinen Sinn ständig neue Bilder einzuchecken, die das Problem am Ende doch nicht lösen.

mirabilos schrieb:

@Engywuck: gehst Du zu http://www.cacert.org/ und ziehst dir deren
Root-CA-Zertifikat und importierst das im Browser. Und _bitte_ beim
Browserhersteller beschweren, gerade Firef*x (M*zilla) ist da extrem
konservativ, selbst Micr*s*ft hat schon (wenig) mehr Bereitschaft ge-
zeigt, das zu integrieren).

Zum Vergrößern anklicken....

Davon unabhängig ist sowas für ein Avatar einfach überflüssig.

Engywuck schrieb:

Äh. Öh.
Seltsam.
Grad mal geschaut:

Vor geänderter Komprimierung:
183608 Byte in Ordner ressources

Nach geänderter Komprimierung:
153964 Byte in Ordner ressources

(jeweils ohne .svn und attributes)

Ich würde vorschlagen, die Änderung zu belassen ;-)

Zum Vergrößern anklicken....

ja, bitte drin lassen!
(Aber schon interessant: bei derart kleinen Bildern ist offenbar der Overhead für's packen größer als der Gewinn dadurch.)
@Mik @mirabilos: Wenn man durch so eine kleine Änderung selbst richtige .jars bauen kann, dann ist das schon ein großer Vorteil für's Testen vorm einchecken ;-) Außerdem denke ich nicht, dass "wir den Fehler finden" - das ist mit sehr großer Wahrscheinlichkeit in Fehler in Jewel oder einer Library, die von Jewel genutzt wird. Dafür werden wir auch, wenn wir den Fehler identifiziert haben, nicht so schnell für alle Programmierer ein Fix bereitstellen.

Gruß,
Pfeffer.

Wenn die Dateien nicht größer werden und es damit dann funktioniert, ist es ok. Aber den Vorteil selbst JARs erzeugen zu können möchte ich nicht mit größeren binaries erkaufen. Normales testen geht ja trotzdem, wenn die Dateien im Work-Verzeichnis liegen. Und mir EVE wird wahrscheinlich dann sowieso alles anders.

Was für einen Grund hat es eigentlich, dass manche Binärdateien mit in die exe reinkompiliert werden und andere nicht?

Engywuck

Die Bilder, die nicht hineinkompliert werden, sind diejenigen, die im Arbeitsverzeichnis liegen müssen, sonst werden sie von EWE zur HTML-Darstellung nicht gefunden.

Der Hintergrund der Icons für die Cachegröße ist jetzt rot statt transparent. BItte wieder korrigieren!

Dann vielleicht doch die Änderungen wieder zurücknehmen. Eigentlich hatte ich meinem Bildbearbeitungsprogramm nur gesagt, dass es alles was png heisst, neu abspeichern soll, mit geringerer Kompression. Wenn das jetzt aber noch unvorhergesehene Nebenwirkungen zeitigt, fahren wir mit den alten Icons vermutlich besser.

Engywuck

P.S.: Am Wochenende kann ich vermutlich nix machen (wenn ich meinen Rechner nicht hilfsweise ans laufen bekomme).

MiK schrieb:

Der Hintergrund der Icons für die Cachegröße ist jetzt rot statt transparent. BItte wieder korrigieren!

Zum Vergrößern anklicken....

Werden sie bei Dir in CacheWolf rot angezeigt? - Bei mir nicht. Es scheint sich um einen Fehler in IrfanView zu handeln, das zeigt mir den transparenten Bereich jetzt auch rot. Aber CacheWolf zeigt es korrekt, XnView, GIMP und Windows-Bild-undFax-Anzeige auch.
Mir scheint es keinen Grund zu geben, da was zu ändern (außer dass das Problem noch nicht bei allen Bildern behoben ist).
Allerdings zeigt mir IrfanView auch weiterhin an, die Bilder wären min PNG-ZIP komprimiert.

Gruß,
Pfeffer.

Sie werden in Cachewolf falsch angezeigt. nicht Nur in anderen Betrachtungsprogrammen. Wie hast Du es getestet? Mit einem frischen Verzeichnis oder in "work"?

Bei mir werden sie auch im CW falsch angezeigt.
Zusätzlich zu den Size-Icons aber auch die Goto_VGA Datei.... Genauso mit rotem Hintergrund.

Ich habe die Änderungen gerade rückgängig gemacht. Das eigentliche Problem haben sie sowieso nicht behoben.