Benutzer Diskussion:Con-struct

rsvg im SVG-Buch

Die Vorschaubilder sind ja auch mit rsvg erstellt, da sieht man oft, daß die Darstellung falsch ist, es ist also vieles falsch implementiert oder aber einige Fehler von rsvg schlagen an vielen Stellen durch, weswegen viele Dinge nicht in vollem Umfange korrekt dargestellt werden, Autoren können sich also nicht drauf verlassen. Daher reicht es meiner Meinung nach nicht, nur zu gucken, ob die irgendwas implementiert haben, das sollte dann schon auch meistens richtige Ergebnisse liefern. Die Verfügbarkeit sagt also letztlich nicht so viel darüber aus, ob Autoren davon ausgehen können, daß das auch verwendbar ist. Da in dem Buch nur sporadisch getestet wird, beruhen auch die Angaben zu anderen Darstellungsprogrammen meist nur auf Schätzungen oder Tests, die nicht im Buch stehen, daher sind das auch subjektive Einschätzungen. Auch von daher bin ich mir nicht so sicher, wie sinnvoll die Angaben überhaupt sind. Bei den anderen Programmen steht da immerhin die Version, mit der eine weitgehend erfolgreiche Interpretation nachvollzogen werden konnte - warum schreibst du da nur 'ja' und eine Version als nur im Quelltext sichtbaren Kommentar? Doktorchen 12:49, 7. Mär. 2013 (CET)

Hi Doktorchen. Ich hatte zuvor lange und vergeblich gesucht, welche 1.2 Funktionalitäten in rsvg implementiert sind, bis ich auf den Gedanken mit dem Source-Code kam. Eigentlich wollte ich nur diese 1.2 Dinge eintragen. Da ich aber einmal dabei war, habe ich noch ein paar weitere Nicht-Funktionalitäten ergänzt.

Bei den (nur vermutlich sicher) implementierten Dinge entschied ich mich für „Ja“, nachdem „mindestens 3.7“, „min. 3.7“, „3.7 oder kleiner“, „m. 3.7“, „3.7“ noch ungeeigneter erschienen. Vielleicht gibt es eine bessere Idee. Um den genauen Versions-Stand einzutragen, müßte sich aber erst mal jemand finden, welcher in den zahlreichen Vor-Versionen sucht und vielleicht auch noch prüft. Gruß -- Con-struct 20:00, 7. Mär. 2013 (CET)

Weiter vorne im Buch ist erklärt, was die Zahlen zu bedeuten haben - wenn man da 3.7 hinschreibt, heißt das, zumindet mit der Version und vermutlich auch neueren ist das Merkmal weitgehend richtig implementiert. Wenn ich mehr weiß, etwa Version 3 bis 17 oder sowas, dann habe ich das dort notiert - wenn der Fehler dann in Version 25 wieder behoben ist, kann das dann immer noch ändern, wer das Merkmal mit der Version testet, ähnliches gilt, wenn jemand feststellt, daß etwas schon in 2.1 gut funktioniert, nicht erst ab 3.7, wobei man meist davon ausgehen kann, daß es dann auch bei den Zwischenversionen 2.1 bis 3.7 funktioniert - Ausnahmen gibt es da natürlich ab und an einmal ;o) Teils ist auch explizit sowas erwähnt wie 1.7 (falsch), um zum Ausdruck zu bringen, daß es implementiert ist, aber eben in der Version falsch. Man kann auch schreiben 1.7 (teilweise) - insgesamt zwar nicht viel Information für den Leser, aber besser als nichts, und das Buch ist ja nicht primär dazu da, Fähigkeiten von Darstellungsprogrammen zu testen. Bei der hier verwendeten Version von librsvg stimmt wohl unter anderen mit der Vererbung von Eigenschaften nicht, daher versagt das Teil bei relativ vielen Bilder aus dem Buch, gibt aber auch diverse andere Mängel. Anhand der Beispielbilder kann man teilweise auch direkt sehen, daß einige Sachen bei der hier verwendeten librsvg offenbar falsch implementiert sind, wo du für Version 3.7 offenbar ein korrektes Ergebnis vorgefunden hast (text-anchor, text-decoration etwa). Doktorchen 20:28, 7. Mär. 2013 (CET)

Markierungen: Ursprung und Grenzen im SVG-Buch

Der ergänzte Absatz scheint mir unverständlich oder falsch zu sein. Den Ursprung kann man beliebig setzen, man muß eben nur die viewBox passend setzen. die Eigenschaft overflow ist per Empfehlung in der Stilvorlage des Darstellungsprogrammes auf 'hidden' zu setzen, daher ist wohl die Anzeige von Opera korrekt. librsvg und inkscape haben vermutlich gemäß den PNGs eine fehlerhafte Implementiertung von 'viewBox' bei Markierungen und bei inkscape ist zusätzlich overflow nicht auf 'hidden' gesetzt, weshalb im ersten Beispiel die Kreise komplett sichtbar sind. Wenn du Eigenschaften und Attribute für Markierungen testen willst, solltest du auch das zugehörige SVG-Dokument komplett hochladen, nicht nur Fragmente daraus einbetten - und die PNGs bringen nichts, weil da nicht dransteht, welche Version der Programme das so darstellen. Zudem sollte man dann hervorheben, daß die Darstellung wie bei Opera wohl die korrekte ist, die anderen falsch - für Mozilla/Gecko, WebKit, Squiggle etwa könnte man dann auch noch Ergebnisse erwähnen - ich bin mir aber nicht sicher, ob es überhaupt sinnvoll ist, das Buch systematisch mit Tests und Beispielen für fehlerhafte Darstellungen zu ergänzen, ein PNG für die richtige Darstellung würde ja zusammen mit dem SVG-Dokument reichen, wenn man dann einfach dazu hinschreibt, welche Programme fehlerhaft sind und welche richtig - fehlerhafte Darstellungen muß man bei einem Test nicht dokumentieren. Wichtig ist vorrangig anzugeben, welches die richtige Darstellung ist. Statt eines PNGs ist es meist auch einfacher, direkt im SVG eine Kontrolle unterbringt - etwa eine rote Referenz, welche bei einer korrekten Darstellung andersfarbig verdeckt wird - sobald man etwas Rotes im Test sieht, ist die Darstellung falsch, da muß man nicht lange rätseln. Bei vielen Test-ähnlichen Beispielen im Buch ist das nach Möglichkeit so umgesetzt, um auch ohne PNG direkt erkennen zu können, wenn das gerade verwendete Programm Blödsinn macht. Unabhängig davon kann es natürlich auch hilfreich sein, wenn die richtige Darstellung ein irgendwie ästhetisch 'schönes' Ergebnis liefert, welches irgendwie brauchbar aussieht, also hier wohl eher keinen angeschnittenen blauen Kreis. Der grüne Kreis mit rotem Kringel links oben in den PNGs ist von der Funktion her auch unklar, sonst nicht verwendete Elemente, die nur per use referenziert werden, kann man doch einfach in ein defs schreiben.

Was ist eine Element-Koordinate bei einem flächigen Objekt? Die Aussage im Text scheint mir keinen Sinn zu ergeben. Hier ist offenbar der Kreismittelpunkt gemeint. Da man aber eine beliebige Anzahl von Objekten in die Markierung reinstecken kann, ergibt der ganze Abschnitt so keinen Sinn, denn man ordnet die Elemente in der viewBox ja so an, daß man die Markierung erhält, die man gerne hätte, die Koordinaten bestimmen sich also danach, wie die Markierung aussehen soll. Ein Attribut translate gibt es auch nicht, und statt transform kann man natürlich bei dem Beispiel auch den Mittelpunkt des Kreises passend wählen oder eben die viewBox.

Kurzum, Beispiel ist offenbar schon sinnvoll für den Leser, wenn es geeignet umgesetzt ist und als SVG-Dokument verfügbar, der Text oder die mutmaßliche Schlußfolgerung ist aber unverständlich oder falsch, die PNGs sind redundant, wenn man das SVG-Dokument geeignet umsetzt ...Doktorchen 15:10, 17. Mär. 2013 (CET)