Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Last visited

  • Days Won


Posts posted by Geep

  1. I thought that might be the case. I don't believe I can access the SVN. Could you zip up all the font stuff you can easily find in that archive and send a link to me? TGA/DDS, even TTF for Stone, Mason, Carleton, etc., etc. No hurry. Thanks.

    P.S. Try to preserve file timedates

  2. I'm guessing there's a way to do that. Then back to DDS to distribute. That process would still cause an extra generation of quality loss, but at least you'd have a TGA in hand, for iterative editing without cumulative losses. But maybe first ask long-time TDMers to hunt for archived TGAs.

  3. Because DDS is a lossy format, every direct edit of a DDS file may reduce its quality slightly. So that means either:

    • hunt down the corresponding TGA file with the same timestamp
    • otherwise, edit the DDS as few times as possible.

    In the case of Stone, if the TGA can't be found and editing DDS is needed, I'd want to think about batching up all the bitmap edits needed for i18n... but that's a lot of work.

    I might add, there a third possibility in the case of the readable fonts that are currently ASCII only. If they were sourced from TTF, and you find the TTF (easy in a few cases), then see if it covers Latin-1 or more. You can (with some complications RE the conversion software) regenerate an improved TDM font from that.

  4. On 4/7/2024 at 5:40 PM, wesp5 said:

    I don't really know what this is about, but I will use the occasion to remind everybody that there is a surplus pixel at the lower left side of the capital W character. People speculated this might come from another character nearby in a font table but I don't see how V could have a pixel at that position....

    I'm assuming we're talking about Stone 24pt font here, used in subscripts & elsewhere.

    Images of letters are arranged into a bitmap by a process that doesn't have to conform to a tidy alphabetic grid. See Figure 2 of my new article https://wiki.thedarkmod.com/index.php?title=Font_Bitmaps_in_DDS_Files

    In the figure, you can see there's an accented "a" to the left of the W, whose foot is presumably within W's bounding box. I think I looked at this earlier & concluded that I couldn't shrink W's bounding box enough in the DAT file. So probably the pixels of the W need to be moved to the right... I haven't tried such surgery yet.

  5. I have updated my Refont program, to now have a function that can analyze a font DAT file for missing or problematic characters. As part of a broader inquiry, I've just applied that program, individually, to all current 'english' font DAT files. I'm reporting the overall results here. I'm sure this will not be a surprise to some of you, but may be to others.


    As you know, TDM fonts are based a bitmap system, derived from 256-character code pages, of which "English" and "Russian" are currently supported. "English" is actually Latin-1, with additional characters to cover more European languages in a single codepage. This is (in theory) quite good for major European languages, less so for less-prominent ones. For each font, bitmaps are distributed in 3 sizes (12, 24, 48 pt), with the engine doing interpolation scaling.

    Current Font Findings

    12-pt Size for All Fonts

    Only ASCII (i.e., lower range 0-127) characters are provided, no European. For some fonts (stone, mason, mason_glow), the 12-pt DAT is not distributed, so the engine will substitute a larger size, which typically has better Latin-1 coverage.

    For Fonts Used in Main Menus, HUD, or Subtitles

    The numbers shown approximate the number of "characters needing work"

    Fontname             Size-24    Size-48
     carleton               20       16
     carleton_condensed     20       35
     mason                  --       33         Since 24 pt is not distributed, engine uses 48 pt.
     stone                  30       83

    For Additional Fonts Used in FM Readables, Etc.

    Except for one font (treasure_map), all the remaining fonts are ASCII-only, i.e., no characters in the upper range. In the lower range, routinely the 24 and 48 pt sizes have equivalent coverage. Most of these fonts are fully or nearly complete, while some neglect certain punctuation symbols. The worst is "everette", with 24 "needing work" characters.

    Further details are here:


    Details about the 24 and 48 pt Sizes

    The numbers shown approximate the number of "characters needing work". Note that in some cases, only a correction to font metrics in the DAT file would be needed. Other cases would need bitmap surgery.

    For Fonts Used in Main Menus, HUD, or Subtitles

     carleton Size-24 (20 need work) [Note 1]
        Ń (0x8c), Ș (0x8d), Ț (0x8e), đ (0x90), ś (0x91), ŝ (0x95), ô (0x98), ŕ (0x99), ǔ (0x9a), ń (0x9c), ș (0x9d), ț (0x9e) + 8 more [Note 4] in upper range
     carleton Size-48 (16 need work) [Note 1]
        Ô (0x88), Ń (0x8c),Ș (0x8d), Ț (0x8e), đ (0x90), ĉ (0x96), ă (0x9b), ń (0x9c),  ș (0x9d), ț (0x9e), § (0xa7), Ñ (0xd1), á (x0e1), ñ (0xf1), ù (0xf9) + 1 more [Note 4] in upper range.
     carleton_condensed Size-24 (20 need work) [Note 1]
        Same set as carleton size-24
     carleton_condensed Size-48 (35 need work)
        All in ranges 0x80-0x8e, 0x90-0x9e, plus § (0xa7), Ñ (0xd1), á (0xe1), ñ (0xf1), ù (0xf9)
     mason Size-48 (33 need works) [Note 2]
        All in ranges 0x80-0x8e, 0x90-0x9e, plus Ą (0xaa), ą (0xba), ř (0xf7)
        Also, treatment of Non-breaking Space (NBSP)(0xa0) and Soft hyphen (SHY) here is inconsistent with other fonts, but unclear what correct treatment should be.
     Stone Size-24 (30 need work) [Note 3]
        Ń (0x8c), Ș (0x8d), Ț (0x8e), đ (0x90), ô (0x98), ŕ (0x99), ș (0x9d),  ț (0x9e), ð (0xf0) + 21 more [Note 4] in upper range.
     Stone Size-48 (83 need work)
       2 in lower range with bad boxes (p & y) + 20 in upper range with bad boxes (could enumerate these here, but too tedious) + 61 more [Note 4].
    [Note 1] Same stats for carleton_bold, carleton_glow
    [Note 2] Same stats for mason_glow. For mason and mason_glow, 24 pt is not distributed, so engine uses 48 pt.
    [Note 3] A more precise and in-depth analysis of 24-pt stone, including bitmap inspection, was presented earlier.
    [Note 4] Bounding boxes are shared among code points. Bitmap inspection would be needed to id which glyph "owns" bounding box, and which codepoints are interlopers. In many cases, this represents a deliberate substitution strategy, e.g., to redirect a missing accented character to another similarly-accented or unaccented character. Better than nothing.

    For Additional Fonts Used in FM Readables, Etc.

    Only the author of one font started to add upper-range (128-256) characters, but didn't get far along:

     Fontname     Size-24  Size-48
     treasure_map    107    96

    Remaining fonts are ASCII-only! Characters in the upper range (of which TDM defines 124) were not done. These are indicated as "124+" below, plus any additional problematic characters in the lower range. These latter are generally punctuation symbols.

     Fontname       Size-24 and Size-48
     andrew_script        124+0
     bamberg              124+0
     camberic             124+3
     carolingia           124+3
     chrishand            124+6
     ellianerelle         124+0
     everett              124+24
     gothica2             124+20
     jd_hand              124+0
     lotharus             124+11
     mac_humaine          124+8
     medusa               124+1
     nancy                124+4
     popsies              124+1
     rapscallionpirate    124+10 (for 48 pt, +9 for 24 pt)
     shoppinglist         124+1
     summertime           124+0



    • Like 4
  6. This was overall an enjoyable FM for me. Thanks for making it. Thoughts/spoilers:


    The briefing was clear and straightforward, if a little long. Continuity issue: one thief was described as having a fat ass, but later was not seen as being fat.

    I liked the carriage start. In the village, I spent some time looking for rope arrows, or ways to mantle up house facades. Nada. Not a problem.

    Inside the house, the shifting volumetric lighting and soundscapes with scraping (or distant thunder?) were particular highlights. The paintings of the sea captain and the ship with kraken amplified the storyline in the readables. The meaning of the bottles was nicely ambiguous (I thought the diary entry about seeing the dead crew in the bottles was a reference to alcoholism, not actual ghosts in the bottles.)

    I figured in the enormous library, there was a 99% chance that there was nothing worth looking at on the shelves, but I surveyed them anyway. Could have used a little payoff. Or fewer bookcases.

    The whole first part before the attic, while quite good from a loot, puzzle, and atmosphere perspective, might have benefited by breaking up the lengthy traversal with some unexpected threat (e.g., rotting floor giving way, stack of boxes and bottles falling over).

    The statuettes were splendid, particularly the one with the projected silhouette. Although they didn't seem to a perfect match to the descriptive note and overall nautical theme (e.g., no tentacles).

    Ubiquitous Terrible Old Man... kinda cool. The cutscene surprise ending was effective. Though I wish the last image could have had our heroes half covered in sand or sloshing water.

    Also, there were 2 minor issues undoubtedly due to engine or asset shortcomings:


    - When I first was in the nautical trophy room, I wanted to break through the glass case tops, but had no blackjack. So I tried picking up one of your cannon balls and dropping it repeatedly on the glass. No luck.

    - I didn't notice this when I played, but saw it in Cambridge Spy's youtube playthru at times 19:53 and 21:27... when a Terrible Old Man walks in front of a vertical display case, the glowing glass panels appear in front of his body, not behind.


    • Like 1
  7. 7 minutes ago, Rio_Walker said:

    Have you not considered using the screen? She walks behind it, there is a shadow of her lifting her arms, the light flickers - POOF - model swap, she steps out clothed.  Although, there had to be something preventing the player from walking behind the screen.

    That would be another good method. The one I used was easier for me, given that I was also supporting a SFW difficulty level where she is already dressed before reaching the attic.


    I liked how you handled her undressing to begin with.

    Thanks. No animation available for that either, so all done with cut-scene fakery and video editing.


    What startled me earlier tho, along with creepy music while the Builder's priest sings in the background, is the dress mannequin... with human hands.

    Glad you enjoyed a bit of sparks with those. Although I can't take any credit for the idea of dress mannequins with human hands... you'll see them IRL at any mall. But the implementation in TDM... therein the magic:


    It's a regular AI, but largely immobilized in an invisible box. It stops squirming and freezes about 1/2 minute after the game starts. So its exact posture is slightly different each time. The head is given a custom offset, to bury it into the floor beneath the dress.

    It's 11pm here, and I'm off. Thanks for chatting.

    • Like 1
  8. 8 minutes ago, Rio_Walker said:

    Also... maybe (if you'll be updating it someday) you should add a plank leading from the roof to the attic during the escape sequence, because I saw Emily just hover into it but fell down and missed the moment Emily respawned with clothes on. =D

    That "fall" delay was by design. Because there is no animation available to show her actually re-dressing from the trunk of clothing, so instead I wanted you to have to imagine it. Rather than actually catching up with her and seeing the instant body swap.

  9. 41 minutes ago, Rio_Walker said:

    I do have a question - what are those golden things actually? Like the one near the clothes iron above girl's room looked like a press or a stamp. That's a big stamp =D

    They are a riff on historic mushroom-style "linen smoothers", as this article sketches:


    The gold color hints at heavy brass.

    Bonus in the NSFW difficulty setting: One is also seen outside a laundry setting, for its *snort* suggestive shape.

  10. 2 hours ago, snatcher said:

    The only letter I could detect where spacing is noticeable is: J ack J erk J iffy J oy J uice.

    Yeah, it's J anky, but can't be fixed in the DAT file. Likely it requires moving pixels in the bitmap. I'm personally unenthused about doing that, particularly in a 2.12 timeframe.

    • Like 1
  11. Yet another Stone 24 pt Update.

    This removes stray marks to the left of G (as well as char 249, u with accent grave), visible with textscale 0.25 but not 0.24. So this may or may not benefit subtitles, but it will definitely help Stone font readables. Most of them use a scale of 0.25 for body text.

    An attempt was made to also improve G spacing, but (since xSkip can't be changed) effect is marginal at best.

    fontImage_24.dat of Feb 27

  12. 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.

  13. 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.)


    • Like 1
  14. Here is another update to the English Stone font's DAT file used for subtitles and some readables:


    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:

    1. 43% (55 chars) Good as is.
    2. 9% (12 chars) Good enough after DAT tweak included in this update.
    3. 6% (7 chars) Missing and shown as hollow box.
    4. 30% (38 chars) Missing accent/diacritic.
    5. 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:


    Changes to 2.11 english Stone fontImage_24.dat
    Feb 21, 2024 by Geep

    Within This Report
    - TDM chars shown herein are portrayed using UTF-8, not ANSI.
    - Changes to s, s2, t, t2 are described in pixel units. In terms of float values in range [0.0 .. 1.0], 1 pixel = 1.0/256.0

    ASCII Fixes, also done earlier for Jan 30th DAT update

    Problem: Stray mark from adjoining character seen to left. Right side of character is not clipped.
    Solution: move s to the right, incrementing 1 pixel, and compensate by decrementing pitch & imageWidth.

        char 37 (0x25) %
        char 67 (0x43) C
        char 69 (0x45) E
        char 84 (0x54) T
        char 87 (0x57) W
        char 89 (0x59) Y
        char 124 (0x7c) |    [Jan 30th change to xSkip is reverted][s move & imageWidth changed by 1 as described, but pitch decremented by 3 for better (though suboptimal) spacing]

    Problem: Poor spacing of J
    Prior Solution: Earlier, for the Jan 30th DAT update, both pitch and xSpace were altered. The J descender could go under the preceding character on the line. But there was then concern about xSpace changes affecting existing readables.
    Current Solution: the xSpace change is reverted, and instead the pitch decrement made larger (to 3). This is suboptimal, so maybe revisit possibility of xSpace change for TDM 2.13, or shift pixels in bitmap. Since J is at left edge of 256x256 bitmap, this limits shifts in s & s2.
        char 74 (0x4a) J

    Problem: Garbage image box
    Solution: Redo based on bitmap (including xSkip)

        char 60 (0x3c) <
        char 62 (0x3e) >

    ANSI Fixes, done in this Feb update

    Fully Fixed Chars

    Problem: Stray mark from adjoining character seen to left, and right side of character is clipped.
    Solution: move both imagebox x coordinates s & s2 to the right, incrementing 3 pixels

    Shifted right 3:
        char 169 (0xa9) Ů

    Problem: Stray mark from adjoining character seen to right, and left side of character is clipped.
    Solution: move both imagebox x coordinates s & s2 to the left, decrementing 3 or 5 pixels

    Shifted left 3:
        char 131 (0x83) Ż
        char 132 (0x84) Ź

    Shifted left 6: [a shift of 7 would space better, but then show stray marks to left. Probably bitmap surgery if want better still.]
        char 180 (0xb4) Ž   [Also decremented pitch by 3, to benefit spacing]

    Problem: Stray mark from adjoining character seen to left. Right side of character is not clipped.
    Solution: move s to the right, incrementing 1 or 2 pixels, and compensate by decrementing pitch & imageWidth.

    Move s 2:
        char 154 (0x9a) ǔ

    Move s 1:
        char 164 (0xa4) ű
        char 184 (0xb8) ž   [Also decrement pitch by 2, to benefit spacing]
        char 205 (0xcd) Í
        char 232 (0xe8) è
        char 233 (0xe9) é
        char 250 (0xfa) ú

    Problem: Poor spacing of Æ
    Solution: decrement pitch by 3 [Good enough, if still not optimal. Didn't try shifting s, s2.]
        char 198 (0xc6) Æ

    Improved Chars, but Still Not Good

    Problem & Solution: Same stray marks to left as just mentioned above.
    Problem remaining: These characters are also listed below as missing their accent/diacritic.

    Move s 1:
        char 172 (0xac) Č
        char 190 (0xbe) Ÿ
        char 203 (0xcb) Ë.

    Problem: Upper image boundary is negative, so out of range (t = -7). Glyphs that "ran off" bitmap had row 0 pixels replicated upward [this may vary with graphics driver], so were weird looking.
    Partial, Temporary Solution: Set t to zero, and reduce "height", "imageHeight, & "top" by 7. So, these are now just clipped on top.

        char 140 (0x8c)  Ń [Note A]
        char 152 (0x98)  ô [Note B]
        char 153 (0x99)  ŕ [Note B]
        char 240 (0xf0)  ð [Note C]

        [Note A] After fix, this char is listed below as shown with hollow box.
        [Note B] After fix, this char is listed below as missing its accent.
        [Note C] After fix, this char is listed below as weird.

    Problems due to Bitmap Content. No Repair Undertaken

    Glyphs with Missing Accent:

        char 133 (0x85) Ŝ
        char 134 (0x86) Ĉ
        char 135 (0x87) Ẑ
        char 136 (0x88) Ô
        char 137 (0x89) Ŕ
        char 138 (0x8a) Ǔ
        char 139 (0x8b) Ă
        char 151 (0x97) ẑ
        char 153 (0x99) ŕ     Clipped against top of bitmap
        char 155 (0x9b) ă
        char 162 (0xa2) Ű    (also standin for Hungarian Ü)
        char 165 (0xa5) Ě
        char 170 (0xaa) Ą
        char 171 (0xab) Ę
        char 172 (0xac) Č      [Note 2]
        char 176 (0xb0) Ő     (see also: Hungarian Ö at TDM codepoint 214)
        char 178 (0xb2) Ť
        char 179 (0xb3) Ď
        char 182 (0xb6) ť     [Note 3]
        char 183 (0xb7) ď
        char 190 (0xbe) Ÿ     [Note 2]
        char 192 (0xc0) À
        char 199 (0xc7) Ç
        char 200 (0xc8) È
        char 202 (0xca) Ê
        char 203 (0xcb) Ë     [Note 2]
        char 204 (0xcc) Ì
        char 206 (0xce) Î
        char 207 (0xcf) Ï
        char 208 (0xd0) Р    Missing accent is horizontal bar
        char 209 (0xd1) Ñ
        char 210 (0xd2) Ò
        char 212 (0xd4) Ô
        char 213 (0xd5) Õ
        char 217 (0xd9) Ù
        char 219 (0xdb) Û
        char 221 (0xdd) Ý
        char 255 (0xff) ÿ     [Note 3]

    [Note 2] This char had a stray mark to its left from an adjoining character. That problem was fixed above, but the missing accent was not addressed.

    [Note 3] This applies to TDM European but not TDM Russian codepoints, where FF works with B6 to show я.)

    Glyphs with Other Problems. Charitably, Work Started but Not Finished:

        char 152 (0x98) ô     Circumflex badly rendered as small square
        char 167 (0xa7) §     Wrong glyph, shows 8, probably as starting point
        char 168 (0xa8) š     Adequate, though accent only so-so
        char 188 (0xbc) Œ    Wrong character, shows D. Maybe plan to flip it?
        char 189 (0xbd) œ    Wrong character, shows o (start of work?)
        char 191 (0xbf) ¿    Shows ? instead. Maybe plan to flip it?
        char 222 (0xde) Þ     Wrong char B (start of work?)
        char 240 (0xf0) ð. Wrong character, o (prob start of work). Clipped against top of bitmap.
        char 254 (0xfe) þ. Wrong character B (maybe starting glyph to convert)

    No Glyph. Shown as Hollow Box:

        char 140 (0x8c) Ń    Clipped against top of bitmap
        char 141 (0x8d) Ș
        char 142 (0x8e) Ț
        char 144 (0x90) đ
        char 157 (0x9d) ș
        char 158 (0x9e) ț
        char 173 (0xad) Soft hyphen (SHY). Shown as hollow box. Better to show as regular hyphen?

    Information about methods, including new tools, to conduct this analysis and tweaking will be forthcoming, mostly after the 2.12 release.










    • Like 3
  15. 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.

    • Like 1
  16. On 2/10/2024 at 2:57 PM, stgatilov said:

    Some GUIs use some kind of pseudographics.
    Reducing the spacing also breaks such readables.

    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


    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:


        "num_pages"    : "1"
        "page1_left_title"    :
            "               Sales Ledger"
        "page1_left_body"    :
            "         Item         |Gold  |qty"
            "Skull candle    | 15g    | 3"
            "Silver lamp     |20g    | 2"
            "Small candle  |  8g      | 4 "
            "                             |            |"
            "                             |            |"
            "                             |            |"
            "                             |            |"
            "                             |            |"
            "                             |            |"
            "                             |            |"
            "                             |            |"
        "page1_right_title"    :
        "page1_right_body"    :
        "gui_page1"    : "guis/readables/books/book_calig_mac_humaine.gui"
        "snd_page_turn"    : "readable_page_turn"

    Note that it uses book_calig_mac_humaine.gui; so this pseudographic was not in Stone font


    • Like 1
  • Create New...