Endre farge på undertekster
Eller lim inn underteksttekst
Innstillinger
Velg fargen hele filen blir. Eksisterende farger på en linje erstattes i stedet for å stables, så én kjøring gir nøyaktig én farge per linje; fet, kursiv, understreking og karaoketider blir stående. Bare #rrggbb skrives — det er den ene skrivemåten alle de ni aksepterte formatene kan bære nøyaktig. Ikke alle spillere tegner farge inne i linjen, og SRT har ingen standard for det: filen vil holde fargen, men om den vises, er opp til spilleren.
Denne siden maler hver linje i en undertekstfil i én farge. Den leser filen som det den faktisk er og ikke etter filnavnet, så den samme kjøringen virker på ni formater, og hvert av dem får fargen i notasjonen det allerede forstår: `<font color="#rrggbb">` i SRT, WebVTT, SBV og SAMI, en override-blokk i ASS og SSA, en `<span tts:color>` i TTML, tagg-arrayen i JSON, og den samme innebygde markeringen inne i de siterte cellene i en CSV.
Fargen du velger, erstatter det som var der i stedet for å legges oppå. En linje som kom delvis grønn, kommer tilbake helt i den nye fargen — ett område over hele linjen i stedet for en `<font>` inne i en `<font>`, som noen avspillere viser som den indre fargen og andre ignorerer helt. Fet, kursiv, understreking og karaoketiming blir stående der de er, og et stilt område dekker fortsatt nøyaktig de tegnene det dekket før.
Det er én farge for hele filen med vilje. Undertekstfarge er som regel en leveringsavgjørelse — en hvit husfarge, en gul som overlever en lys scene, en farge reservert for én slags taler — og en fil som trengte to farger, ville trenge noen til å avgjøre hvilke linjer som tar hvilken, som er en jobb for en tekstredigering og ikke for én verdi på et panel. En tekstblokk uten tekst får ingenting: det finnes ikke noe område å male, og et fargeområde med null lengde ville vært en tagg på størrelse med ingenting.
Ingenting lastes opp, og ingenting forlater nettleserfanen. Farge er en av de få delene av stiling en undertekstfil kan bære uten en renderer ved siden av seg, men om seeren ser den, er avspillerens avgjørelse — denne siden skriver markøren, og spørsmålene nedenfor sier rett ut hvilken side av den grensen den står på.
Eksempler
To enkle SRT-tekstblokker
Inndata
1
00:00:01,000 --> 00:00:02,000
Hello there.
2
00:00:03,000 --> 00:00:04,000
Second line.
Resultat
1
00:00:01,000 --> 00:00:02,000
<font color="#ffcc00">Hello there.</font>
2
00:00:03,000 --> 00:00:04,000
<font color="#ffcc00">Second line.</font>
Én `<font>` per linje, lagt rundt hele linjen, og timekodene og de tomme linjene er nøyaktig som de kom. Taggen er et område over linjen og ikke en egenskap ved blokken, og derfor får en blokk med to hardt ombrutte linjer to tagger i stedet for én som spenner over linjeskiftet.
En linje som allerede bærer en farge og en kursiv
Inndata
1
00:00:01,000 --> 00:00:02,000
<i>Hello</i> <font color="#00ff00">there</font>.
Resultat
1
00:00:01,000 --> 00:00:02,000
<font color="#ffcc00"><i>Hello</i> there.</font>
Det grønne området fjernes før den nye fargen legges på, så resultatet er én `<font>` rundt linjen med kursiven fortsatt inni — ikke en `<font>` inne i en `<font>`, der nestingsreglene avhenger av avspilleren og utfallet er stille forskjellig på hver. Det som var grønt, er nå samme farge som alt annet, som er den ærlige lesningen av et panel som ber om én farge.
Den samme blokken i en ASS-fil
Inndata
[Script Info]
ScriptType: v4.00+
[V4+ Styles]
Format: Name, Fontname, Fontsize
Style: Default,Arial,20
[Events]
Format: Layer, Start, End, Style, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,Hello there
Resultat
[Script Info]
ScriptType: v4.00+
[V4+ Styles]
Format: Name, Fontname, Fontsize
Style: Default,Arial,20
[Events]
Format: Layer, Start, End, Style, Text
Dialogue: 0,0:00:01.00,0:00:02.00,Default,{\c&H0000CCFF&}Hello there{\c}
ASS har ingen `<font>`; fargen er en override-kode som åpnes før teksten og lukkes av en bar `{\c}` etter den, så resten av linjen ikke ved et uhell blir malt også. Stilarket sin `PrimaryColour` redigeres ikke — overstyringen på blokknivå er en sterkere instruks og den eneste som ville gjelde bare denne blokken.
En tekstblokk uten tekst
Inndata
1
00:00:01,000 --> 00:00:02,000
2
00:00:03,000 --> 00:00:04,000
Hi.
Resultat
1
00:00:01,000 --> 00:00:02,000
2
00:00:03,000 --> 00:00:04,000
<font color="#ffcc00">Hi.</font>
Den tomme blokken blir stående tom i stedet for å få en `<font>` rundt ingenting. En tom blokk er allerede et strukturelt problem — kontrollsidene rapporterer den — og en markup-tagg uten tekst inni ville ikke rette det, bare skjule det for en grep. Blokken som har tekst, males normalt.
Ofte stilte spørsmål
Hvilke formater skriver denne fargesiden, og hvordan ser markøren ut i hvert av dem?
Ni: SRT, WebVTT, ASS, SSA, SBV, SAMI, TTML, JSON og CSV. SRT, WebVTT, SBV og SAMI tar `<font color="#rrggbb">`, ASS og SSA tar en `{\c&H…&}`-overstyring lukket av `{\c}`, TTML tar `<span tts:color="#rrggbb">`, JSON skriver fargen som et taggområde over linjen, og en CSV beholder den samme `<font>`-markeringen inne i tekstcellen sin. Formater som ikke har noe sted å sette innebygd farge, tas ikke imot av denne siden i det hele tatt — en LRC- eller MicroDVD-fil har ingen fargesyntaks, så en kjøring der ville rapportert en endring og skrevet ingenting.
Hvorfor står det `&H0000CCFF&` i ASS-utdataene når jeg valgte `#ffcc00`?
Fordi en ASS-farge skrives med bytene i motsatt rekkefølge: `&HAABBGGRR`, der alfa kommer først og deretter blå, grønn og rød parvis. `#ffcc00` er rød 255, grønn 204, blå 0, så den blir `00` alfa, `00` blå, `CC` grønn, `FF` rød — `&H0000CCFF&`. Verdien er fargen du valgte, og en avspiller som viser den, viser den samme gule; tallene ser bare omrokerte ut fordi formatet lagrer dem baklengs.
Vil hver videospiller faktisk vise den nye fargen?
Nei, og det er den ærlige grensen for denne siden. `<font color>` er ikke en del av SRT-spesifikasjonen — det er markering de fleste avspillere tåler og noen ignorerer — og ASS-overstyringskoder respekteres av libass-baserte avspillere som VLC og mpv, men ikke av hver maskinvareboks. Siden skriver markøren riktig, og resultatet kan verifiseres i filen selv; om en bestemt avspiller viser det, er den avspillerens avgjørelse. Må fargen garanteres på skjermen, må den brennes inn i bildet, som er en annen jobb.
Hva skjer med farger filen allerede hadde?
De erstattes, de legges ikke oppå. Hvert fargeområde på en linje fjernes først, og deretter legges ett område over hele linjen til, så resultatet er én `<font>` i stedet for en `<font>` inne i en `<font>`. Nestede fargetagger er tilfellet der avspillere er mest uenige — noen tar den indre, noen den ytre, noen flater begge ut — så en fil som har vært gjennom denne siden, har ett entydig svar i seg.
Farger siden enkeltord, eller hele undertekstfilen?
Hele filen, én farge, hver linje. Det finnes ingen omfang per blokk eller per ord på denne siden, og det er med vilje: panelet rommer én verdi, og en kjøring der resultatet avhang av hvilke blokker du hadde klikket på, ville ikke vært reproduserbar fra filen. En linje som trenger ett ord framhevet, er en tekstredigering snarere enn en fargeendring, og søk-og-erstatt-sidene her kan gjøre den målrettede delen av det.
Beholdes fet, kursiv, understreking og karaoketiming når fargen legges på?
De beholdes, og områdene deres forblir knyttet til de samme tegnene. Bare fargeområder fjernes og legges til igjen; de fire andre slagene er urørt, så et kursivert ord inne i en linje forblir kursivert inne i den nye fargen. I ASS betyr det at `{\i1}` og den avsluttende `{\i0}` fortsatt står på de samme stedene rundt teksten, med fargeoverstyringen åpnet før dem og lukket etter.