InfoPanel und SVG's aus ./images/openautomation

[Avatar]

Ich habe ein Problem wenn ich die SVG's aus dem Bereich ./images/openautomation nehmen möchte und dies auf dem InfoPanel darstellen möchte.
Da dauert es ewig für die Darstellung, die Skalierung ist komplett anders, sie erscheinen dann viel zu gross. Ich benutze es in Verbindung mit der Routine "btIP_changeColor".

Bin ich der Einzige der diese Probleme hat?

Wenn ich SVG's aus dem Bereich ./images/fhemSVG nehme gibt es keine Probleme.

Grüsse
Eric

[betateilchen]

Das liegt schlicht daran, wie eine SVG Datei in ihrem Inneren aussieht (genauer: wie sie erzeugt wurde), die Funktion btIP_changeColor() kann nix dafür. Der schlimmstmögliche Fall sind SVG Dateien, in denen einfach ursprünglich als Bitmap erstellte Grafiken ohne Umwandlung in Pfade in eine SVG Datei konvertiert wurde.

Genauere Auskunft gibt ein Blick in die SVG Datei, die man einfach mit einem Texteditor öffnen kann.

[Avatar]

Ja das ist mir soweit schon klar. Nur ist die Frage was kann ich da unternehmen. Denn diese Dateien können unter FHEM ohne weiteres genutzt werden und es klappt, wie auch immer.
Im InfoPanel und mit "btIP_changeColor" leider nicht.

Grüsse
Eric

[Benni]

Ich hatte auch schon mal ein kleines Problem mit btIP_colorChange und SVG und zwar dann, wenn in den SVGs keine Farbe (ich glaube f. "stroke"; sorry bin gerade nicht auf meiem System) definiert war. btIP_changeColor macht ja, wenn ich's noch richtig im Kopf habe, eigentlich nur einen simplen replace für die Farbe und zwar wird "#000000" gesucht und entsprechend mit der gewünschten Farbe ersetzt.

Wenn man das Icon nun mal zum bearbeiten öffnet (bspw. Inkscape) und alles was schwarz sein muss auch tatsächlich schwarz einfärbt, sollte es funktionieren, zumindest klappte das so bei mir.

Bei mir waren das aber keine Icons aus openautomation, sondern aus "persönlicher" Quelle

Aber ein Versuch kann ja nicht schaden.

Gruß Benni.

[Avatar]

Hallo Benni
Danke für deine Antwort.

Was die Problematik ist, ist wie das Parsing der SVG dabei erfolgt. So wie es aussieht, hat das Modul Schwierigkeiten wenn höhe, breite ect. auf einer Zeile im File geschrieben ist, oder in der art etwas im kopf steht was nicht unbedingt sinnvoll ist. Ich müsste da mehr das Modul analysieren, dachte aber, da ich nicht der Owner bin, da zeit ersparen könnte und dies dem Erstellen übergeben könnte.

Grüsse
Eric

[Benni]

Ok! Dann bin ich an der Stelle wieder raus!

[betateilchen]

Das Modul selbst parst bei Farbentausch keine Größeninformationen. Es durchsucht schlichtweg den Inhalt der SVG Datei und ersetzt den hexadezimalen Farbcode per regexp.

Aber wenn Du einen besseren Lösungsweg hast - den Du ja jederzeit in Deine 99_myUtils einbauen, testen und verwenden kannst - bin ich immer offen für Anpassungen.

[Avatar]

Ok, ich muss es mal anschauen.

Einfach zur Info. Wenn ich die SVG Datei welche fehlerhaft ist wie folgt ändere:

alt:
<svg version="1.0" xmlns="http://www.w3.org/2000/svg"
width="468pt" height="375pt" viewBox="0 0 468 375"
preserveAspectRatio="xMidYMid meet">

neu:
<svg version="1.0"
xmlns="http://www.w3.org/2000/svg"
width="468pt"
height="375pt"
viewBox="0 0 468 375"
preserveAspectRatio="xMidYMid meet">

d.h. pro Zeile eine definition, dann funktioniert es.

Grüsse
Eric

[betateilchen]

Ich habe auch schon 100kB große SVG gesehen, in denen es nicht einen einzigen Zeilenumbruch gab... da war dann wirklich alles zu spät.