Diskussion:SVG

Stil

Überlegungen zum einheitlichen Stil sowie Sammlung von buchinternen Vorlagen finden sich auf SVG/ Stil (konstruktive Diskussionen darüber sind wie immer herzlich willkommen) --Neo@NHNG 12:56, 15. Nov. 2008 (CET)

Vorschläge für Ergänzungen

Jeder der will kann Ideen einbringen und oder umsetzen. Sofern nicht selbst umgesetzt, sollten die Ideen aber wenigsten so ausführlich erläutert sein, daß ein williger Autor das dann auch umsetzen kann.

• w:XSLT (Beispiel ist bei den Stilvorlagen angegeben, mehr wäre ein größerer Exkurs, vielleicht auch besser im Buch über XSL untergebracht)
• programmieren in SVGs (Java, ecma-script, java-script, tcl, php, perl - auch jeweils wohl ein größerer Exkurs)
• neuere Entwicklungen (eine Liste aktueller Arbeitsentwürfe? Weil sich das ab und an ändert, erfordert solch ein Abschnitt etwa bei der Literaturliste natürlich dauerhafte Wartung)
• Internationalisierung (entsprechende Attribute und Eigenschaften sind diskutiert - noch mehr? Wenn ja, was?)
• Cocon (Apache)
• Fehlerquellen (genauere Angaben wären da sinnvoll, damit das jemand schreiben kann - Fehlerquellen für browser und Autoren gibt es reichlich, teils auch bereits erläutert)
• SVG Mobil http://greensspirit.blogspot.com/2009/08/tune-your-mobile-svg-user-interface.html
• SVG-Effekte in HTML anwenden (ist derzeit nicht spezifiziert und allenfalls in der experimentellen Phase, etwas früh für ein Buch darüber)
• Mehr Anwendungsbeispiele, hinreichend kompakt mit gut strukturiertem und beschriebenem Quelltext

direkter Zugriff?

Hallo,
ich weiß nicht, ob es auch als Referenzhandbuch geplant ist, aber wenn ja, dann wäre es geschickt wenn man auf die Tag-Beschreibungen direkt nach folgendem Schema zugreifen könnte:

http://de.wikibooks.org/wiki/SVG/<TAGNAME>

Beispiele:

http://de.wikibooks.org/wiki/SVG/path
http://de.wikibooks.org/wiki/SVG/text
http://de.wikibooks.org/wiki/SVG/span
http://de.wikibooks.org/wiki/SVG/g

Viele Grüße --Marsupilami 23:02, 12. Aug. 2009 (CEST)

Bis jetzt sollten die Referenzen einfach zu dem Punkt springen an denen sie im Buch eingeführt werden, aber eigentlich eine gute Idee wenn es zuerst auf eine Tabelle geht in der mögliche Attribute beschrieben werden, Kindelemente usw. Das müsste man eigentlich halbautomatisch aus einem RelaxNG generieren können. --FischX 09:29, 13. Aug. 2009 (CEST)

Korrekturwerte

Vollfläche	Rahmen

Die Materialien hier habe ich sehr hilfreich gefunden, mir totalem Neuling ist vieles gut erklärt worden. Zu einer Sache habe ich allerdings nichts finden können, weder eine kurzen allgemeinen Hinweis, noch eine genauere Beschreibung: bei den Elementen mit "stroke-width" geben die Koordinaten nicht (wie bei den vollen Flächen) die Außenabmessungen – diese werden immer um die stroke-width größer. Ist ja logisch, aber von Anfängern nicht unbedingt so erwartet.

Je nach dem Wert der stroke-width ist das meist nicht mehr vernachlässigbar, und je nach der Form und der Lage sind Korrekturwerte zu verwenden.

In File:DifferencesSVG.svg habe ich mal zusammengestellt, welche Werte bei einigen Standardformen anzusetzen sind, um deckungsgleiche Flächen zu erhalten. Selbstverständlich ist je nach der Seite um den Korrekturwert zu erhöhen (oben und links) oder zu vermindern (unten und rechts). Die Korrekturwerte in der Tabelle lassen sich mit trigonometrischen Basiskenntnissen ermitteln, ich hoffe, dass mir kein Fehler unterlaufen ist.

Und nun meine Frage: Ist das von irgendeinem allgemeinen Interesse, hier oder sonstwo? Falls ja: wo gehört das hin? sarang♥사랑 17:19, 24. Feb. 2010 (CET)

Mir ist nicht ganz klar, was oder wieso da was zu korrigieren ist (Präzisere Wortwahl? Motivation, Anwendung darstellen?). Der Strich wird mittig auf den Pfad gesetzt, das ist alles. Will man das derzeit anders haben, gibt es verschiedene mehr oder weniger elegante Methoden der Maskierung. Sofern keine Transparenz vorliegt, kann man z.B. die Form nochmal ohne Strich drüberlegen und verdeckt dann damit den Teil des Striches, der innen liegt. Wählt man die Farbe von Strich und Füllung gleich, so hat man die umhüllende Form. Durch das Vertauschen von innen und außen kann man auch einen umgekehrten Effekt hinbekommen, bei dem nur der Strich zu sehen ist, der in der Form liegt. Mit clip und mask läßt sich auch nur ein beliebiger Teil des Striches senkrecht zum Pfadverlauf darstellen. Das habe ich auf einer meiner Anleitungsseiten stehen, könnte ich natürlich mal bei Gelegenheit auch hier näher ausführen... Das einzeln auszurechnen ist ja bei beliebigen Kurven vielleicht ein sportlicher Zeitvertreib, aber nichts, von dem ich vermuten würde, das viele das tun wollen, wenn es auch eleganter ohne Rechnerei geht ;o) Jedenfalls gehört der Strich selbst nicht zur Fläche, letztere liegt immer innerhalb des Pfades. Im allgemeinen ergibt die Umhüllende des Striches auch eine andere Form als die des Pfades, kann man deutlich bei Ellipsen sehen. Jedenfalls je nachdem, welche Technik man anwendet, kann das in verschiedene Abschnitte passen, sofern man neue Pfade berechnet, kann das ins Kaptiel zu path passen, verwendet man clip oder mask oder Filter in die entsprechenden Kapitel, bei einer allgemeinen Anwendung, die nicht einem bestimmten Element, einem Attribut oder Eigenschaft zuzuordnen ist, könnte man das Kapitel 'weitere Elemente' in sowas wie 'Anwendungen und Beispiele' umbenennen und das dort unterbringen (das Kapitel ist bislang sowieso nur ein Provisorium für Dinge, die entweder noch keine eigene Seite haben oder bislang nicht direkt in andere Abschnitte passen). – Doktorchen 11:17, 5. Mär. 2010 (CET)

Mit „Korrekturwert“ meine ich: wenn ich zu einer Vollflächenform, z.B. einem gleichseitigen Dreieck mit den drei Koordinatenpaaren 100 0, 200 174, 0 174 den Rahmen der Form mit denselben Außenmaßen zeichnen will, lassen sich die Koordinaten dafür nach einem bestimmten Schema ermitteln. In diesem Fall sind sie bei einer stroke-width von 40 nach meiner Tabelle 100 40, 165.36 154, 34.64 154. Für einige häufig vorkommende Standardformen hatte ich diese Korrekturen zu den Koordinatenwerten benötigt und deshalb zusammengestellt. -- sarang♥사랑 15:16, 5. Mär. 2010 (CET)

Ja, bei einfach Polygonen oder Linienzügen ist das einfache Rechnerei. Bei abgerundeten oder abgeschnittenen Ecken kann das etwas aufwendiger werden, den korrekten Pfad anzugeben, habe ich allerdings bei der entsprechenden Eigenschaft beschrieben und mit einem Beispiel verziert. Die Beschreibung der Eigenschaft hier ist in der Hinsicht zumindest schonmal deutlich hilfreicher als die bloß zeichnerische Darstellung in den Spezifikationen ;o) Zur Gehrung habe ich ja auch Formeln angegeben. Bei gekrümmten Kurvensegmenten ist das nicht ganz so einfach, die umhüllende Kurve explizit anzugeben. Mit elementarer Herumrechnerei (Grundkenntnisse in Analysis und linearer Algebra) kann man da immer eine Funktion ausrechnen, die diese Kurve beschreibt, ich vermute allerdings mal stark, daß man die zur konkreten Darstellung oft nur mit kubischen Pfaden approximieren kann (habe allerdings nicht nachgerechnet, ob es sich nicht vielleicht doch wieder um kubische Pfade handelt, wenn der Ausgangspfad ein kubischer ist). Spannend wird das Thema auch, wenn man einen Strich mit variabler Dicke simulieren will, zum dem Zwecke muß man, wie Inkscape das wohl auch macht, von dem Pfad ausgehend die resultierende Umhüllende wieder als neuen Pfad berechnen, gegebenenfalls approximieren. Wenn mir jetzt konkret ein Anwendungsbeispiel vorläge, wofür man explizit einen Pfad für die Einhüllende braucht, könnte ich mich da schon mal ein paar Tage hinsetzen, allgemeine Formeln herleiten, die einem wohlmöglich weiterhelfen oder die man in ein Programm oder Skript stecken kann, um das zu automatisieren. Ich vermute mal, wichtig wird das eigentlich erst, wenn man diese umhüllende Fläche einheitlich teiltransparent darstellen will, ohne die Eigenschaft opacity zu verwenden (geht etwa in SVG tiny 1.2 nicht). In dem Falle läßt sich die Rechnerei nicht vermeiden. Fallen dir noch andere Situationen ein, wo man das wirklich explizit braucht (statt also einfach fill und stroke auf dieselbe Farbe zu setzen und gegebenenfalls opacity zu verwenden)? Dann stellt sich natürlich auch die Frage, reicht es, einen Pfad anzugeben, der die Fläche samt Strich umschließt oder braucht man wirklich exakt den einhüllenden Pfad? Da sich der Strich oft selbst überschneidet, kann der mehr oder andere Knicke aufweisen als der Originalpfad ohne Strich. Ich kann mir vorstellen, daß erstere Lösung bei Selbstsüberschneidungen hinsichtlich der fill-rule interessant werden könnte.

Schon für <rect width="100" height="100" stroke-linejoin="round" stroke-width="30" /> muß man etwas nachdenken, ebenso für <rect width="100" height="100" rx="20" ry="60" stroke-width="40" />. Bereits spannend wird es dann mit <ellipse rx="100" ry="40" stroke-width="38" /> und richtig lustig wird es mit <ellipse rx="100" ry="40" stroke-width="250" /> - was auch bei einigen Darstellungsprogrammen bereits Probleme bereitet ;o) Doktorchen 13:40, 6. Mär. 2010 (CET)

Naja, so weit bin ich noch lange nicht...

Mir ging es konkret um ganz einfache Formen, für die es sich anbietet, sie "zufuß" zu erstellen, denn was manuell ganz nett und übersichtlich bleibt, wird von Tools (inkscape &Co) zu wüsten Dasteien aufgebläht. Und wenn es so wie bei dem ersten Beispiel (File:U+25A0.svg und File:U+25A0.svg) darum geht, regelmäßige Dreiecke und ähnliches mit kongruenten Außenabmessungen zu zeichnen, helfen die einfachen Formeln.

Dass es immer komplexer wird, wenn die Formen anspruchsvoller werden, ist evident; aber mich daran zu wagen habe ich erstmal nicht vor. Danke für die ausführliche Diskussion! -- sarang♥사랑 15:36, 6. Mär. 2010 (CET)

SVG als Band im Buch Websiteentwicklung

Ich plädiere dafür SVG in das Buch Websiteentwicklung aufzunehmen. Ist eine nachträgliche Verschiebung möglich? Wer entscheidet das (der Autor/die Gemeinschaft)? --Feeela 16:25, 13. Okt. 2011 (CEST)

Mal abgesehen von dem unmöglichen denglischen Begriff 'Websiteentwicklung' kann man das da sicher listen. Umbenennen des Titels halte ich jedenfalls für schlecht, schon wegen des denglischen Begriffes, der schon bei den anderen Büchern eher peinlich und demotivierend ist. Das braucht man bei SVG nicht auch noch ;o) Von daher sollten Umbenennungen des Titels schon sorgfältig diskutiert sein. Sonst hätte ich da die starke Tendenz, auch anderweitig kräftig bei Titeln derartiger Bücher aufzuräumen ;o) Doktorchen 16:43, 13. Okt. 2011 (CEST)

Wie fertig ...

... ist das Buch? Eigentlich ist das ja der Kandidat für den Buchkatalog, wenn nicht für mehr. Nur, die Rechtschreibung wechselt ständig zwischen aktueller und alter. Wenn's die aktuelle sein soll, würd' ich mich da gerne ranmachen. Kurze Antwort reicht mir ;-) --92.196.49.188 14:56, 14. Aug. 2013 (CEST) Z.B. die vorherrschenden "dass" sprechen wohl klar für die aktuelle Rechtschreibung. --92.196.49.188 17:17, 14. Aug. 2013 (CEST)

Da ist schon mal ein Programm durchgelaufen, mit welchem das konvertiert wurde - muß aber zum einen nicht alles erwischt haben, da ich aber als Hauptautor außerhalb von wikibooks immer 'daß' etc verwende, kommt 'daß' schon ab und an mal bei Ergänzungen vor, wenn es mir nicht auffällt - ich war schon damals nicht davon überzeugt, daß es wirklich ein Fortschritt ist zu konvertieren, aber wer mag, kann das ja tun ...

Hinsichtlich der 'Fertigkeit' denke ich: Beispiele und Anwendungen kann man immer mal ergänzen. Die Angaben zu den Darstellungsprogrammen sind einerseits natürlich recht hilfreich, aber eigentlich auch ein steter Quell der neuen Arbeit. SVG 2 wird auch noch eine Weile dauern - von daher sind da ansonsten größere Ergänzungen wohl erstmal nicht notwendig ...

Doktorchen 19:53, 14. Aug. 2013 (CEST)

Hilfe erbeten

	੭ ੧੨ ੧ ੧੪ ੨ ੧੩ ੮ ੧੧ ੧੬ ੩ ੧० ੫ ੯ ੬ ੧੫ ੪ ISO 15924: Guru ٧ ١٢ ١ ١٤ ٢ ١٣ ٨ ١٠ ١٦ ٣ ١٠ ٥ ٩ ٦ ١٥ ٤ ISO 15924: Arab 7 12 1 14 2 13 8 11 16 3 10 5 9 6 15 4 ISO 15924: Latn transcription of the indian numerals
most-perfect magic square from the Parshvanath Jain temple in Khajuraho, Rajasthan

c:file:This users contributes BiDi 03.jpg
vom 2 November 2007

c:file:rakonto 09 deu.ogg ^{auf Deutsch}
 : commons:rakonto
 : → #Media (examples)

Liebe Freunde! Die Datei SVGwriting-mode01.svgwurde durch Benutzer:Doktorchen im November 2009 erstellt.
Meine SVG Erfahrung ist sehr, sehr begrenzt. Z.Z. Arbeite ich an der Erstellung von SVG Dateien zu den w:de:vollkommen perfektes magischen Quadraten.

Unter testwiki:most-perfect magic square erstelle ich die Nummerkonvertierung für ein Dutzend ISO 15924 Schriften wie 'Arab · Armn · Beng · Cyrl · Cyrs · Deva · Grek · Gujr · Guru · Hans · Hant · Jpan · Hebr · Knda · Kore · Latn ^{ieinschließlich römischer Zahlen un Binärkodierung} · Lepc · Maya · Mlym · Mymr · Orya · Runr · Sinh · Taml · Telu · Tibt · Xsux. Weitere werden eventuell hinzugefügt und könnenn am Seitenanfang von testwiki:most-perfect magic square# gefunden werden..
Der Kern der Arbeit ist die Internationalisierung des als Chautisa Yantra bekannten Quadrats, welches sinnvollerweise als "Khajuraho Quadrat" bezeichnet werden sollte.

Konkrete Bitte: Kann jemand eine Beispiel SVG-Datei nach dem JPG-Vorbild erstellen, in dem der englischer Text beibehalten wird und welches ähnlich wie c:file:Abstrakt.svg strukturiert und kommentiert ist.
Benutzer, die sich an der Zusammenstellung der Beispiele (Wahl der font-family, font's, Zeichensatzgröße u.a.) beteiligen möchen, bitte ich, sich bei testwiki:most-perfect magic square#participants einzutragen.

Geplant ist die Verwendung von für die Internationalisierung erforderlichen spezifischen Parameter wie "unicode-range". class="nowrap" wird bereits verwendet um den Umruch breiterer zwei- und / oder mehrstelliger Zeichensequenzen zu unterbinden. Beispiele dafür befinden sich (wenn auch noch nicht in optimierter Form bei Grek, Hans · Hant · Jpan · Hebr · Latn ^{römische Zahlen bzw. Binärkodierung}. Diese Beispiele können fallweise in veränderter Form im Gesamtwerk mitverwendet werden.

Für jede Art von Unterstützung bedanke ich mich im Voraus. Herzliche Grüße lɛʁi ʁɑjnhɑʁt (Leri Reinhart)
‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 10:39, 16. Aug. 2015 (CEST)

P.S. In einem weiteren Schritt sollen Animationen zu den Transformationen der Quadrate erstellt werden. Eine englischsprachige "road map" befindet sich unter testwiki:most-perfect_magic_square/invited#invitatiion_text.

P.P.S. Bitte die wiki-Syntax nicht verändern, da der code durch einfaches Kopieren und Einfügen auch auf weitete wikis eingefügt werden kann. Die Korrektur von Tippfehlern/Schreibfehlern und die Übersetzung der "englischsprachigen Textschnipsel" ist herzlich willkommen. Danke!

PAGEID: 28354 · https://de.wikibooks.org/?pageid=28354

links here: https://de.wikibooks.org/?curid=28354#multiscript_collaboration

REVISIONID: 805754

hinzugefügt ‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 18:28, 18. Aug. 2015 (CEST)

Hinsichtlich der Testdatei zu den Schreibrichtungen: Ob sowas korrekt interpretiert wird oder nicht, hängt natürlich stark vom verwendeten Darstellungsprogramm ab. Bei den üblichen Verdächtigen und aktuellen Versionen darf man da sicher mit Problemen rechnen, auch das leistungsfähigste gängige Darstellungsprogramm Opera/Presto hatte da noch Probleme. Opera ist inzwischen ja zu WebKit/Blink gewechselt, daher darf man auch bei Opera mit mehr Problemen rechnen, als bei den älteren Presto-Versionen.

Leider ist die Interpretation von SVG-Schriften (die man direkt in die SVG-Datei einbetten kann), bei aktuellen Programmen meist entweder gar nicht vorhanden oder mangelhaft, eine korrekte Darstellung von Glyphen weniger gängiger Schriftsysteme ist also mehr oder weniger davon abhängig, ob dafür Schriftarten auf dem Rechner des Nutzers verfügbar sind.

Alternativ bleibt einem allerdings, Glyphen als einfache Pfade abzuspeichern und die Textinformation dann als zusätzliche Metainformation anzugeben.

Ob Pfad oder Text, die mangelhafte Interpretation von tref kann man natürlich umgehen, indem man das Element use verwendet oder aber auch Entitäten im internen Teil der DTD definiert, wie man dann in der Datei vewenden kann. Zumindest für einfache Anwendungen sind das meist ein brauche Ausweichmöglichkeiten.

Ansonsten verstehe ich noch nicht so recht, was jetzt eigentlich konkret gemacht werden soll, diese Quadrate sehen ja sehr einfach aus. Im Kapitel über Pfade gibt es ja etwa auch ein Beispiel für ein Sudoku-Feld. Die Positionierung von Glyphen findet man im Kapitel Text als Graphik und im Kapitel Graphiken formatieren. Wenn ich die Unicodes der Glyphen bekomme, kann ich solch ein Quadrat natürlich erstellen, dann kann man sehen, wie man das am besten umsetzt und ob es besondere Probleme mit den Glyphen auf typischen Betriebssystemen gibt.

Sind die Glyphen nicht das Problem und man will nur die üblichen Ziffern verwenden, gibt es bei der Ausrichtung allenfalls das prinzipielle Probleme, daß man vertikales Zentrieren schätzen muß, ebenso, sofern man keine SVG-Schrift verwendet, die Größe der Glyphen, was aber meist unproblematisch ist, wenn man das umgebende Quadrat hinreichend groß macht.

Es bietet sich natürlich an, das mit Skripten (PHP) erstellen zu lassen, dann kann man zügig Größe und Inhalt solcher Quadratstrukturen ändern - die Ergebnisse lassen sich dann ja einfach statisch abspeichern. Ich gucke mir die wikipedia-Seite mal an und schaue mal, was ich davon verstehe ;o)

Ansonsten bin ich derzeit in Urlaub, kann also ein paar Tage dauern, bis ich mal wieder reinschaue. Doktorchen 11:46, 18. Aug. 2015 (CEST)

Herzlichen Dank Doktorchen für die ausführliche Hilfe und beste Wünsche für einen erholsammen und entspannten Urlaub. Hoffentlich können wir danach über IRC, Skype oder Telefon zuerst die umsetzbaren Ideen ansprechen. Da die maximale Größe von testwiki:most-perfect magic square bei 203.030 Bytes lag, werde ich die einzelnen Schriftrelevanten Blocks als Unterseiten deffinieren ^{/Guru · /Latn · /Arab}.

Neu ist die Verwendung von LANG="en" sowie LANG="ar" und LANG="pa"&nbsp>^??? und schrittweise weitere Optimierungen. Gruß aus München ‫·‏לערי ריינהארט‏·‏T‏·‏m‏:‏Th‏·‏T‏·‏email me‏·‏‬ 18:28, 18. Aug. 2015 (CEST)

Wenn ich das mit Unicode richtig verstanden habe, beinhaltet das ohnehin meistens Informationen zur Schreibrichtung, wenn man die nicht gezielt anders haben will als normaerweise für die Glyphen sinnvoll, sollten also derartige Attribute gar nicht relevant sein.

Ein paar kleine Beispiele habe ich inzwischen erstellt.

Die Farbkodierung in den Beispielen scheint mir nicht sonderlich wichtig zu sein, habe ich erst einmal ignoriert. Wenn man die Farben auf die Glyphen beschränkt, läßt sich das aber leicht ausbauen.

Die Regeln, die für reversible Varianten gelten, habe ich nicht verstanden. Ein Verständnis scheint mir da aber auch nur notwendig zu sein, um die Zellen mit passenden Zahlen zu füllen, daher wohl nicht so wichtig.

Ich habe erst einmal nur ein paar simple Beispiele zusammengebastelt, wie man durch Transformationen und Wiederverwendungen das alles etwas besser strukturiert, was aber auch ein gutes Stück Geschmacksache ist. Allerdings kann man so natürlich die Koordinatensysteme so wählen, daß man einfach durchschaubare Zahlen für die Glyphenpositionen und das Gitternetz bekommt und man dann nur eine Transformation für das Gitternetz braucht, um es für die Zentrierung passend zu verschieben.

Beispiele für Animationen habe ich auch erstellt. Will man allerdings Spalten und Zeilen in einem Dokument zyklisch permutieren oder gar noch abwechselnd Spalten und Zeilen, so muß man da schon etwas länger drüber nachdenken, wie man das effektiv umsetzt, eventuell erzeugt man dann mit einem Skript (PHP etwa) die values-Listen der Animationselemente, das geht dann zügiger, als alles per Hand einzutippen.

Die Beispiele sind recht einfach, lohnt also wohl nicht, die hier auf Dauer hochzuladen, daher habe ich die provisorisch auf meiner Seite abgelegt:

http://hoffmann.bplaced.net/svgueb/mq/

Ist das jetzt in irgendeiner Weise hilfreich? Konkrete andere Wünsche für Beispiele? Doktorchen 12:44, 23. Aug. 2015 (CEST)