Geep

OK, I poked around a little further. At the moment, beta5 is what I have installed. testSubtitlesANSI ships with an override of tdm_subtitles_message.gui, which allows easy adjustment of textscale. The shipped textscale is set to 0.24. With that, the stray marks left of G are not visible. If you change it to 0.25, they are visible; which is evidently what your custom gui is also using. If you setaside any custom tdm_subtitles_message.gui, then the core one goes into effect. Which, for beta 5, uses a textscale of 0.24 I don't know whether we will be going with 0.24 or 0.25 for the release. Nevertheless, now that I can see the stray marks, I'll see about fixing them. BTW, with your gui, the black outline shadows have the effect of enlarging the stray marks as black smudges. Helpful for diagnosis.

I just looked at capital G. I didn't see any stray marks. The spacing to its right was a bit larger than required, but I didn't think grossly so. Is that what you were referring to?

Here is the release of testSubtitlesANSI , one of my tools to test and improve the Stone 24 pt font that is used in all the English subtitles. testSubtitlesANSI.pk4 of Feb 25, 2024 As the screenshot below reveals, this testing tool is an FM that's a variant of that used to develop subtitles for individual AIs. Here, the subtitles are just alphabetic lists. There are 7 subtitles that cover all the TDM 8-bit codepoints (e.g., 0-255), including those representing European languages. The first two subtitles (i.e., codepoint sub-ranges) are shown in this screen shot. The tool allows inspection for stray marks and inter-character spacing; black walls & floor facilitate that. This release includes the most recent improvement to these attributes, provided in yesterday's update of the fontimage_24.dat file. (The changing of those attributes was done with a different tool, used iteratively with this one.)

Oops, in that last release, I accidentally didn't check character spacing in the codepoint range 128-159. And sure enough, there were problems with character 131 & 132, which needed 4 more pixels of horizontal box shifting than the 3 pixels they got earlier. So here's a better version: fontimage_24.dat of Feb 24

Here is another update to the English Stone font's DAT file used for subtitles and some readables: fontImage_24.dat This supercedes the Jan 30th update. As agreed, now all character spacings - as given by xSkip - are preserved (from this file in TDM 2.11). Exception: the Jan 30th repair of garbage metadata for "<" and ">" remains, including xSkip repair. ASCII Characters (lower 128). The earlier Jan 30th post summaries those ASCII characters that needed metadata changes to avoid adjoining stray marks. (The detail report below updates newer reversions and minor revisions.) ANSI Characters (upper 128). An analysis was also made of the status of the Stone 28 pt font's characters in the upper codepoint range of 128-255. This could be of interest if the subtitle system was some day expanded to include European languages, and continues to use the historic codepage method. The analysis also prompted some additional DAT tweaks now. Broadly, implementation of the upper-range characters (standard or TDM-specific, as defined in the TDM wiki's I18N - Character mapping I18N) is incomplete for Stone 24 pt. The status is: 43% (55 chars) Good as is. 9% (12 chars) Good enough after DAT tweak included in this update. 6% (7 chars) Missing and shown as hollow box. 30% (38 chars) Missing accent/diacritic. 7% (9 chars) Otherwise weird. But often suggestive of glyph work started but not completed. In addition, 7 chars within categories (3-5) were "improved", but are still not good. To really solve categories (3-5) requires DSS bitmap surgery (and corresponding DAT adjustments), which is beyond the scope of planned work. DAT tweaks of ANSI characters (like with ASCII) were careful to avoid changes to xSkip. Tweaks can be further grouped by problem solved.... In category (2): - (4 chars) Char is clipped, with stray mark from adjoining character on other side. - (7 chars) Stray mark, without char clipping. As improvements in categories (3-5): - (3 chars) Stray mark, without char clipping - (4 chars) Out of valid range on top edge A categorized itemization about treatment of specific problems and characters, with further details, is here: Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.

It's hard. I see what you are thinking about is a "bullet point" pattern, with or without a bullet point character. For that case, I suppose what we are trying to detect is: - the line starts with the bullet point pattern - a "J" character (say) with a shortened spacing, is somewhere in the line. - the line itself in the xd file is long enough to force a word wrap (let's just think about a single wrapping here) - the author assumed a particular word wrap point, and put in extra spaces in mid-line, immediately at the wrap point, so as to indent the latter part of the line, aligning with the indent of the first part. - the shortened-spacing J screws up the resulting alignment. Probably would need a script/program to winnow this down... ideally, that algorithm could also restrict attention to just Stone font. I'm OK with putting such an effort off for now, maybe revisiting it for 2.13.

OK, I understand. I will revert the spacing changes. But I'm looking at some other issues in that DAT file, so won't happen until around next week.

If I open and dock a 2D window and then change it from X-Y to, say, Y-Z, it doesn't seem to remember that latter change across DR sessions. A small pain.

Is this really a problem? Maybe we can figure that out before reverting the "J", which previously was so badly spaced it looked like it had a space character after it. It would be helpful to identify which missions have such pseudographics. I suspect it's a small number. And those using Stone font smaller still. In that regard, I did some preliminary experiments, limited to a cohort of 46 FMs on my machine with expanded FM .pk4s, that I can do full-text searches across files on, with TextPad. (@stgatilov, I imagine you are in a position to similarly and more conclusively search the entire english FM collection.) I searched with characters (or short strings) that would be likely to be found in pseudographics. For untranslated FMs, I searched in filenames of form *.xd . For translated FMs (those that had string "#str_" in their *.xd; there were 8 such FMs in my cohort) I searched in file english.lang Results Many search strings were useless due to too many false hits: "_" Widely used as part of internal xd name. Used on separate line as heading underscore. "/" Widely used as part of internal xd name. "\" (except "\\") Widely used \n or \" escape character "--" (assuming single dash is everywhere) Several in a row to bracket a heading, or as part of a letter's signature. Used on separate line, as heading underscore or as border between paragraphs These search strings were moderately useful, showing up in just a few FMs (tho none were pseudographics on examination): "=" Used on separate line as heading underscore (in penny3's erasing.xd) "+" Used as bullet points, or (several in a row) to bracket a heading (in penny3's erasing.xd; in bcd's english.lang) These search strings were most promising: "|" Only 1 hit, but it's a table-form pseudographic! (northdale1's snowedinn.xd) "\\" (i.e., escaped \) No hits found in my cohort Inspection of snowedinn.xd showed this: Note that it uses book_calig_mac_humaine.gui; so this pseudographic was not in Stone font

Hmmm, interesting. But Stone is not a monospaced font, so trying to do pseudo-graphics using Stone (if that was indeed what was used) would already be pretty difficult.

I haven't used DR in a while, and saw that my old layout was gone. Trying to muck about and re-establish some half-assed approximation of that took a while. Problems I had: "View -> New XY View" . OK, I need an YZ view, does that cover it? Took a while to determine, yes it does, you have to use Ctl-Tab to get to alternatives. (Never used that much in the past, once I had my 3 orthogonal views). HOWEVER, with this new system, sometimes I would create the 2D view, but couldn't then direct Ctl-Tab to it. Bug? It became clear after a while that there were some places you could dock, and some not, and that the blue haze would indicate that. And that those locations might change depending on what you did before. One problem for me was I had a 2D view that I wanted to dock in the right lower corner, but it would only do a full-height docking. And after a full-height dock, there was no way to grab a corner handle to make it less than full height. I'm not asking for that feature... I just wish I had a reasonable understanding of the best way to sequence and manage the horizontal and vertical splits. So: Do update the now-obsolete section of the user manual, and ideally provide a thorough video to illustrate the new system. (Sorry, datiswous, your vid above is not it.) Hint: That unrushed video, with audio, should demonstrate how to approximate each of the old layout styles.

I've just been reading through some old forum posts about correcting fonts. One of the points Tels makes is that, if correcting a font used in readables, you need to avoiding changing any character's spacing (I read this as xSkip value), to prevent changes in existing FM readables with that font. I suspect this advice is too conservative. You want to avoid enlarging an xSkip, because the resulting changes to wordwraps could potentially lead to line or paragraph truncation. Making an xSkip smaller could lead to wordwrap changes, but these IMHO would be unlikely to be harmful. In that regard, here's the situation with my changes to english Stone fontimage_24.dat (see a few posts previous as File Update for Improved Subtitle Font). Only a few characters got altered xSkips. Of those, the angle brackets were unlikely to be used in an existing readable, because they showed garbage glyphs. The "|" was xSkip-shortened, but also unlikely in readables. Only the badly centered and so xSkip-shortened "J" is thought to have potential to affect existing wordwraps. I have argued here that xSkip shortening is OK. However, I'm willing to revert spacing changes for "|" and "J" if people feel strongly otherwise.

Anyone have a working link (or can create a link) to the modified version of ExportFontToDoom3 executable? This 2009 version was created by Crispy, to handle 256 chars instead of just 128. It was released in this forum post: the dark mode readables ttf fonts The following links to it are now dead: - crispy's original release: http://www.inventivedingo.com/stuff/exportfonttodoom3_modified.zip This is what's listed at the bottom of Font Conversion & Repair as as "Fixed version of ExportFontToDoom". - Hyeron's 2009 upload: http://www.4shared.com/file/151870191/d47d0e16/exportfonttodoom3_modified.html - tels 2011 mirror: http://bloodgate.com/mirrors/tdm/pub/exportfonttodoom3_modified.zip. No luck with wayback machine, github, sourceforge, either .exe or source. (Source & exe for unmodified version from Grant Davies is in hand.)

File Update for Improved Subtitle Font As requested a while ago, to address the stray marks and other problems seen with current subtitle font, Stone, I am providing a short-term fix for characters in the printable ASCII range 32-126, using corrected metadata: fontimage_24.dat This is intended to replace tdm_fonts01.pk4\fonts\english\stone\fontimage_24.dat No change is needed in the related .dds files for this. Briefly, problems with stray marks found to the left of a character were due to picking up pixels from an adjoining character in the glyph bitmap dds files. Adjusting the location of the source box and related metrics fixed these. Affected were: % C E T W Y | The | character also got improved spacing, as did J Finally, the entirely screwed data for the angle brackets was corrected. This coming month I hope to work up a wiki page with diagrams to better explain what I learned about the mysteries of the idTech4 font .dat and .dds files. To see what the results look like with corrected fontimage_24.dat in place (as an override), here is my testing FM: testSubtitlesASCII.pk4 A longer-term fix (beyond 2.12 release) would also address ANSI and TDM-specific-mapped charaters in the range 128-255. To look at that, I have a similar experimental tester for ANSI (unripe to release). It shows substantial issues in that range. And then there's also consideration of fontimage_12.dat and fontimage_48.dat. And the russian-character variant.

Yeah, I had the benefit of a vocal script for most utterances, to decipher what they were saying. In a few cases, I had to listen over and over, and then make a best guess. Their chatter usually makes sense, but not 100.000%

Maybe it would be possible for the user to just bind a hotkey to toggle subtitles on/off?

Related to looking into the stray marks associated with Stone font characters... I've noticed that the nominal 12 pt DDS (which as discussed above only kicks in under 8 pt) has only ASCII glyphs... nothing with code points above 127. Maybe that's why the corresponding 12 pt DAT file was not distributed, as a workaround to force the engine to use 24pt instead, because tels never got around to finishing the low-priority aspects of the project. The 24 pt DDS does have the ANSI glyphs. At a glance, most are fine; a few are a bit ragged. I didn't check compliance and completeness with TDM's character map as given on the wiki. I don't feel ANSI improvement is a 2.12 item. I've got a test FM to show all the characters. At some point, after refinement, I'll post a link.

It's another aspect of, over time, tailoring the degree of subtitles shown to reflect the needs and preferences of the individual player. I think some low-hearing/audio-off players might appreciate brief soundscape descriptions, including weapon sounds; others would find it clutter. I understand that distinction is not personally of interest to you. For now, a fourth category is just theoretical, not a 2.12 item. I'm just asking for a different description of the existing category, other than "effects", that we can both live with. Something that sounds more human. How about "expressions"? If we can agree on a term, then I will revise the appropriate barks to use it.

I like the widget, but I'd love it to be an optional thing, toggled on/off by setting and/or CVar.

Sure, and a similar mechanism, not yet existing, could load translated subtitles, for Polish, Czech, etc. Sounds like 2.13+ to me. That is the main use case at this time. My own desire is not to limit it to that.

Hmm, interesting. The _12 version appears to be picked up at textscale of 0.15 or lower. So you'd have to get down to appx 7 pt type to start using the _12 as source, given my understanding that textscale 1.0 = 48 pts. Kinda baffling.

Yeah, I tried to do that sparingly. It's that low-hearing/audio-off vs normal-hearing/audio-on tradeoff again. Mostly did it when the text itself could be interpreted differently depending on tone. Like sarcasm. Current mechanism would make that hard to add as an option.

I know we disagree on what an "effect" is. To me, it's a non-human sound. So an arrow hit, or a raven call. Primarily to benefit low-hearing players. I would be fine with having a fourth category, between speech and effect. Let's call it maybe "vocal sounds". Here would go the barks that contain zero words. So, snores, cries of pain, some mutters; barks currently translated as just "(sigh)" or "AAiiee" In the short term, if you just fully implement 3 categories, but rename the 3rd category as "vocal_sounds" (or "vocalizations" or whatever), so there would be a "verbosity vocal_sounds" in .subs, then I'd be willing to redo the barks subtitles to use that.

At least for bark subtitles, fast readability is important, because they shouldn't be on the screen much beyond the vocalization time, and for fast talkers, that's not real long. Of the existing fonts available, Carleton and Stone are the easiest to read quickly at a glance. If you were going to allow a different font for story subs, assuming they are generally articulated at a more leisurely pace, then you could consider a more "themed" font. Still, a lot of TDM fonts are pretty slow to scan/parse.

I think this is probably "it depends". If a single AI is giving a story monologue, it may be implemented as a single .ogg file, just broken up into subtitles. So this would all be in the same slot. (Likewise, there are some long barks in a single .ogg file too). But the story could be in multiple .ogg files, delivered by one or several AI. Then, the slot could vary, if there also barks happening that scrambled things up. I could be wrong about this. I recall there was some chatter a long while ago about making what slot an particular AI uses somewhat sticky. That's interesting, about volume (or distance) threshold triggering of subtitle display. I'm guessing no threshold test is applied for story subs.