Hi all,<br><br>For my first foray into contributing to Wine (a blast, so far :) )<br>I am implementing CreateScalableFontResource which is <br>currently present in stub form, but when fully implemented <br>should create .FOT files from .TTF files for (amongst other
<br>things) temporarily installing fonts by a successive call to <br>AddFontResource (which exists in Wine). <br><br>It was trivial to code the functionality for the flow of
<br>
CreateScalableFontResource as per the documentation<br>but my research into the .FOT file format threw up a couple <br>of questions.<br>
<br>Even though .FOT files, as far as they're used by <br>AddFontResource are little more than storage for a couple <br>of pathnames, they are in fact Win3.1-style NE-binary files. <br>With that in mind,<br><br>1) AFAICT, there is no code in Wine currently to save
<br>NE-binaries to disk, although obviously they are loadable<br>and data structures relating to the format are defined. Rather <br>than write a standalone, .FOT saving function,
based off the <br>kind of code you see in the fnt2fon program - .FON files<br>are a similar, though not identical format - would it be better <br>to write something like a NE_SaveModule that takes an <br>in-memory NE module and saves it to disk, and call that from
<br>my .FOT saving code? <br><br>This would live in ne_module.c I guess, and be limited, certainly <br>initially, to the
context in which I'd be using it. IE, just saving the <br>resources. Indeed, I don't know in what
other context that code <br>WOULD be used, but who knows, down the line someone <br>might want to expand it to do something more useful.<br><br>2) NE binaries, including FOT files, contain as part of the header <br>a DOS
stub-executable that typically spits out a message of <br>some sort. I reasoned that being in itself a compiled binary we can't <br>legally use the blob of binary that would appear in a real-world FOT <br>file as-is, and I certainly
wasn't about to go decompiling it, so I lifted<br>the DOS stub executable from fnt2fon which I'm assuming as it's<br>distributed with WINE is fair game.<br> <br>This will mean .FOT files generated by my code will be slightly different
<br>to a real, "in-the-wild" .FOT file, but I'm not
sure in the circumstances <br>that matters as the file is typically temporary, and only used as a <br>container, never to be run - it's just different from a user perspective.
Is <br>this OK? <br><br>Also, are there any open-source requirements on that small binary blob?<br>Fnt2fon certainly includes it with no added info.<br><br>3) Related to item 2, so far, the actual spec of the .FOT file format has
<br>eluded me, though knowing that it's a NE binary has enabled me to <br>reverse a lot of it, which I'm yet to test but I believe will be enough to fool<br>AddFontResource into doing what it's supposed to do. Again, is it
<br>enough to go that far for now as the FOT format seems to be unsupported <br>in WINE?<br><br>Advice on these points would help me help you :)
<br><br>--<br>Chris Howe<br><br><br>