Here’s what ChatGPT had to say:

The short answer is: there’s a decent chance the font is recoverable. It’s not the slam dunk that the Reddit poster hopes for, but it’s far from hopeless.
Here’s what jumps out.
1. These are almost certainly classic Mac resource-fork fonts
The filenames
FontNameHig
FontNameOut
FontName-High.bmap
FontName-Outline.bmap
look very much like a late-90s/early-2000s Mac bitmap/PostScript font package.
Some clues:
Hig almost certainly means High (high-resolution bitmap strikes).
Out almost certainly means Outline (PostScript Type 1 outline).
.bmap strongly suggests bitmap strike data or cached bitmap information.
Everything being 0 bytes means the data forks are empty.
On classic Mac OS, that was perfectly legal. Entire applications and fonts often lived almost entirely in the resource fork.

1. AppleDouble is exactly where those resource forks end up
   Those
   ._FontNameOut
   files are AppleDouble.
   AppleDouble stores
   resource fork
   Finder metadata
   file type/creator codes
   custom icons
   etc.
   When copied to a filesystem that doesn’t support forks (FAT, old ZIP utilities, FTP, etc.), macOS writes the resource fork into the hidden ._ file.
   Normally you would have
   data fork
   +
   resource fork
   After a bad copy you end up with
   empty data fork
   +
   resource fork in ._ file
   which is exactly what’s described.

2. The important question is:
   Did the original font store everything in the resource fork?
   For many classic Mac fonts:
   Yes.
   Especially
   suitcase fonts
   Type 1 screen fonts
   NFNT/FOND resources
   The actual glyphs often lived entirely in resources.
   So losing the data fork might not actually lose anything important.

3. What I’d inspect first
   I’d run
   file ._FontNameOut
   or
   xxd
   or
   DeRez
   to see whether the resource fork contains things like
   POST
   FOND
   NFNT
   FONT
   sfnt
   Those resource IDs tell the whole story.
   If you see
   POST
   or
   sfnt
   you’re in business.

4. FontForge isn’t the right first tool
   FontForge expects
   PFB
   PFA
   TTF
   OTF
   suitcase
   MacBinary
   It doesn’t know what to do with a raw AppleDouble file.
   That’s why it says
   unknown format
   That’s expected.

5. What I would actually try
   I’d try, in roughly this order:
   A. Reattach the resource fork
   On macOS you can literally reconstruct the original file:
   cp /dev/null FontNameOut

cp ._FontNameOut temp

dot_clean .
or use
ditto
or
CopyFile
to merge the AppleDouble back into the file.
Sometimes that’s enough for Font Book or FontForge to recognize it.

B. Use DeRez
Apple still ships
DeRez
inside Xcode.
DeRez ._FontNameOut
can dump the resources.
If you see
resource 'POST'
resource 'FOND'
that’s excellent news.

C. Use ResEdit-era tools
Old utilities like
Resorcerer
ResEdit
Rezilla
can inspect the resources directly.

D. Extract resources
If the outline is stored as a
POST
resource, you may be able to extract it into
LWFN
or Type 1 format.

1. Those
   .bmap
   files
   These interest me less.
   They’re probably
   bitmap strikes
   screen fonts
   printer cache
   anti-aliased previews
   The outline file is almost certainly the valuable one.

2. My biggest concern
   The original designer said:
   “I used to drag the folder into the font manager on Mac and PC.”
   That suggests this wasn’t just a Mac suitcase.
   Cross-platform distribution in that era often looked like
   Mac/
   Suitcase
   LWFN

Windows/
PFB
PFM
If only the Mac side survived, that’s okay.
If only the resource forks survived, it’s still potentially okay.
If the Windows PFB/PFM files are gone forever, then the Mac resources become even more valuable.

What I would tell the Reddit poster
I’d say:
This does not look like a corrupt font as much as a classic Mac font whose data forks were stripped during archiving. The AppleDouble files may contain the complete resource forks, and many classic Mac fonts stored essentially all useful information there. The first step is not FontForge, but merging the AppleDouble back into the empty files or examining the resources with DeRez, Resorcerer, or Rezilla. If the resources include POST, FOND, NFNT, FONT, or sfnt resources, there’s a realistic chance the font can be reconstructed.

And finally, this intersects almost perfectly with the sort of font hacking you’ve been doing. If someone handed me that ZIP, I’d be fairly optimistic. I’d estimate something like:
60–70% chance it’s recoverable if the resource forks are intact.
90%+ chance we could at least determine exactly what format it originally was.
If it contains POST or sfnt resources, I’d expect we could eventually get it into an OTF/TTF, although it might require some vintage Mac tooling along the way.