Six has doubts that a VWF routine is really necessary for Dragon Force II, and after playing the game a bit with the preliminary translations completed so far, I tend to agree. But before we abandon this as a potential project goal, what are the typical advantages of a variable width font versus a normal font? Is there any rule of thumb that VWFs always turn out nicer than fixed width fonts?
About the font goals...
What you see in the Youtube video was Sixfortyfive literally using ASCII code to reinsert text translated by Sandslice. This can be done because Shift-JIS is basically "ASCII plus a million kana and kanji" as I like to describe it, and the result is really good -- but the catch is, the text was uncompressed to begin with in these cases.
The challenge comes in reinserting the storyline dialogue (the kind of text you saw in the first half of the video), which is compressed. The compression is really easy -- it's just uncompressed Shift-JIS with one-byte codes interspersed referring to commonly used values stored in a simple 256-entry dictionary. So when, say, an exclamation point is called, the game engine gets to use one byte as opposed to two every time the script needs that punctuation (the Shift-JIS exclamation consists of two bytes, whereas the ASCII exclamation point is just one).
But we can't simply use ASCII values to re-insert the translated text for the story dialogue on account of the game engine using one-byte codes to refer into the dictionary by default. The dictionary, of course, has to contain two-byte and therefore non-ASCII values -- we couldn't find any operators to pair up with ASCII values that would just produce a letter without an extra space or something. Also, I believe Six has played around with the idea of replacing dictionary values with the two-byte Roman alphabet characters stored in Shift-JIS (was it half-width or full width? I keep forgetting), and the result just looked awful.
One hypothetical solution to the problem is to simply NOP out the ASM routine for the dictionary compression, and assign the uncompressed text display routine to display the story dialogue as well. The downside is neither Six nor I are used to tracing ASM code (though I assume NOP'ing out the decompression routine would be easily accomplished in an appropriate dissassembler -- if one exists for Saturn ASM). I'm not sure how to go about finding it since ASM routines seem kind of nebulous to the uninitiated, whereas graphics and text values give you something concrete to stare at in RAM. So that's an area where help will be needed.
Failing that, I've hypothesized that we should be able to find the font graphics sheet (and decompress it if needed) and strategically overwrite appropriate kana and kanji images with our own stylized Roman alphabet font. Store two-byte values in the compression dictionary pointing to the spiffy Roman alphabet images on the sheet, and budda-bing, just write the English text in straight ASCII. The game engine will still treat the values as dictionary references, but each ASCII value circuitously points to its letter on the sheet if the ruse works well. However, there may be some kind of half-width/full-width issues Six might wish to bring up if we had to turn to a solution like this.