Wikipedia: Problemer med SVG -er

fra Wikipedia, den frie encyklopedi
Hopp til navigasjon Hopp til søk
Ofte stilte spørsmål om SVG -opprettelse for Wikipedia

Det er noen få problemer med å lage SVG -filer . Disse skyldes hovedsakelig det faktum at SVG -filene konverteres for visning. Noen av problemene og løsningene deres er vist nedenfor.

Hvis du har et spørsmål om SVG -grafikk som ennå ikke er oppført her, kan du kontakte WikiProjekt SVG eller Wikipedia: Graphics workshop . Detaljerte forklaringer på SVG -filer er også tilgjengelige på hjelpesiden i Commons . Generelle spørsmål om Inkscape besvares også i Vanlige spørsmål om Inkscape.

Nye svar kan legges inn via denne lenken .

Forkortelse : WP: PMS

i Nåværende : Siden 2016 har tekst i SVG bare blitt vist med riktig tegnavstand i svært begrenset omfang . Bugfabben: T36947 har alltid eksistert, men ikke så ekstrem. Du finner en løsning ( løsning ) i følgende seksjon:

#Avstanden mellom bokstavene er feil
Qsicon Advarsel Orange.svg
For en mer detaljert kontroll av displayet og gyldigheten, kan SVG testes med SVG Check før du laster opp (mer om dette på Commons: SVG Check ).
Hvis du ikke er sikker (f.eks. SVG -kontroll dekker ikke alle fonter og oppløsninger) og først vil se hvordan libRSVG faktisk vil gjengi filen, last den opp til File: Test.svg .
Merk: Enhver SVG -fil lastet opp til Wikimedia Commons skal vise:
  • Hvordan den ble opprettet: Bruk maler som {{ Inkscape }} , {{ Adobe }} , {{ HandSVG }} eller hva som helst .
    Filer som er opprettet med Inkscape eller Adobe Illustrator, bør lagres som "normal" (eller "optimalisert") SVG før de lastes opp (dette unngår noen mindre feil).
  • Enten det er W3C -valid eller -invalid: angi riktig parameter for malen, f.eks. B. {{Inkscape|v}} .
    For å gjøre dette, bør filen sjekkes med W3C -validatoren (et testverktøy for blant annet SVG).

Hvorfor er det noen problemer i det hele tatt?

MediaWiki viser ikke SVG -filer direkte, men konverterer dem i stedet til PNG -filer når de er integrert på en side. Årsaken til dette var opprinnelig at noen nettlesere ikke kunne vise eller skalere SVG -filer direkte, men i dag er årsakene faktisk mer komplekse, se phab: SVG -klientsidegjengivelse (T5593) . For SVG-rendering, en tilpasset og begrenset, noen ganger buggy versjon av libRSVG programmet er bibliotek brukes (som ble opprinnelig bare ment for ikoner). Eye of Gnome image viewer bruker også libRSVG, og alle som er i stand til å installere dette programmet, som er utbredt under Linux med riktig libRSVG -versjon, kan bruke det til å bestemme før du laster opp alt som vises feil ( mer om dette på WP: SVG # Testfiler hjemme ).

tekst

Hvorfor vises ikke ønsket skrift?

Alle installerte fonter

Det er viktig for gjengivelsen at skriftene den skal vise også er installert på serveren. En liste over fonter som kan brukes til Wikimedia -sider finnes under meta: SVG -fonter .

Dessverre kan ikke gjengiveren behandle direkte innebygging av skriftdefinisjoner som SVG -fonter. Hvis du virkelig vil vise andre fonter, har du ikke annet valg enn å konvertere dem til baner. Se også: WP: SVG # fonter i ekstraherte vektordata .

Det bør også bemerkes at de installerte skriftene ikke er jevnt utjevnet og skalert. Forskjellene er spesielt tydelige når det gjelder små størrelser . Noen ganger er det en overlapping når du reduserer størrelsen. Hvis det skjer, kan du øke avstanden eller bruke en annen skrift. Denne grafikken gir en illustrasjon av forskjellene, spesielt i forstørrelsen [1] , de dårlig skalerbare skriftene kan sees (f.eks. Times og Courier anbefales ikke; vi kan ikke garantere at de er oppdaterte). Se også avsnitt: " #Avstanden mellom bokstavene er feil "

En annen mulig årsak er mangel på tolkning av skriftnavnet ("fontfamilie") i (stort sett enkelt) anførselstegn , som faktisk er (for navn med mellomrom, sifre eller skilletegn unntatt bindestrek, og muligens samme verdi av reserverte søkeord ) av W3C generelt anbefalt ( phab: T64987 ( Bugzilla: 62987 ) ) . [1]

Merk:

  • LibRSVG støtter ikke CSS 2 " shorthand font " -egenskapen ( phab: T43425 ( Bugzilla: 41425 ) ) .
  • Inkscape V.0.48 støtter ikke "reserve skrifter" slik at SVG-filen må oppdateres manuelt i en teksteditor etter lagring.

Hvorfor vises ikke teksten min?

Dårlig SVG med tekstramme
Rett SVG uten tekstrammer

Det er flere mulige årsaker til dette: I Inkscape har du ikke lov til å bruke tekstrammer (kalt " flytende tekst "), men "bare" enkle tekster som du angir i Inkscape med et enkelt klikk og begynner å skrive umiddelbart ( phab: T43424 ( Bugzilla: 41424 ) ) . Hvis du derimot åpner en ramme og setter inn tekst der, får du svarte områder i stedet for teksten eller så vises ikke teksten i det hele tatt. Som navnet antyder, gjør kontinuerlige tekstfelt automatisk linjeskift hvis en linje ikke passer inn i den forhåndsdefinerte rammen. I vanlige tekstfelt kan linjer brytes med Enter -tasten.

I dette tilfellet lagres de engelske flytende-tekst-og-grafikkene (som bare var et forslag og aldri en standard) [2] -elementer i SVG-versjon 1.2 på SVG-filnivå i formen som følger:

 <flowRoot
     ...>
   ...
  </flowRoot>

Spesielt når det gjelder tomme tekstfelt, er det ikke sikkert at Inkscape ikke lenger enkelt kan velge og slette disse elementene. For å konvertere en flytende -Textfeldes i en vanlig tekstboks, gå til "Tekst" -menyen og velg "Generisk tekstkonvertering" (Konverter til tekst) Inkscape ikoner tekst konverteres til regular.svg eller "avbryt løpende tekst". Inkscape ikoner tekst unflow.svg Hvis dette fortsatt ikke fungerer, er den enkleste måten i disse tilfellene å åpne den innebygde XML -editoren ( Shift - Ctrl - X ) (eller et tekstredigeringsprogram) og slette alle flowRoot -elementer (foreldreløse her).

Tekst som også er justert med en bane kan settes i flytelementer (f.eks. Med en passende editor som Inkscape). → Se: " # Tekst justert til banen "

Videre teksten egenskapen text-size ikke støttet med hensyn til den relative informasjonen smaller/larger ( Phab: T88833 ).

En annen mulig årsak er en "manuell kjøring", se avsnitt: " #Hvorfor flyttes teksten min (forsvunnet)? "

Hvorfor flyttes teksten min (forsvinner)?

Korrekt individuelt plasserte bokstaver
Feil fremstilling: bare nedstigningen av "g" stikker opp øverst til venstre på bildet

I SVG -standarden er det mulig å plassere hver bokstav individuelt i en tegnstreng ved å angi en x- og y -posisjon for hver som en liste ( kerning og shifting , denne typen posisjonering skjer vanligvis med PDF -import). Det ser omtrent slik ut:

 <tekst
     x = "50 70 90 110"
     y = "50 52 48 46"
     style = "font-size: 24px; font-family: sans-serif" > efgh </text>

MediaWiki -gjengivelsen forstår ikke denne syntaksen (det samme gjelder de tilsvarende relative attributtene dx og dy, phab: T35245 ( Bugzilla: 33245 ) ). Koordinatattributtene x / y (eller dx / dy) kan bare inneholde én verdi, ellers vises de som om begge verdiene var null. (Som et resultat, hvis y="0" vises tegnene over kanten på bildet og blir avskåret eller, under visse omstendigheter, forsvinner helt, se ytterligere eksempel. )

I Inkscape kan denne tilsvarende "tekstmanipulasjonen" enkelt utlignes med funksjonen: ‹Tekst› - ‹Fjern manuell kjøring›. Inkscape ikoner tekst unkern.svg

En RegExp- kompatibel tekstredigerer er også tilgjengelig for å korrigere større kildetekst. Hvis det første tallet er det avgjørende (dvs. bare for sammenhengende tekst, må tekst som er langt fra hverandre enten flyttes manuelt eller skilles ved å <tspan i tekstredigereren), søkeuttrykket (f.eks. Med Notisblokk ++ ) kan se slik ut:

( [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 <rect> og <line> kalles foran <text> -elementet. [Eksempel?]

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

En annen motgift er i stedet

 <text font-size = "5px" > Eksempeltekst </text>

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

 <g transform = "scale (0.1)" > <text font-size = "50px" > Eksempeltekst </text> </g>

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

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 Inkscape -ikoner tekst vert kern.svg .

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

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

Det tilsvarende elementet <textPath> 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. Inkscape -ikoner banen union.svg 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.

 <rect 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
Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg Audacity Logo.svg

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).

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). Inkscape -ikoner viser node handles.svg (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

.