Skift farve på undertekster
Eller indsæt underteksttekst
Indstillinger
Vælg den farve, hele filen skifter til. Eksisterende farver på en linje erstattes i stedet for at blive stablet, så én kørsel efterlader præcis én farve pr. linje; fed, kursiv, understregning og karaoke-timing lades i fred. Kun #rrggbb skrives – det er den ene stavemåde, alle ni accepterede formater kan bære præcist. Ikke alle afspillere tegner inline-farve, og SRT har ingen standard for det: filen vil indeholde farven, men om den vises, er op til afspilleren.
Dette værktøj maler hver linje i en undertekstfil i én farve. Det læser filen som det, den faktisk er, og ikke efter endelsen, så samme kørsel virker på ni formater, og hvert af dem får farven i den notation, det allerede forstår: `<font color="#rrggbb">` i SRT, WebVTT, SBV og SAMI, en override-blok i ASS og SSA, et `<span tts:color>` i TTML, tag-arrayet i JSON og samme inline-markup inde i de citerede celler i en CSV.
Den farve, du vælger, erstatter det, der var, i stedet for at lægge sig oven på det. En linje, der ankom delvist grøn, kommer tilbage helt i den nye farve — ét område over hele linjen i stedet for et `<font>` inde i et `<font>`, som nogle afspillere gengiver med den indre farve og andre ignorerer helt. Fed, kursiv, understregning og karaoketiming lades, hvor de er, og et formateret område dækker stadig præcis de tegn, det dækkede før.
Det er én farve til hele filen med vilje. Undertekstfarve er som regel en leveringsbeslutning — en husets hvid, en gul, der overlever en lys scene, en farve reserveret til én slags taler — og en fil, der havde brug for to farver, ville kræve, at nogen besluttede, hvilke linjer der tager hvilken, og det er en opgave for en teksteditor snarere end en enkelt værdi på et panel. En tekstblok uden tekst får intet: der er intet område at male, og et farveområde med nul længde ville være et mærke på størrelse med ingenting.
Intet uploades, og intet forlader browservinduet. Farve er en af de få former for formatering, en undertekstfil kan bære uden en renderer ved siden af, men om seeren ser den, er afspillerens afgørelse — denne side skriver markøren, og spørgsmålene nedenfor siger ligeud, hvilken side af den grænse den står på.
Eksempler
To almindelige SRT-tekstblokke
Input
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>
Ét `<font>` pr. linje, lagt om hele linjen, og tidsstemplerne og de tomme linjer er præcis, som de ankom. Mærket er et område over linjen og ikke en egenskab ved tekstblokken, og derfor får en tekstblok med to hårdt ombrudte linjer to mærker i stedet for ét, der spænder over linjeskiftet.
En linje, der allerede har en farve og en kursiv
Input
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åde fjernes, før den nye farve lægges på, så resultatet er ét `<font>` om linjen med kursiven stadig indeni — ikke et `<font>` inde i et `<font>`, hvor indlejringsreglerne afhænger af afspilleren, og resultatet stille og roligt er forskelligt på hver. Det, der var grønt, har nu samme farve som alt andet, hvilket er den ærlige læsning af et panel, der beder om én farve.
Samme tekstblok i en ASS-fil
Input
[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 ikke noget `<font>`; farven er en override-kode, der åbnes før teksten og lukkes med en bar `{\c}` efter den, så resten af linjen ikke ved et uheld også males. Typografiarkets `PrimaryColour` redigeres ikke — override på tekstblokniveau er en stærkere instruktion og den eneste, der ville gælde kun denne tekstblok.
En tekstblok uden tekst
Input
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 tekstblok lades tom i stedet for at få et `<font>` om ingenting. En tom tekstblok er allerede et strukturelt problem — kontrolsiderne rapporterer den — og et markup-mærke uden tekst indeni ville ikke løse det, kun skjule det for en grep. Tekstblokken, der har tekst, males normalt.
Ofte stillede spørgsmål
Hvilke formater skriver denne farveside, og hvordan ser markøren ud i hvert af dem?
Ni: SRT, WebVTT, ASS, SSA, SBV, SAMI, TTML, JSON og CSV. SRT, WebVTT, SBV og SAMI tager `<font color="#rrggbb">`, ASS og SSA tager en `{\c&H…&}`-override lukket af `{\c}`, TTML tager `<span tts:color="#rrggbb">`, JSON skriver farven som et tag-område over linjen, og en CSV beholder samme `<font>`-markup inde i sin citerede tekstcelle. Formater uden plads til inline-farve accepteres slet ikke af siden — en LRC- eller MicroDVD-fil har ingen farvesyntaks, så en kørsel der ville rapportere en ændring og skrive ingenting.
Hvorfor står der `&H0000CCFF&` i ASS-outputtet, når jeg valgte `#ffcc00`?
Fordi en ASS-farve skrives med bytes i omvendt rækkefølge: `&HAABBGGRR`, hvor alpha kommer først og derefter blå, grøn og rød. `#ffcc00` er rød 255, grøn 204, blå 0, så det bliver `00` alpha, `00` blå, `CC` grøn, `FF` rød — `&H0000CCFF&`. Værdien er den farve, du valgte, og en afspiller, der viser den, viser samme gule farve; tallene ser kun ombyttede ud, fordi formatet gemmer dem bagfra.
Vil alle videofafspillere faktisk vise den nye farve i min SRT-fil?
Nej, og det er denne sides ærlige grænse. `<font color>` er ikke en del af SRT-specifikationen — det er markup, som de fleste afspillere tolererer, og nogle ignorerer — og ASS-override-koder respekteres af libass-baserede afspillere som VLC og mpv, men ikke af enhver hardware-set-top-boks. Siden skriver markøren korrekt, og resultatet kan verificeres i selve filen; om en bestemt afspiller viser det, er afspillerens afgørelse. Skal farven garanteres på skærmen, skal den brændes ind i billedet, og det er en anden opgave.
Hvad sker der med farver, filen allerede havde i sine <font>-mærker?
De erstattes og lægges ikke oven på. Hvert farveområde på en linje fjernes først, og derefter tilføjes ét område over hele linjen, så resultatet er et enkelt `<font>` i stedet for et `<font>` inde i et `<font>`. Indlejrede farvemærker er netop det tilfælde, hvor afspillere er mest uenige — nogle tager det indre, nogle det ydre, nogle flader begge ud — så en fil, der har været gennem denne side, har ét entydigt svar i sig.
Farver siden enkelte ord eller hele undertekstfilen?
Hele filen, én farve, hver linje. Der er ingen omfangsvælger pr. tekstblok eller pr. ord på denne side, og det er bevidst: panelet rummer én værdi, og en kørsel, hvis resultat afhang af, hvilke tekstblokke du havde klikket på, ville ikke kunne genskabes ud fra filen. En linje, hvor ét ord skal fremhæves, er en tekstredigering snarere end en farveændring, og sidens søg og erstat kan klare den målrettede del af det.
Bevares fed, kursiv, understregning og karaoketiming, når farven lægges på en ASS-linje?
De bevares, og deres områder bliver siddende på de samme tegn. Kun farveområder fjernes og tilføjes igen; de fire andre slags røres ikke, så et kursivt ord inde i en linje forbliver kursivt inde i den nye farve. I ASS betyder det, at `{\i1}` og dets afsluttende `{\i0}` stadig står samme steder omkring teksten, med farve-overriden åbnet før dem og lukket efter.