Geep

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+

@stgatilov, another problem area is the complete overlap between the inventory pickup message field (just above the breathe bar) and the subtitle fields, particularly the lowest. I think when both a subtitle and pickup message appear, both will be very hard to read. I can think of many solutions. Here's two of the easier ones: when subtitles are on, pickup messages are suppressed, i.e., as if you had set cvar tdm_inv_hud_pickupmessages "0". do away with the pickup message field, and just show pickup messages in the objectives/saved-games message field at top. A variation on (1) would be, when subtitles are on, show pickup messages just as a subtitle with "story" priority e.g.: [acquired 80 in jewels] A variation on (2) would be, keep the pickup message field, but reroute its messages to the objectives message field when subtitles are on. (Hmmm, I forget where trainer messages appear. Is that also a problem?)

(Following is copied from "AI Barks" thread, regarding: - what the subtitle field margins should be - what the character limits should be - making the subtitle fontsize and field size adjustable.) @datiswous, the centering of the subtitles was the stock tdm_subtitles_common default, so I left it that way with my The Lord customization. I'm not sure centering (versus, say, left justification) is really the issue with respect to subtitles fitting in the box. To that point, as a demonstration with testSubtitlesLord, I used rather aggressive side margins of 170 (so a field width of 300), which can just-barely accommodate 42 characters/line. But that means, depending on word breaks, some lines with 42 or 41 characters will force an autobreak, as it sounds like you observed. While margins of 170 is the minimum required to avoid overlap with fully-enlarged inventory icons, I think such overlap is less critical than avoiding unwanted word-wrap. So going with margins of 160 & field width of 320 is better going forward, while still avoiding the egregious overlap of the stock tdm_subtitles_common. Can you live with a character-length restriction of 42 characters/line? I think (given 2 lines) that should be adequate for almost all srt phrases that are limited to about 6 seconds. Another approach to strike a balance between margin overlap and word-wrap would be to reduce the font scale slightly. And in the long run, it would probably be desirable to have a CVar that the user could use to scale both font size and corresponding field height & width (and probably interfield vertical spacing). This could be shown as part of the HUD Settings special screen, even if internally it is a separate layer. Then the user could find their own compromise.

@datiswous, the centering of the subtitles was the stock tdm_subtitles_common default, so I left it that way with my The Lord customization. I'm not sure centering (versus, say, left justification) is really the issue with respect to subtitles fitting in the box. To that point, as a demonstration with testSubtitlesLord, I used rather aggressive side margins of 170 (so a field width of 300), which can just-barely accommodate 42 characters/line. But that means, depending on word breaks, some lines with 42 or 41 characters will force an autobreak, as it sounds like you observed. While margins of 170 is the minimum required to avoid overlap with fully-enlarged inventory icons, I think such overlap is less critical than avoiding unwanted word-wrap. So going with margins of 160 & field width of 320 is better going forward, while still avoiding the egregious overlap of the stock tdm_subtitles_common. Can you live with a character-length restriction of 42 characters/line? I think (given 2 lines) that should be adequate for almost all srt phrases that are limited to about 6 seconds. Another approach to strike a balance between margin overlap and word-wrap would be to reduce the font scale slightly. And in the long run, it would probably be desirable to have a CVar that the user could use to scale both font size and corresponding field height & width (and probably interfield vertical spacing). This could be shown as part of the HUD Settings special screen, even if internally it is a separate layer. Then the user could find their own compromise. EDIT: I'll copy this to the "futures" thread, given the "long run" ideas.

Good to know. It will probably be Thursday/Friday before I get to this. Quick question. There seems to be two popular styles of adding a leading speaker ID. With colon, e.g. "Jack: " and in parentheses, e.g. "(Jack) ". With a TDM conversation, at the start of an srt, what style do you like? For both styles, general subtitling recommendations seem to say to put the ID on the first line by itself. For TDM, that might have to be amended to "...except where the subtitle phrase doesn't fit entirely on the second line." BTW, for barks, I'm assuming the ideal max line length is 42 characters/line.

Thanks, I'll look into Kdenlive as well.

The HUD and subtitle guis could be made aware of each others' layout via existing and new CVars. So if you wanted to, say, have subtitle field widths shrink as inventory icon size enlarges, you could. Not saying that's a good idea, just that it's possible.

The Wench voice is the first one I've tackled that actually needs some audio clips to be done with srt. For that, I've downloaded and installed "Cadet", free captioning software produced by public TV station WGBH in Boston. Working with one clip, I was able to produce a srt file. Painful process, though. I clearly need to look at more Cadet tutorials....

You'd certainly want that override to happen. I don't know if it does. You could try a test by providing an override .ogg & subtitle. Specifically, as an override target, in 2.11, Dragofer provided a dozen subtitles for The Cynic voice as part of the core; see tdm_sound_vocals_decls01.pk4\subtitles\tdm_ai_cynic.subs. If you want to make a version of my testSubtitles... FM specifically for these dozen, here is content for an appropriate fm_test_subtitles_shaders.sndshd: BTW, this voice is used by two AI characters: tdm_ai_guard_citywatch (defined in tdm_ai_humanoid_guards01\def\tdm_ai_guard_citywatch.def) tdm_ai_thief (in tdm_ai_humanoid_guards01\def\tdm_ai_thief.def)

I'll be doing The Wench next. If anyone has a particular voice they want me to do sooner rather than later, let me know.

FYI, as this project goes forward, I plan to work first on barks for which a text vocal script is available. Complete bark text are available - via the wiki's "Voices" - for these: The Thug [done] The Grumbler [done] The Pro [done] The Mature Builder (Builder3) [done] The Young Builder (Builder4) [done] The Lord [done] Simpleton [done] Average Jack [done] The Lady [done] The Wench [done, final revision] The Commander [done] The Moor [done] The Maiden [done] These vocal sets are also referenced under "Voices", but the bark text is missing: Builder 1 & 2* [done] The Drunk [done] The Cynic [done] The Lady02 [done] The Critic [done] (* Builder 1 just uses Builder 2 vocal assets. Also, beyond the scope here: there are a few "conversation" clips used in the Saint Lucia FM, not intended for general use, even though they are distributed with the core. These differ between Builder 1 and 2, and are "verbosity story". Their subtitles are distributed in the core as file tdm_sound_vocals_decls01.pk4\tdm_stlucia.subs ) If you have bark text for any of the missing vocal sets, please get me a copy. Thanks. There are additional vocal sets not referenced under "Voices". These are low priority for me. Probably all except the newer manbeast (which is the only one that has a substantial amount of English) will be put off beyond 2.12 release. They are: manbeast [done] player [mainly various grunts] raven horse generic elemental spider revenant zombie werebeast Further out still, there are numerous non-AI sound clips for which "effects" subtitles might be provided. Many of these are found in tdm_sound_sfx01.pk4 and tdm_sound_sfx02.pk4

Can only speculate. The HUD features were in TDM a long time (so mature) before they became resizable. Subtitles are still kind of a work in progress. Also, subtitles are optional, whereas the other HUD features are (with an exception or two) not. And maybe tdm_hud.gui is already complicated enough.

I think we still differ on what that implementation should be. Sorry, I'm going to be a pain in the butt. Not really true; currently, the last phrase of an SRT is still bound by the original clip duration. So, SRT would also need the ability to be extended. And the SRT author have the ability to make use of that extension when specify the last-phrase end time. That said, I'm mainly interested in inline at this time, so, in the interest of getting that done, willing to postpone consideration of SRT extensions (say until 2.13). On the third hand, SRT will probably be used a lot more with "story" phrases, including those appearing in Conversations. So maybe it can't be postponed. For conversations (including those that are inline), I think the default extension should be 0, not 0.2 seconds. Because it's not desirable to extend unless you really have to, as I argued earlier. No. What I want is duration extensions that can be individualized and applied on a per-sound-clip basis. I would much prefer just specifying another individual (but optional) parameter, even if that requires more cut/paste. If instead it's necessary to reorder and group sound clips to apply extensions, this will make management of my testing list considerably more difficult. ALTERNATIVE: I could imagine, instead of specifying an optional extension parameter, it could be calculated on-the-fly. The algorithm would count the number of characters and the approximate number of words, apply them against global max CPS and WPM settings, and generate extensions, bounded by 0.0 and 0.5 seconds by default. If you're interested in this alternative, we could pursue it further. (The CPS/WPM could be one or two user-adjustable CVars.)

The Windows console/C++ program to populate the first 2 columns of the foregoing spreadsheet, with the sound files and their durations, is now available, as executable or as source code: soundDurationsCSV.exe soundDurationsCSV.cpp To run this successfully, you must have ffprobe/ffmpeg installed on your machine, to fetch the durations. The comments of the cpp file has a link to info about how to do that. For command-line parameters, do: soundDurationsCSV -h If you want to compile this yourself, it requires C++ 17 (or later).

I have concerns here, but let me get back to you after the weekend, when things are calmer IRL and I can address this thoughtfully.