User talk:Sarang/Archive/2011
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
SVG simplified BS icons has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry. If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category. In all cases, please do not take the category discussion personally. It is never intended as such. Thank you! |
a×pdeHello! 19:22, 5 October 2011 (UTC):This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)
File:Flag_of_Libya_(1951).svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. |
Fry1989 eh? 19:03, 27 October 2011 (UTC):This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)
XML-Verarbeitungsfehler: Präfix nicht an einen Namespace gebunden
Hallo Sarang. Gerade habe ich mal meine ersten SVGs mit halbwegs sauberem Quellcode geschrieben, und schon gibt's ein Problem. Hier ist noch alles in Ordnung, aber wenn ich bei File:Fanoperm521.svg auf das Bild klicke kriege ich eine Fehlermeldung. Sicher siehst du im Gegensatz zu mir gleich wo das Problem liegt. Grüße, Lipedia (talk) 04:11, 5 November 2011 (UTC)
Ok, bei File:Fanoperm425.svg hat es jetzt funktioniert. Ich hab einfach noch mehr Müll rausgeworfen. Sowas wie id="path2904-2" sodipodi:nodetypes="cc"
vor allem. Findest du den Quelltext in Ordnung? Lipedia (talk) 04:32, 5 November 2011 (UTC)
- Hallo Lipedia, die Fanoperm521-Fehlermeldung liegt tatsächlich daran, dass der Präfix "sodipodi" in
sodipodi:nodetypes
dank der vorhergehenden Entmüllung nicht mehr existiert. - Erstmal vorab: Du hast dir viel Arbeit gemacht, und wirklich sehr guten Code produziert. Der Quelltext ist sehr übersichtlich strukturiert. Wenn es dich nicht langweilt (oder frustriert) könnte ich eine weiter abgemagerte Version erstellen, es liesse sich noch vieles vereinfachen, oder einfach weglassen.
- Das beginnt bereits bei den Lines. Statt circle, polygon und drei lines (immer mit allen Attributen! Hier bietet sich eine Gruppierung an, um die Attribute nur einmal zu definieren) liesse sich genau dasselbe in einem path ausdrücken:
<path stroke="#000" fill="none" stroke-width="4" d="M300,67 550,500H50zV500a144,144 0 1,1 0-288 144,144 0 1,1 0,288m250,0L175,283.5m250,0L50,500"/>
, statt 478 bytes braucht es dann 148. Weil du die Grundfigur in weiteren Grafiken versetzt benötigst empfiehlt es sich alles relativ zu einem Bezugspunkt aufzubauen, dann müssen statt zu transformieren nur dessen Koordinaten geändert werden und alles ist verschoben. Statt 148 bytes wird der path dann 153 bytes gross. - Auch die Vertices lassen sich, statt mit sieben circles (und jedesmal allen Attributen; fill="black" ist überflüssig, du kannst es ausprobieren) durch einen einzigen path ausdrücken - der ist allerdings etwas komplex:
<path stroke="#000" fill="none" stroke-width="52" stroke-linecap="round" stroke-dasharray="0,250" d="m300,67 250,433h-500zm0,288v1"/>
macht dasselbe, mit 134 bytes statt 479. - Die Numbers sind als Grafiken gezeichnet, das ist viel aufwendiger als sie als Text darzustellen, bringt aber Vorteile bei der Portierung. Auch hier liesse sich vieles zusammenfassen; alle liessen sich mit einem Pfad zeichen, statt
style="fill:#ffffff;fill-opacity:1"
ist mitfill="#fff"
genau dasselbe etwas kürzer spezifiziert, und statt 5 Stellen nach dem Dezimalpunkt wäre bei zwei oder nur einer gewiss kein Unterschied zu erkennen — auch nicht bei Vergrösserung auf 2000. Die Koordinaten sind bereits relativ definiert, da ist oft viel zu vereinfachen. Mit etwas kompakterer Schreibweise sähe die Ziffer 3 so aus:<path fill="#FFF" d="m163,291 6.64-.8c.2,1.7 .78,3 1.7,3.88 .93,1 2,1.34 3.37,1.34 1.42,0 2.6-.54 3.56-1.6 1-1.07 1.46-2.52 1.46-4.35 0-1.73-.46-3-1.4-4-.93-1-2.06-1.5-3.4-1.5-.87,0-1.93,.17-3.15,.5l0.76-5.6c1.86,.05 3.27-.35 4.25-1.2 1-.86 1.46-2 1.46-3.42 0-1.2-.36-2.16-1-2.88-.72-.72-1.67-1-2.86-1-1.17,0-2.17,.4-3,1.22-.83,.8-1.33,2-1.5,3.56l-6.32-1c0.44-2.16 1-3.9 2-5.18 .9-1.3 2.13-2.32 3.7-3 1.6-.75 3.38-1.12 5.35-1.12 3.37,0 6.07,1 8.1,3.22 1.68,1.76 2.5,3.74 2.5,5.96 0,3.14-1.72,5.65-5.15,7.52 2.05,.44 3.7,1.42 4.9,2.95 1.24,1.53 1.86,3.38 1.86,5.54 0,3.14-1.15,5.82-3.44,8.03-2.3,2.2-5.15,3.32-8.57,3.32-3.24,0-5.92-.93-8.06-2.78-2.13-1.87-3.37-4.3-3.7-7.32"/>
, 677 bytes statt 1372. - Die text-Definition dieser "3" sähe etwa so aus:
<text x="160" y="303" style="font-family:Arial;font-size:53px;font-weight:bold;fill:#fff">3</text>
, mit nur mehr kurzen span-Anweisungen für die anderen Ziffern.
- Gelegentlich erstelle ich mal so eine minimierte Variante. Solche Optimierungen sind ein Privatvergnügen, für die Wikipedia ist schon viel getan wenn SVG-Code so gut aufgeräumt ist wie bei deinen Grafiken. Gruss, -- sarang사랑 09:44, 5 November 2011 (UTC)
Da ich insgesamt 168 solche Grafiken erstelle wäre es nützlich wenn du die graue Fano plane noch weiter vereinfachst, so dass ich den Code weiter verwenden kann. Die abgespeckte Version kannst du als File:Fanoperm124.svg hochladen - aber bitte belasse es dabei, dass die Zahlen Pfade sind. In Fanoperm124 kommen keine Pfeile, weil diese Grafik die Permutation darstellt, die nichts verändert. Mit roten Pfeilen würde ich mich an deiner Stelle gar nicht befassen - die sind bei jeder Grafik anders, und da bleibt es nicht bei Drehungen der selben Grundfigur. Lipedia (talk) 12:05, 5 November 2011 (UTC)
- Gut. Ich habe nun das graue Fanoperm124.svg erstellt (wegen der Pfadzahlen ist es recht gross). IMHO ist es zu einfach um unter anderer Lizenz als ineligible zu zu segeln. Du hast da noch was mit der Description, da gehört ein
en|1=
rein. - Wenn du was verschieben willst, musst du nur bei allen drei Pfaden die Anfangskoordinaten "m300,67" entsprechend zu ändern, dann geht es ohne transform. Kann ich dir noch was basteln? Von den roten Pfeilen gibt es nur eine endliche Anzahl, mit wenigen Bögen und Spitzen, die wären auch recht einfach zu zeichnen. Und aus grau schwarz zu machen ist keine Hexerei… -- sarang사랑 16:56, 5 November 2011 (UTC)
Interessanterweise werden die Zahlen in File:Fanoperm124.svg geringfügig verschoben angezeigt. Nur wenn man auf das Bild klickt bekommt man die fehlerfreie Version. In File:Fano plane nimbers.svg besteht das Problem nicht. Da ich bei sowas empfindlich bin misstraue ich deiner Vereinfachung jetzt doch ein wenig.
Übrigens fällt mir auf, dass die Ladezeit der Fanoperms bemerkenswert lang ist. Auch bei File:Fanoperm274.svg mit komplettem Inkscape-Code. Verstehst du, wovon die Ladezeit abhängt? Lipedia (talk) 00:27, 6 November 2011 (UTC)
- Die drei Punkte sind ein typographisches Sonderzeichen, die Ellipse.
- Die Ladezeiten sind manchmal extrem lang, und dann wieder recht kurz, relativ unabhängig vom Code; nur extrem aufwendige SVGs brauchen signifikant mehr Zeit.
- Die Codierung der Zahlen habe ich überprüft, indem ich das gesamte Coding in einer Testversion von Fano plane nimbers.svg auf verschiedene Weise übereinandergelegt habe und so sehen konnte, dass die Zahlzeichen überall und vollständig in beiden Darstellungen kongruent sind; Änderungen prüfe ich immer auf solche Weise, da ist die Deckungsgleichheit bzw. winzigste Unterschiede sehr gut zu erkennen.
- Dennoch erscheinen die Zahlen 6 und 7 etwas aussermittig, obwohl alles exakt übereinstimmt.
- Um vieles schlimmer: bei starker Vergrösserung werden in Fanoperm124 Unsauberkeiten in den "Bäuchen" der Zahlen 2, 3, 5 und 6 erkennbar. Offline gibt es das auch bei stärkster Vergössserung nicht, was das Testen erschwert. Ich finde das einerseits beunruhigend, andrerseits interessant und werde das näher untersuchen.
- Du entwickelst ohnehin ohne Verwendung von Fanoperm124 weiter, somit kann ich mich ohne Stress diesen Problemen widmen. Ich gebe dir Nachricht, wenn es Erfolg gibt. -- sarang사랑 10:12, 6 November 2011 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)