Geep

Rather than bundled subtitling themes, I'd like to see more flexible offerings, namely two new Settings for Subtitle Font Size Subtitle Font In the .gui, Subtitle Font size would directly tell the .gui how to scale the font. Together, the two settings could allow the .gui to intelligently adjust the backing fields; some .gui code experimentation would be needed. How about this? This optional parameter, in units of seconds, should be the last one in a line, preceded by a space. Probably doesn't need enclosure in double quotes, but that would be OK if you find it makes parsing easier. Specifying an amount of extra time, rather than the amount of total time, seems safer to me. An ideal format would be 1 digit before the decimal point, up to 3 after it. So typical: 0.1, 0.25, 0.125

Which leads me to wonder again why DR doesn't offer quick & easy smooth cylinder creation.

Currently the fieldwidths are a fixed proportion of the screen width (e.g., 90%). In the example images, there is the suggestion that the fieldwidth would be adjusted for aspect ratio instead. So a fieldwidth of 90% for a 4:3 screen becomes, for a 16:9 screen (with a 0.75 reduction) a fieldwidth of 67.5%. That is, about 2/3rds of the screen.

For the record, there is much about these examples I dislike: The subtitles here are way too lengthy and should be broken up into individual sentences. Subtitle sentences should be always terminated, e.g., with periods. No terminator means the sentence continues in the next subtitle. And I continue to make the case that these default panel fieldwidths are too large. As you know, I'd like half-screen, but could I suppose, live with up to 2/3rds. Having a less-wide default means that the player could then make it wider with a new future Setting that scales up (or down) fontsize too. So if enlarged, better support for low-vision users, and if shrunken, less obstrusive for eagle-eye'd English-as-second-language users.

The bottom example would be preferable to me, provided the default fontsize overall (not just the width) was enlarged by around 15%, to make lower case read faster. This would make the string about the same width as the top example.

Yes, probably using @datiswous's latest test map. And maybe more clues will appear: @nbohr1more just asked datiswous whether it is possible to narrow down which dev version broke things.

Good hunting, to get it down to a 2.09 vs 2.10 change. A bug report and stgatilov from here.

Maybe to get the gui transferred to the internal cpp variable, you have to do: onAction { set "gui::startSelect" "startpos2"; set "cmd" "startSelect"; // line 161 of ModMenu.cpp }

@datiswous, just catching up on this thread. I've also not been able find a copy of grayman's modified main_briefing.gui HMart's concerns may be apt, but since this there is still related C++ code, it presumably was all working at one time, and may still be. In your proposed version, you might see if, for gui::startSelect, instead of specifying the names of info_player_start, you just specified more generic objects. It could be that info_player_start was introduced later than 1.08, and is incompatible with startSelect. EDIT: Ignore that last idea; clearly info_player_start was what grayman had in mind. I would think as the main menu state transitions from BRIEFING to DIFF that the value of that StartSelect string you specified would be picked up by the cpp code... unless that became broken into the main menu redo's between 1.08 and today. Probably needs someone with source set up in a debugger (not me) to resolve. If all else fails, some form of selection after map load is a workaround.

FYI, as I work on The Wench, I'm adopting the following style to using parentheses. This differs in my earlier treatment for The Thug and The Lord, where square brackets were more frequent, with a different meaning. (I plan to revisit those subtitles for this and other reasons, after The Wench). [Fragment from my eventual style guide:] TO BE DETERMINED: Some styles of including a speaker ID in a subtitle use parentheses or square brackets. This is not important for subtitling barks, but may be for “verbosity story” subtitles. Parentheses. These are used to refer to what the AI is saying/vocalizing. The most common purpose is: Descriptors for non-word vocalizations that are not otherwise represented, e.g., (coughing) (sneezes) Other purposes, used sparingly, are: Descriptors for vocal style or sound quality, e.g., (sing-song) (hoarsely) Indicating the speaker’s physical or emotional state, e.g. (surprised) (sleepily) (drowning) Providing stage directions or context, e.g., talking (to buddy) Indicating the speaker is actually talking in a foreign language, though shown in English. As the examples indicate, the text within parentheses should be all-lower-case and relatively short (for CPS/WPM considerations). If it refers to the entire phrase, put it at the beginning, and, if using a verb, favor the “...ing” form, e.g. (humming). If it refers to a particular location within the sound file, if using a verb, favor the active-form, e.g., (hums). For a long sound, consider indicating its conclusion: (humming done) or (/humming). Do NOT use parentheses (or square brackets) to enclose speech to indicate: whispering or sotto-voce. Instead, add a prefix word (whispers), (whispering), (confidentially), etc. asides by the speaker. Dashes can be helpful to set off such speech, or an embedded “(aside)”. Be modest in indicating the loudness of a bark; while the voice tone can be evident, the actual volume that a bark is emitted is not under the subtitler’s control. Square Brackets. These are: Mainly reserved for future “verbosity effects” sounds. Can be used for non-vocal sound included with a bark clip, whether associated with the AI or not, but important enough to warrant a subtitle mention. This will be rare. Example: [claps]. Curly Braces. TDM fonts do not support these.

I guess I fell out of sync with where we were. I'll be looking forward to trying it out.

I'd like to get back to the request for the ability for the subtitler to extend individual subtitle durations, because that will be affecting how I create my subtitle content. Maybe the previous ideas on this were a bit too code-intensive (e.g., for inline & srt lines in .subs, having an additional parameter; or doing calculations based on wpm). Let me propose yet another, more limited/simple possibility... no new parameters, and no change to inline, but with srt, it would be OK for the last phrase to specify an endtime that exceeds the end of the clip, and the subtitle would be extended to that endtime. (For sanity, there can be a limit to that extension; I believe there's already a proposed global for that purpose.)

FYI, the findTooLongSubtitles program has been upgraded and is now available to download here. It now has an additional feature. For a given maximum fieldwidth, if a subtitle can be accommodated within two lines, valid places to insert a manual linebreak are indicated by '|'. The subtitle author can then choose one, based on additional sentence structure considerations. With a fieldwidth of 42, for the 2.11 New Job results posted here earlier, the analytic results are slightly improved, plus the '|' indicators appear: For the same fieldwidth, here's the analysis for 2.11 St. Lucia:

Another utility program, "findToolLongSubtitles", is now available, which scans a directory for .subs and .srt files, and checks the length in characters of each subtitle line against a maximum fieldwidth expressed in characters: Win executable C++ source code file It is more fully described in the latter as: findTooLongSubtitles.cpp By Geep, March, 2023, for The Dark Mod, under the terms of its open-source license. Purpose: Given a particular subtitle maximum fieldwidth, evaluates TDM subtitles - contained in .subs and .srt files - and reports those that don't fit. Assumes a maximum 2-line subtitle field. If a subtitle doesn't currently fit (or suboptimally relies on auto-word-wrap to fit), but could be made good by inserting or adjusting a linebreak, locations where that break could be positioned are shown. This program only examines a single folder at a time for contained .subs and .srt files. If your FM has these files in multiple places, run this program more than once. For an "inline" subtitle, a string-embedded "\n" causes a manual linebreak. When shown in this program's output, that subtitle has 2 lines, as in the game. This allows use of a common output routine for inline & srt subtitles. Console program invocation: findTooLongSubtitles -m maxSubtitleCharsPerLine [default is 42] -d dirWithSoundFiles [default is current dir] -o output file [default is stdout] Build: Requires C++ 17 or later For example outputs, evaluating subtitles found in the 2.11 releases of FMs New Job and St. Lucia against a proposed 42-character fieldwidth, see here.

Those are 2 ways to solve it, in addition to current TDM method (fixed-width translucent field spanning 2 lines). Others are - Have an outline font, that is, white with black background borders. Done right, this can be more reliably readable than drop shadows. Some foreign films use this. Probably a heavy lift for TDM. Have a dynamically-sized background rectangle (either black or dark translucent) that is a slightly-enlarged bounding box around each line separately. That last one is would probably also be more readable than drop shadows. All of these alternatives would mean less obscuring of the player's world view by translucent panels. That said, TDM isn't the only one using that panel style for captioning.

Yeah, it's both bad and good. The bad is that the letter glyphs were designed for a 4:3 world, and are widened with 16:9; so they are not as narrow as you might like for captions. The good is that the background fieldwidths are identically scaled, so compatible with limits like "characters/line", that should work independent of display aspect ratio.

The srt "spec" say to do it this way (shown in phrase 2): 1 00:00:00,180 --> 00:00:03,300 It's far too late now. 2 00:00:03,710 --> 00:00:07,470 I'm going to have to go to the market tomorrow. I've been assuming TDM's parsing implements this, but haven't yet been in a position to test that. You? If it doesn't, time for a bug report. (If you do test this, please let me know what you find. Also, if it doesn't work, you could try embedding a "\n" as a temporary workaround. That may or may not work. If it does, I'll need to alter my findTooLongSubtitles tool to support "\n" in srt, not just inline.)

I've built another console utility program, "findTooLongSubtitles". This can be pointed at any directory with .subs or .srt files, and will find all lines within, that are longer than what you specify (default is 42 characters/line). I'll be using it for barks, but it relates to what we are discussing here more broadly. I pointed it at 2.11's newjob FM, and generated this results: The first thing to notice is that there are two files, dealing with "story" captions. The first covers the audio briefing, as a long series of phrases in a .srt file. The second has the inline subtitles. Neither of these explicitly have linebreaks set, so both rely on word-wrap to make use of the second line. This is not ideal. Even so, many, but not all, would still fit as-is into a half-screen-wide subtitle field; namely, those that are roughly under 84 characters (2 x 42). In the briefing, all would likely fit, except two (#18 & 22) would be marginal. For the inline, 13 would seem to fit, but 9 need to be converted from inline to srt. All subtitles would benefit (not just the ones in this printout) from explicit line breaks that would make intelligent use of sentence structure. BTW, this utility program will be released in a day or so.

I'd like to follow up on an earlier post, that keeps with the simple approach of retaining a fixed subtitle fieldwidth. Regarding about how one might test that a subtitle fieldwidth is "just right" for a given subtitle-line character limit (e.g., 42/line), font, and font scale, here's what I would suggest. Using dummy sound files, create a set of about 100 "worst likely case" subtitles that are exactly the length of the character limit. These are directly derived from the corpus of existing "story" and "speech" subtitles. Turn this set into 100 sound shaders for another version of my testSubtitles... program (with the desired fieldwidth, font, and font scale under test), and step through them. What you are looking to achieve is NO auto-wrap from the first to second line. If you get auto-wrap, then adjust the font scale and/or fieldwidth and iterate until good. This gives assurance about "worst likely cases", not "worst possible case", e.g, 42 W's in a row. Details: Suppose you have a function that takes a subtitle string and a font, and returns the "draw length" of that string in internal scale-independent font units, that is, pre-scaling/rendering. It's just a summation of lookups into the appropriate static character-width table (assuming kerning is not an issue). Because we will be using the calculated value just to rank the strings for "worse-ness", the "font unit" is arbitrary. [ @stgatilov, maybe you could provide me with such a function in C++? Then I could do what follows. ] OK, so that is embedded into a program that is turned loose on the existing subtitles, to: look for 2-line subtitles (in inline or srt form) where the lines together exceed the character limit convert those to a single string by replacing the linebreak with a space truncate them to the character limit calculate the "draw length" of each export the strings and their draw lengths into a csv (along with a field indicating the source) Do that for each available subtitle source (FM or stock barks), and import all the .csv files as sets of rows in a spreadsheet. Then sort the rows by draw length and deduplicate (ignoring source). Take the 100 "worst likely case" rows, export them, and turn them (using techniques already developed) into sound shaders for the testSubtitles... program. So, a bit of work, but you get assurance that you've optimized things to minimize future problems.

I'm proposing the width be reduced to half-screen; that's relatively easy. I'm not opposed to smarter and more tight-fitting background management, while recognizing that's technically more challenging.

That's true. But most TDM fonts have slow readability, which is definitely not what you want in a subtitle. "Stone Print" would be a good substitute for Carleton. I'm not sure we never need a subtitle background. But it could be made a user choice, with a CVar toggle on/off. Regarding moving subs up, this is another compromise. Given that there are up to 3 stacked 2-line subtitles possible, and existing FMs that show messages centered on screen.

That's true, but given a corpus of representative text (which we have with the subtitles done so far), we can estimate length distributions, and cover 99.9% of representative real sentences. Takes some analysis, but do-able.

I wasn't proposing ever changing the font itself from Carleton, which I agree would be problematic. With respect to scaling the fontsize, if the adjustment process also carefully scales the field dimensions to match, it should not affect (or at least affect little) where auto-wraps occur. And this would further help with low-vision, which seems to me the whole point of the similar size adjustments in the HUD. So "fixed forever"... nah. But "fixed for the next bunch of official releases"... sure. For now, what I very much want is a policy on the maximum number of characters on a subtitle line. Then, a fontsize and fieldwidth can be determined that support that nicely, while minimizing corner overlap. As a first draft, I proposed: 42 characters max current fontsize: SUBTITLES_TEXT_SCALE 0.25 fieldwidth of 320 This would need more fulsome testing. It may be a slightly smaller fontsize or slightly larger fieldwidth is needed. As to the maximum character limit, if you google "subtitle character limit", you'll see that "about 42" seems most popular, with a range from 37 to 47. It would not be hard to write a program that, for a given FM, looked at all the subtitle lines in the .sub and .srt files and reported any that exceed any maximum number of characters. The FM author could then adjust those strings accordingly. Sure, it's more work, but kinda trivial in the big scheme of getting an FM out. And it is a one-time fix. I'm willing to write such a program, if I knew it would be used. (My Excel template provides the similar functionality that I use at the moment.)

I understand. But I'm against the current way-too-wide field length, that encourages subtitles that are either too long to read in the given time, or that have to be on-screen too long, when they should be chopped into smaller pieces. Too much work? I bet if you analyzed your srt phrases, almost all are already under 84 characters long. Below is a custom tdm_subtitles_common.gui that uses margins of 160 instead of 170. It's what I plan to use for The Wench testing. This should be more friendly to your existing subtitles than what came with testSubtitlesLord.

I'm seeking a middle ground, that would still accommodate low-vision folks. I don't think limiting the characters/line to 42 (a common limit used on streaming services like Netflix) would be a hardship, given srt capabilities. As I indicated above, with that limit and the current font size, the subtitle fields could be narrowed to 320 (i.e., half screen width). That would gracefully eliminate overlap with the corner items, except if the latter are enlarged to near-max size. And we could put off any consideration of adjustable subtitle font sizes until 2.13+