内容介绍
1,这是高级部分 Substation Alpha 5 的格式方案(以下全E文 偶是不可能翻译的- -自己看 偶是把文档贴上来的 在最后我会贴上附件)
1.1 Introduction
1.2 Changes to [Script Info]
1.3 New group, [Textures]
1.3.1 Embedded into file
1.3.2 As an external file
1.3.3 Muxed into the container
1.4 [V5+ Styles] group
1.5 Unspecified groups
1.6 Changes to [Events]
1.7 New override tags
1.7.1 Trivial tags
1.7.2 3D transformation tags
1.7.3 3D texturing tags
1.7.4 General usage
1.7.5 Ruby support
1.7.6 Changes to the \t tag
1.7.7 Changes to color handling
Advanced Substation Alpha 5 format proposal
By Rodrigo Braz Monteiro (a.k.a. ArchMage ZeratuL)
Draft #5, 2006-03-20
Todo item by
Equinox the spec needs exact definitions of behaviour, not only "this does that". for example, what happens if top-aligned and bottom-aligned text collides in the middle?
Annotation by
jfs I'd like to scrap the SSA name and just call it eg. Advanced Subtitles 5. Who cares about the source of that number anyway ;)
Todo item by
Jfs I think it'd be a good idea to extend this to a complete spec, either copy-pasting from the SSA/ASS specs or re-writing as necessary.
[edit] Introduction
This format is a proposal for a successor to the Advanced Substation Alpha 4.00+ (and 4.00++) format. It includes several new override tags, which greatly extend the power of the format, as well as adding some new features and cleaning up some of the oddities that were being carried over from older versions. This document details the differences since v4.00++ (ASS2, presently only available on MPC, although it is almost identical to v4.00+).
Note that the name is not definitive, but, for the sake of writing of this document, it shall be referred to as AS5 for now, and its version is 5.00+. This could create issues if ever Substation Alpha resurrects and pulls out a totally different v5.00.
Written by ArchMage ZeratuL. The author can be reached on the channel #aegisub on irc.chatsociety.net.
Contributions by:
jfs
TheFluff
[edit] Changes to [Script Info]
No major changes here. As with before, this group can be used to dump random data (Aegisub does abuse this), so the "Generator" tag's utility is somewhat questionable. I believe that it would be interesting to have a generic way to know which program generated the script, and this could also be used to interpret the new "userdata" field on the dialogue lines. More on this later.
ScriptType: v5.00+
Generator: Name of program used to generate the script, i.e. "Aegisub", "Sabbu", "SSATool", etc.
Also, programs that edit the script files must leave any unknown fields untouched in the file. This allows other programs to safely store information there.
Annotation by
ender Scale the subtitles according to PlayResX and PlayResY, and don't assume that pixels are always square
Annotation by
jfs In line with not keeping the SSA name, maybe use AS5 for Script Type?
Annotation by
RasqualTwilight I support jfs' suggestion.
[edit] New group, [Textures]
One of the most advanced new features is the support for textures to be used on subtitles. All textures should be 32-bit PNGs, 24-bit JPEGs, or 24-bit Windows BMPs. Textures can be loaded into the script in one of three ways:
Annotation by
Equinox Why only Textures, i.e. static bitmaps? Movies should work too
[edit] Embedded into file
In that case, the texture has to be encoded in some ASCII-friendly format, and the line should be in the following format:
TextureEmbed: TextureName, Data
Annotation by
Equinox original SSA already defines an embedding format, i.e. UUenc. however, that kind of is obsolete and it is a HUGE waste of space unless the entire script gets compressed afterwards.
Annotation by
Equinox compression support should be a required feature in AS5
Annotation by
TheFluff I agree, kill the UUenc. Noone's going to use it anyway... And what do you mean, compression? Isn't that a matter for the renderer to worry about?
Annotation by
Equinox Well, i'd retain at least some form of direct embedding. Binary isn't really nice either, so UUenc isn't THAT bad. But, if it goes the UUenc way, the script should be zipped or bzip2ed or whatever. So specifiying a required compression algorithm all renderers are required to support would be nice. zip/deflate/zlib and bzip2 are interesting candidates...
Annotation by
RasqualTwilight I just think this is an unnecessary syntax complication, why not just use external resources?
[edit] As an external file
As a file on your hard disk, only really useful for hardsubbing. Should be:
TextureExternal: TextureName, Filename
For example:
TextureExternal: Arrow, c:\fansub\Arrow.png
Annotation by
Equinox full path names are a no-go. it'll never work properly without people changing the path all the time
Annotation by
TheFluff Allow both but recommend relative? Also, for portability, slashes should be used instead of backslashes when specifying relative paths.
[edit] Muxed into the container
Same as above, but the resource is made available by the container splitter. For softsubbing into Matroska.
Annotation by
Equinox need a syntax to specify resource paths. URI?
Annotation by
RasqualTwilight How about making it canonical with the relative path, i.e. look first in metadata and fallback on file system. This way, the renderer is not necessarily bound to a specific container format.
Annotation by
Jfs Let the container muxer decide on how to name resources, it can then transform whatever resources named in the AS5 file into muxed-in resources (including originally external ones) and change the definitions accordingly. The media framework should then in some way either handle it as part of the stream (maybe a secondary two-way connection between renderer and splitter?) or just have the splitter export temporary files on playback, and change the resource definitions in the subs into an external reference.
[edit] [V5+ Styles] group
The first obvious change is that the section name is renamed to [V5+ Styles]. Other than that, it is identical to v4.00++ styles, except that it adds a new field, "vertical", which lets you specify whether the text is horizontal (0) or vertical (1), and a new style type.
Annotation by
jfs In line with changing Script Type to AS5, also change this to AS5 Styles.
Annotation by
RasqualTwilight I concur.
A style line will thus look like this:
Style: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, OutlineColour, BackColour, Bold, Italic,
Underline, StrikeOut, ScaleX, ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment,
MarginL, MarginR, MarginT, MarginB, Encoding, RelativeTo, Vertical
(linebreaks added for readability)
The new style type is a simplified style, that allows you to set properties via override tags. In practice, what it does is to add all tags specified in it to the start of every line that uses this style. Also, these styles can inherit from another style, so the tags are combined (base style tags first, then derived style tags). It looks like this:
StyleEx: Name, BaseName, Tags
e.g.:
StyleEx: HazukiMad, Hazuki, \b1\1c#FF0000
StyleEx: Simple , , \fnArial\fs26
http://asa.diac24.net/asa_16x16.png Annotation by
Equinox killing the entire thing and exclusively using StyleEx is probably the best way.
Annotation by
TheFluff interesting thought, but that'd require a specification of default values, too... yellow arial with black border?
Annotation by
ArchMageZeratuL I don't think that killing standard is a good idea. Besides, we want compatibility with v4.00++. If possible, it should be a superset of it.
Annotation by
jfs Nah, really no need to keep that level of compatibility. If needed, a conversion tool could be made. People shouldn't need converting back to ASS either, I believe. For default values, how about "rederer decides"? Of course each script can just create its own base style that overrides every single setting.
Annotation by
RasqualTwilight I suggest StyleEx: HazukiMad < Hazuki, etc. or StyleEx: Hazuki > HazukiMad, etc. if it doesn't too much strain for parsing. It shall be more intuitive than the comma.
[edit] Unspecified groups
AS5 allows you to define your own groups. The rasterizer must ignore these groups, and any program that does not know how to parse it should leave it untouched in the file.
[edit] Changes to [Events]
The changes to dialogue lines are basically three: removal of four (five in v4.00++) relatively useless fields (and moving them to override tags, see below), adding of one new field, userdata, and improving the two time fields. The removal of the margin fields is especially good in the sense that it makes the subtitles a lot less verbose (in the majority of subtitle scripts, all 3 (4) border values are set to 0000 for practically every line).
But perhaps, the most important change is that the time field is now more flexible, allowing over 10 hours of subtitles, millisecond precision (for those who insist on timing to 120 fps raws) and timing to frames. Timing to frames might be extremely tricky and cause issues, so this is open for discussion.
Dialogue line:
Dialogue: Layer,Start,End,Style,Actor,Userdata,Contents
Where:
Layer: Same as ASS
Start: Start time. The main difference from previous format is that it allows any number of digits for hours, and seconds are treated as floating point numbers, i.e both "0:05:10" and "0:03:24.165" are valid. Also, you can set frame numbers by using the "f" prefix, i.e. "f126" to start on frame 126.
Annotation by
Equinox is freame-based timing in the file really a good thing? (imagine a VFR-compatible shifter...)
Annotation by
TheFluff frame-based timing was made obsolete with MicroDVD subs, and I have no idea what it's doing here
Annotation by
jfs People will want frame-exact typesetting, and no better way to provide that than letting the typesetter specify a frame number. Each video frame will have a number, it's just getting the video framework to feed them correctly. Of course, it should be disallowed to use a frame-number for start time and a timestamp for end-time.
End: End time, works the same as start time.
Style: Same as ASS
Actor: Same as ASS
Annotation by
jfs Couldn't Actor be put into userdata?
Userdata: This field should be ignored by rasterizer, and can be used to store program-specific data
Contents: Same as ASS
Todo item by
jfs Specify a recommended format for the Userdata field
The Left, Right and Vertical margins and effect fields become override tags.
[edit] New override tags
The most important changes in the new AS5 format is the inclusion of several new override tags. Some of these new tags allow typesetters to finally do several effects that were only possible with programs such as Adobe After Effects and SSATool before, while others just make their lives easier. Also, they should not be particularly hard to implement.
All tags support parenthesis, however, tags with only one parameter don't need it, with the exception of \effect.
Annotation by
jfs Just skip tag-by-tag compatibility with SSA and let \fn require parentheses around its argument.
[edit] Trivial tags
These tags are merely style overrides, and should be trivial to implement.
\effect(data): Does the same as the old "effect" field
\left#: Sets left margin
\right#: Sets right margin
\top#: Sets top margin
\bottom#: Sets bottom margin
\bordstyle#: Lets you toggle border style between opaque box and outline
\fsc#: Does both \fscx and \fscy at the same time.
[edit] 3D transformation tags
These are very important, powerful, and relatively simple to implement (if you're doing a 3D-based rasterizer) tags.
\vpos(x1,y1,x2,y2,x3,y3,x4,y4): Sets the polygon in which the subs are drawn, allowing you to do any kind of perspective effect with them. This has a large number of uses, such as karaoke, isometric perspective typesetting, hard to match signs, text distortion, etc.
Annotation by
Equinox that's one coordinate too many, rectangles are overspecified. how about (base point, upwards direction, rightwards direction)?
Annotation by
TheFluff one coordinate for each corner is more intitutive IMHO, and you don't always WANT a rectangle... set two of the corners to the same point and you'll get a triangle, for example
Annotation by
ArchMageZeratuL That won't do, equinox. I don't think that there is any way to do it with 3 coordinates that will give you full versatility. Although it should be remarked that 4 coordinates DOES allow for invalid shapes (i.e. twisting). At any rate, being user friendly and intuitive is the most important aspect, so it should remain as 4 coordinates.
Annotation by
Equinox okay, didn't think of a trapezoid case. It might be nice to have more ways of specifying this though. For example, specifying (x,y)(2,3,4) relative to (x,y)1, or even with polar coordinates. Example:
\pos(x1,y1)\polyverticalspolar(degrees,scale)\polyhorizontal(x4relativeToX1,y4relativeToY1)
certain animations would be a *lot* easier to do that way.
Now, for generalizing that, anchor points are a possibly neat thing:
\anch(name,\abs(x,y))
\anch(name,\relative(name,x,y))
\anch(name,\polar(name,deg,dist))
\anch(name,\lastchar(xfactor,yfactor))
\anch(name,\lastword(xfactor,yfactor))
\anch(name,\line(xfactor,yfactor))
\anch(name,\relative(name,x1,y1))\t(\anch(name,\relative(name,x2,y2)))
\vpos(name1,name2,name3,name4)
(example only, needs more thought on what to allow etc.)
That'd allow positioning schemes like "put this word 20px above this other word", and it'd even allow for furigana to be "emulated" by the means of "\anch(a,\lastchar(1,1))kanji\anch(b,\lastchar(1,1))" + "\vpos(a,,,b)furigana"
Annotation by
jfs Maybe look at how SSF does warped text, iirc it takes two curves and warps and bends the text such that its bottom and top edged follow the curves. Then have a tag like \\warp(unclosed drawing,unclosed drawing) with the unclosed drawings being composed of regular \p commands.
\1vc(colour1,colour2,colour3,colour4): Sets the primary colour to blend with each of the four vertices of draw polygon. The primary use for this is to make smooth gradients easily, which are often required for proper blending with the background. Note that you can also set alpha using this tag.
Annotation by
jfs How about if I wanted eg. a sunburst gradient centered on the subs? Suggesting an \1f..\4f tag instead (f for fill) that takes a kind of fill-style command/specification. That would also unify gradients with texturing.
\2vc(colour1,colour2,colour3,colour4): Same as above, for secondary color
\3vc(colour1,colour2,colour3,colour4): Same as above, for outline color
\4vc(colour1,colour2,colour3,colour4): Same as above, for shadow color
\1blend(mode): Sets the blending mode for primary color. Acceptable values are "normal", "add" and "multiply".
\2blend(mode): Same as above, for secondary color.
\3blend(mode): Same as above, for outline color.
\4blend(mode): Same as above, for shadow color.
[edit] 3D texturing tags
While not as important as the above group, texturing would allow a whole new range of special effects, such as particles for karaoke and arrows, images for normal typesetting. It should not prove to be a major challenge, if all the rendering is being done in 3D. For more information about storage of textures, see the section above.
\texture(name): Sets the texture to be applied to the fill of current line. The name must match a texture available under [Textures].
\texpoly(name,x1,y1,x2,y2,x3,y3,x4,y4): Draws a 4-sided polygon with the specified texture. This tag ignores every other setting, including colors and borders, except for \vc, \va and \blend.
[edit] General usage
Tags used for general effects, and that don't fall into any category. They are also more complicated to implement.
\blur#: Applies n-taps of a box blur to subtitles (alternatively: rho parameter in Gaussian blur?)
\bls#: Sets the baseline shift, that is, the shift in the distance that the glyph stands from baseline.
\baseline(start,n,commands): Same syntax as the drawing-command variation of \clip, except that this does not need to be a closed shape. It draws the text so that it follows the curve as if it were its baseline. Very useful for curved texts. The "start" parameter sets how many pixels will the subs start, relative to start of curve, and the "n" parameter is the exponent (same as \p's parameter).
\iclip(x1,y1,x2,y2): Clip subtitles so that they CANNOT be drawn inside this area. The exact opposite of \clip.
\iclip(p,drawing commands): Same as above, but with drawing commands.
[edit] Ruby support
Possibly the most advanced and complicated of the new tags, but also quite useful in some cases.
\ruby(text): Sets the following block of text to show the "text" ruby (aka furigana for Japanese) above it, or to the left, if it's vertical text. This can be reset by calling just "\ruby", which should be done after the relevant block of text.
\ruby2(text): Same as \ruby, except that it shows on bottom for horizontal text, and on the right for vertical text. Disabled with "\ruby2".
\frs#: Sets the font size for the ruby text.
\frd#: Sets the distance from the text baseline to position ruby text on.
Annotation by
Equinox the design of embedded control codes really is b0rked. the TeX way, for example ("\emph{textgoeshere}") is much cleaner.
Annotation by
TheFluff Everyone agrees that this won't work (at least not as it is), but how it should be is hotly debated
Annotation by
Equinox I'd propose
splitting per-line from per-span fields
putting the former in an extra field on the line
making the latter delimit their area of effect with { }
style codes would form a chain of multiple \control items preceding one {text} item. example:
Dialogue: L,S,E,St,A,U,\pos(123,456),
\b(1)\i(1){this is bold and italic \fs(30){and BIG too}}
\1c(red){this is red \1c(green){but this is green}}this is
normal line style\1c(blue){this is blue}
Annotation by
Jfs Another way of doing ruby would be some flexible relative positioning scheme. This would require putting "tags" in lines and then positioning text relative to those tags. For example (lines shortened to essential), using tags not wrapped in {}:
Dialogue: \tag(pos1)涙\tag(pos2)を\tag(pos3)流\tag{pos4)す瞬\tag(pos5)間
Dialogue: \pos(relative,above:squeeze,pos1:pos2)\fsc50なみだ
Dialogue: \pos(relative,above:center,pos3:pos4)\fsc50なが
Dialogue: \pos(relative,above:center,pos5)\fsc50しゅんかん
Here, なみだ would be vertically squeezed in between pos1 and pos2 (it will never be vertically expanded), なが would be centered between pos3 and pos4, and しゅんかん would be centered above pos5. More positioning-schemes could probably be developed, but I think this allows for a lot of flexibility. (Although it's perhaps not very readable.)
Another problem with this is how position-tags should be handled if their position changes over time (due to \t animations) or if their position might not actually be known yet (because the line the tag is defined on hasn't appeared yet.)
Annotation by
RasqualTwilight Is ruby overhang, i.e. spanning of ruby text over more than the enclosed base text, considered. confer Jfs note above. I would like the syntax to be light if possible.
[edit] Changes to the \t tag
The transform tag is arguably the most powerful tag in the v4.00+ specifications, as it allows you to create every sort of complex animation effect. It does, however, lack support for the \pos tag, a function which is instead performed by \move. In AS5, even though \move still works (for compatibility reasons), it's considered obsolete, and is in fact expanded to \pos(x1,y1)\t(t1,t2,\pos(x2,y2)). There are two reasons for \t to support \pos: to allow several movements in a single line (something forbidden by v4.00+), and to allow accelerated movement.
Aside from the tags that \t originally supported, the following tags are now also supported:
http://asa.diac24.net/asa_16x16.png\pos \vpos
\vc (all variations)
\va (all variations)
\blur
Annotation by
Equinox how about multiple animation anchor points?
Annotation by
RoRo Hi there, I think if you will improve \t by adding the \move support (or better say \pos\t(pos) support), you should also think in adding the \org support, so subtitle lines could maintain their perspective even if they are changing their position. (In fact \org should be merged in \pos, ¿why are they separated anyway?).
[edit] Changes to color handling
In AS5, HTML hex is also acceptable (and preferred) over VB Hex, which is what every SSA/ASS version used so far. The supported formats are #RRGGBB and #RRGGBBAA. Let's face it. No one, except for VB programmers and typesetters even know the damn VB format. Not only it's more verbose and hard to type (ampersand has to be the hardest key to press in American keyboard layout...), but it's also backwards.
附件:
As5格式.doc
