Wikipedia: Problemer med SVG -er

( [xy]="[-0-9.]*)[, ][-0-9., ]*" ⇒ \1"

En annen - men ganske sjelden - årsak (muligens i forbindelse med ChemDraw ) er en oppførsel med horisontalt justert tekst ( middle/end ) med tspan . Disse (bortsett fra de siste) må ikke inneholde noen absolutte x -verdier, ellers blir attributtet text-anchor -anker ignorert ( phab: T97233 - sannsynligvis gjelder det samme for vertikal justert tekst).

Avstanden mellom bokstavene er feil

Alle tekstutdrag bør vises på samme måte

MediaWiki -gjengiveren gjør noen ganger feil ved beregning av bokstavavstand. Dette påvirker spesielt de bokstavsekvensene som det er definert en underskæring i den underliggende skriften ( phab: T36947 ( Bugzilla: 34947 ) ). Jo mindre skrift, jo mer uttalt blir effekten.

Effekten kan forhindres hvis grafiske elementer som og kalles foran -elementet. ^[Eksempel?]

En spesiell variant er å sette inn med et mellomrom i tekstelementet. ^[Eksempel?] Plasseringen av teksten kan også endres. Dette kan korrigeres med dx og dy innenfor .

En annen motgift er i stedet

  font-size = "5px" > Eksempeltekst 

for å angi en større skriftstørrelse mens (individuelt) redusere tekstvisningen samtidig

  transform = "scale (0.1)" >  font-size = "50px" > Eksempeltekst  

skaper en betydelig forbedret plassering av de enkelte glyfene. En verdi> 72 piksler virker optimal her (se grafikk til høyre).

Hvis du laster den tilstøtende testgrafikken direkte inn i en nettleser som kan vise SVG, kan du se at mange nettlesere ikke tar hensyn til kerning -definisjonene og ligaturene fra fontfilene.

• En annen bisarr årsak (enhver form for transform ) som er sterkt nedskalerte grafiske objekter kommer i tvil, som er i kildekoden foran teksten ( phab: T65703 ( Bugzilla: 63703 ) ). Jo mindre objektet er, jo mer uttalt blir effekten.
• For en lignende effekt kan x-, y- -posisjonsinformasjonen som er angitt som en liste for teksttegn også brukes, se avsnittet ovenfor: " #Fonten er flyttet til en annen posisjon ".
• Det har også blitt vist at tspan -elementer med et linjeskift i XML -koden lindrer feilen. ^[r] Så det er ikke tilrådelig å fjerne denne innrykkingen i forhold til SVG (med et rengjøringsmiddel eller lignende).
• Hvis størrelsen er uventet, kan du se avsnittet ovenfor: “ #Hvorfor vises ikke favorittskriften min? "

Merk: " letter-spacing " -egenskapen ^[3] støttes, men ikke av noen moderne nettlesere som Firefox ( Mozilla Bug 371787 ^[4] ) .

Overskrift og subscript tekst

• Inkscape -ikoner
• 
• 

Tekstskifte ved bruk av dy

Grunnlinjeskiftet Sup erscript og Sub -script kjent fra HTML og CSS støttes ikke av rendereren ^[5] og også av nåværende nettlesere som Firefox ^[6] og Internet Explorer 11 ^[7] . Alternativt er det imidlertid i SVG den underliggende bokstaven kerning ved hjelp av vertikal forskyvning via tekstattributtene y ^[8] eller relativt dy . ^[9] Inkscape har også GUI -støtte her ved hjelp av .

  xmlns = "http://www.w3.org/2000/svg" width = "350" height = "160" >
   y = "60" x = "20" style = "font-size: 24px; font-family: sans-serif" >
    Normal tekst  style = "font-size: 65%; baseline-shift: sub" > subscript 
  
   y = "120" x = "20" style = "font-size: 24px; font-family: sans-serif" >
    Normal tekst  dy = "5" style = "font-size: 65%" > abonnement 
  

Her style = "baseline-shift:sub" av en enkel vertikal (relativ) forskyvning dy="5" erstattet. ^[10]

(Merk: Vanligvis kan disse koordinatattributtene inneholde en liste med verdier, men gjengivelsen støtter bare en enkelt verdi, se #Hvorfor flyttes teksten min (forsvunnet) ?. )

Banejustert tekst

• 

  textPath

• 

  Løsningstekst konvertert til baneområder

• 

  Løsning med rett rotert tekst

Det tilsvarende elementet støttes foreløpig ikke ( phab: T11420 ( Bugzilla: 9420 ) ) .

Som en løsning kan du justere de enkelte teksttegnene (f.eks. Automatisk mulig med Adobe Illustrator), eller hvis tekstbanen er en rett linje, kan teksten også plasseres / roteres normalt ved hjelp av transform . Den siste, men tilstrekkelige måten er å konvertere selve teksten til baner (som imidlertid har en rekke ulemper).

Hvorfor har bildet mitt fine linjer gjennom banen?

Selv om to bane noder er nøyaktig på samme sted, vises en kolonne ( hårfeste , men også i noen nåværende nettlesere phab: T20936 ( Bugzilla: 18936 ) ) i gjengivelsen (i visse oppløsninger). I Inkscape er det en funksjon ‹Path› - ‹Union› ( Ctrl + + ), som kombinerer de overlagrede nodene til en node. Selv om to objekter overlapper hverandre, kan denne effekten oppstå så snart området i den skalerte gjengivelsen faller under 1 piksler.

Firkantene er helt ved siden av hverandre.

Samme bilde 1 px større.

Merk: Det ser ut til at feilen har blitt svekket etter en oppdatering, slik at den bare oppstår med merkelige oppløsninger.

Hvorfor vises ikke SVG -en min?

Du har sannsynligvis glemt referansen til en bitmap -grafikk i SVG. Rendereren liker ikke disse i det hele tatt, de må fjernes, det vil si ikke bare usynlig. Så hvis du sporer en pikselgrafikk eller bruker den som referanse, må du alltid huske å slette den fra SVG før du laster den opp.

Jeg innebygde en bitmap -grafikk direkte, men det fungerer fortsatt ikke

I motsetning til referanser ( se forrige spørsmål ), innebærer innebygging at koden for bitmap -grafikken lagres direkte i SVG -filen. Dessverre er dette heller ingen garanti for at filen vil vises riktig. Følgende feilkilder er mulige (sannsynligvis ikke en fullstendig liste):

1. Det integrerte bitmapet er en JPEG -fil. Rendereren kan bare vise PNG -filer.
2. Bare for grafikk som er opprettet i Inkscape: Hvis du endrer høyde-til-bredde-forholdet til et bitmap, lagrer Inkscape det på en måte som er ikke-standard. Andre gjengivere som fungerer korrekt, kan derfor vise det forvrengte bildet. For å unngå at det oppstår en feil, er det første du må gjøre etter at du har lagt inn bitmappen, å bruke Object → Group -kommandoen, og bare flytte og skalere denne gruppen.

Kan jeg kontrollere presentasjonen med CSS?

Systematisk test av ulike CSS -metoder

Selv om oppføring av style i objekter og grupper er en sentral mekanisme for visning av SVG -er, bør bruk av innebygd CSS i begynnelsen av dokumentet behandles med forsiktighet. For eksempel, gjør Mediawiki renderer støtter CSS barn velgere (barn velger - Phab: T43423 ( Bugzilla: 41423 )).

Hvis gjengivelsen fungerer korrekt, skal alle eksemplene i illustrasjonen til høyre se like ut (dvs. seks røde sirkler, seks blå firkanter og teksten i samme stil).

[Muligens. ytterligere eksempler er passende her, siden eksemplet til slutt bare viser en feil]

Merk: Siden libRSVG 2,36, den style - må element inneholde en type="text/css" notasjon, i motsetning til anbefalingen fra W3C uttrykkelig gitt som "valgfri" ( Phab: T68672 ).

Hvordan kan jeg angi bakgrunnsfargen?

SVG har verken bakgrunn eller bakgrunnsfarge som en egenskap for grafikken (i motsetning til CSS i HTML, gjelder det samme for tekst). En farget, ugjennomsiktig bakgrunn oppnås derfor med SVG med et farget rektangel på størrelse med grafikken.

  width = "100%" height = "100%" fill = "# A8F" />

Merk: Ved hjelp av det elektroniske verktøyet " in [k] firmary " (fra bruker: Connum ) kan blant annet en bakgrunnsfarge valgfritt settes automatisk.

Et redusert forhåndsvisningsbilde ser helt annerledes ut enn det opprinnelige bildet (halvfiksert)

Den renderer har problemer med å produsere skalert forhåndsvise bilder ved bruk av filterfunksjoner, for eksempel B. med et visst mykt fokus. Så z. For eksempel kan bredden og posisjonen til GaussianBlur -filtre ( feGaussianBlur ) variere betydelig med størrelsen på forhåndsvisningsbildet i PNG, eller filterfunksjonen utføres ikke lenger for små miniatyrbilder. For eksempel vises den samme SVG -filen fem ganger i det følgende galleriet, hver med en annen gjengivelsesoppløsning. Hvis gjengivelsen er feil, vil bildet bare vises riktig fra en oppløsning på 50 piksler eller mer.

46 piksler	48 piksler	60 piksler	80 piksler	100 piksler

Totalt sett bør bruken av filterfunksjoner gjøres veldig nøye. Det skal alltid huskes at når SVG -er vises direkte i nettleseren, kan det oppstå ytterligere feil, siden ikke alle disse kan vises i det hele tatt.

Merk: Feilen oppstår hovedsakelig med en lav verdi (hvis resultatet er under en piksel, er Gnome Bug 605875 , redigert i libRSVG 2.40.9, oppdatering av MediaWiki -gjengivelsen nødvendig [2] )

Hvorfor vises ikke fyllmønsteret mitt riktig?

Dessverre er renderer bare i stand til å reprodusere fyll mønstre riktig i begrenset grad (spesielt i skalering, Phab: T20463 ).

Tips som alternativ : Lag bare et "hovedmønster", og multipliser det deretter med kloning til det dekker hele overflaten av objektet som skal mønstres. Bruk deretter silhuetten til objektet som en klippebane.

Som en ytterligere løsning for avanserte brukere: Det er følgende mulighet. Hvis du plasserer mønsteret igjen i et annet mønster (en enkel firkant er tilstrekkelig) har du vanligvis ønsket resultat (erfaringer kan videreformidles her på diskusjonssiden) .

Hvis mønstre har forsvunnet helt etter gjentatt bruk (av samme mønster), er en mulig årsak en forstyrrelse av definisjonen (defs element). Dette betyr at redaktøren internt lager kloner av mønstrene som brukes (bare med endrede posisjoner) og at disse kan ha blitt plassert foran originalen i dokumenttreet (noe som ikke er fint, men heller ikke er et brudd). MediaWiki -gjengivelsen kan ikke håndtere dette faktum, så fiksen er å sette klonen i dokumentet etter originalen . Eksempelfil : Grundriss Burg Hageneck.svg (ingen feilrapport ennå funnet)

slag-dasharray

phab: T32033 : Filen: EKG-Reto 001.svg viser et fyllmønster med stroke-dasharray feil som hele linjer (litt færre, jo større forhåndsvisningsstørrelse).

• 

  EKG-Reto 001.svg bruker mellomrom som separatorer (støttes ikke)

• 

  EKG-Reto 001 BugSolved.svg bruker komma som separator ( løsning )

RegExp -erstatning (med bare 2 verdier):

• stroke-dasharray="(\d*\.?\d*) (\d*\.?\d*)" ⇒ stroke-dasharray="\1,\2"

animasjon

SVG -animasjoner støttes ikke av wiki -gjengivelsen, men de kan gjøres tilgjengelige for nettlesere med en direkte lenke.

Eksempler: commons: Kategori: Animert SVG

Rettet feil

Markør (fast)

For diagrammer (skisser, grafer og flytskjema-lignende) brukes ofte såkalte markeringssymboler som piler med markørelement . MediaWiki -gjengivelsen forstår dette ganske godt. Imidlertid, med unntak av den sentrale markøren, den såkalte marker-mid i forbindelse med orient="auto" . Gjengivelsen av ytterligere elementer i grafikken kan fullstendig avbrytes her ( phab: T117530 ).

Piler (markeringer) er vridd (fast)

Feil versjon i versjonshistorikken

Her er det en tvetydig særegenhet med såkalte kubiske Bezier- kurver . ^[11] Hvis disse er "ufullstendige" (også for "nesten" rette linjer, se eksempel ), er de ikke justert i henhold til baneretningen (men forblir i sin "normale posisjon").

Årsaken er at med kubiske Bezier -kurver må det siste koordinatpunktet (sluttpunktet) tilsynelatende avvike fra det nest siste for å kunne bestemme en retning (for markøren). Nå kan du enkelt endre koordinatpunktet ved hjelp av et tekstredigeringsprogram, men det er sannsynligvis lettere å sette det på nytt ved hjelp av en GUI -editor (i Inkscape ved å bruke F2 ). Dette kan gjenkjennes ved at lysbuehåndtaket ( kontrollpunktet ) mangler på den aktuelle noden, så dette kan stilles inn ved å holde nede Shift -tasten (og musen). (Dette er grunnen til at feilen også kan løftes hvis du roterer / speiler et speil / punkt symmetrisk bane og bruker en speilet markør uten å faktisk endre banedata.)

En annen mulig årsak kan være noder som er nær hverandre (derfor ikke åpenbare).

Merk:

Feilen er løst fra og med librsvg-2.40.10 ( GNOME Bug # 476507 ) Det faktum at Firefox og Inkscape tolker slik kode (på en måte) etterlater det faktum at W3C-spesifikasjonen og samsvar er unøyaktige.

Foreløpig forekommer denne oppførselen fortsatt i Chrome (65).

info

Info: Med oppdateringen av 24. oktober i 2012 (Server Update på Ubuntu 12.04) servere som er ansvarlig for å lage miniatyrbildene var (ImageScaler), konvertert til tilsvarende oppdaterte programmet librsvg (02:36). På den ene siden bør dette fikse noen feil, på den andre siden kan det også føre til nye feil. Derfor må listen oppdateres om nødvendig (e -postliste for wikitech : New Imagescaler disto / pakker ) Merk: Eventuelle feil som er fjernet kan vises i versjonen datert 24. oktober 2012 .

Se også

Commons : Hjelp: SVG / de - detaljert tyskspråklig introduksjon til SVG

Meta -Wiki : SVG image support - MetaWiki (engelsk historisk informasjon)

Individuelle bevis

1. ^ W3C -anbefaling (7. juni 2011):Fontfamilie: egenskapen 'font -family' (CSS 2.1) Spesifikasjon - Skrifter
2. ↑ Flytende tekst og grafikk , W3 SVG1.2 Draft
3. ^ W3C SVG Tekst: Avstandsegenskaper - bokstavavstand
4. ↑ SVG i Firefox: Element implementeringsstatus
5. ↑ Phab: T7792 ( Bugzilla: 5792 )
6. ↑ Mozilla Bug 308338
7. ↑ msdn.microsoft
8. ↑ http://www.w3.org/TR/SVG/text.html#TextElementYAttribute - tilsvarer y -koordinat i translation
9. ↑ http://www.w3.org/TR/SVG/text.html#TextElementDYAttribute
10. ^ De 5 pikslene i eksemplet avrundes ved å beregne skrifthøyden * 33% , dvs. 24 px * 65% * 33% = 5.148 px
11. ↑ SVG -opplæring 10.4 C og c - Cubic Bezier Curves

.