Subtitle - Patch to make it multiline capable via "\n"

[tateu]

I'm using env->Invoke("Subtitle"...) to overlay some quick debug info in an OMF import filter I am working on. The info is too long to fit on one line so I wanted to print it on multiple lines. Calling env->Invoke several times seemed like a waste, so I modified the Subtitle filter (text-overlay.cpp) to parse the source text and split to multiple lines when it finds "\n" (a string value "", not an int value '\n').

Example:
Subtitle("Some text on line 1\nSome text on line 2", x=10, y=10, font="Arial", size=14, text_color=$FFFFFF)
will print two lines of text with default line spacing

or
Subtitle("Some text on line 1\nSome text on line 2", x=10, y=10, font="Arial", size=14, text_color=$FFFFFF, lsp=100)
will print two lines of text with line spacing = 100

lsp (line spacing) is a new variable and is optional. It defaults to a value of 0. A positive value places the lines farther apart and a negative value places the lines closer together.

The diffs are made against text-overlay.cpp and text-overlay.h downloaded from CVS on 2005-12-15.
http://www.tateu.net/software/Subtitle_MultiLine_text-overlay_cpp_diff.txt
http://www.tateu.net/software/Subtitle_MultiLine_text-overlay_h_diff.txt

[Richard Berg]

You should add a provision to escape the '\'. In other words, "\\n" would come out the way "\n" does without your patch.

[foxyshadis]

Since I'm dumb it took me longer than it had to, but I updated the patch (http://foxyshadis.slightlydark.com/random/Subtitle_MultiLine_text-overlay_cpp_diff.2.txt) for Richard's request (because I'd really like to see this happen).

I can't actually make a working avisynth compile, but I tested it using a similar C fwrite script. The only change is:

+ if(pdest != NULL && *(pdest-1)=='\\') {
+ psrc = pdest + 1;
+ continue;
+ }

[Wilbert]

Funny, i was looking at this yesterday. I don't get Richard's remark though.

subtitle("blabla\\nblabla2")

gives

blabla\
blabla2

as it should. Do i miss something?

[foxyshadis]

He doesn't want it to do that, so you can stick a literal \n in the output stream if you really want to. (Though I don't really see a need.) I wasn't even going to get into the whole "what if you quote the backslash like \\\n" for my addition.

[tateu]

foxyshadis,

Thanks for taking the time to fix this. I'd always meant to get around to it, but I forgot all about it.

Your link doesn't quite work. When you copied and pasted it, the url to my original link got added in with your new link. By manually copying and pasting it I was able to download the file.

[Bidoche]

Funny, i was looking at this yesterday. I don't get Richard's remark though.
subtitle("blabla\\nblabla2")
gives
blabla\blabla2
as it should. Do i miss something?It should output
blabla\nblabla2
Ask your favorite compiler on that if you doubt it

[foxyshadis]

Sorry about that, the editing window was too narrow to notice the extra url on there. ^^;; Fixed now.

[Richard Berg]

He doesn't want it to do that, so you can stick a literal \n in the output stream if you really want to. (Though I don't really see a need.)
Avisynth uses C syntax for many things. Having string literals behave subtlety different from C would just add confusion.

I wasn't even going to get into the whole "what if you quote the backslash like \\\n" for my addition.

Shouldn't need to do anything special. Once you parse an escape sequence (whether it's \\ or \n or anything else), you simply increment your src pointer an extra time and move on. Or you could just use regex.

[Mug Funky]

is it possible to use a | instead?

i just wrote a (HA!) multiline capable script, but it only supports 2 lines and is buggy as hell. it was a tad easier to handle a single character as a separator. it's actually pretty useful for titling though - did captions for a 75 min doco the other day and it only took 4 hours or so (i'm not doing that again for a LONG time). this is what happens when someone asks for a "non-hard subbed" master and instead gets a completely textless one with a long list of inaccurate timecodes that follow NTSC instead of PAL... grr.