I'm not sure how you checked the result, but the font replacement will only be
done when the document is opened by the corresponding MS application but not in
OOo. AFAIK the SubstFontMS is a hint for MS but I do not know how MS decides
about  using it.

->cmc: can you explain how it works/should work ?

->hdu: we should incorporate the mappings anyway

Good idea.

What was the problem with the "modification to existing hggothicbsun entry"?

Here is the steps I followed. (modification to existing hggothicbsun entry)
1. added below in share/registry/data/org/openoffice/VCL.xcu
<prop oor:name="SubsFontsMS">
   <value>msgothic</value>
</prop>
undef FontSubstitution -> en -> hggothicbsun.
2. start Writer and enter some string with HG GothicB Sun font.
3. save it as Word document
4. open it with Word
5. Word font combobox says HG GothicB Sun for the text in document.
So I thought 'SubsFontsMS' did not take effect, but I maybe had misunderstood
according to Stephan's comments 'SubstFontMS is a hint for MS'.
Could you please tell me how SubsFontsMS works and how I can confirm it? 

You should see an effect of SubstFontMS on a system where the original font is
not available, i.e. where HG GothicB Sun is missing. Then Word should use the
fallback font passed by the SubstFontMS field. However, if I remember correctly,
Word also has its own font fallback mechanism that might ignore what we tell him
and choose a different font anyway.

In word under tools->options->fonts->substitutes (or some similiar dialog in
that menu) word lists what the fallback font for a given font would be. On
export we can set 1 fallback font for a given font and word sometimes takes the
hint, but word will try a set of its own fallbacks before it uses the one we
set. It apparently uses PANOSE information to find a substitute for a font
before it uses the document set fallback font. So in practice the word fallback
that we set on export is really of most use to ourselves when we re-import the
document and the primary font is missing

Thanks for explanation. 
Please proceed adding these mappings to VCL.xcu. It must reduce font mapping
complain from Japanese user in SS6.0 and 7.

I added SubstFontMS entries for fonts that can be mapped ms*gothic and ms*mincho
in CWS gslpatches.

Naoyuki, could you pls. quickly verify this issue for me. Thx. a lot in advance.
Ulf.

re-open issue and reassign to naoyuki@openoffice.org

reassign to naoyuki@openoffice.org

reset resolution to FIXED

Hi Ulf,
I checked gslpatches cws (solsparc) but I can not see its effect, although it's
consistent with ssa and cms's comments. (Word own font substitution takes
precedence over document fallback hint)
Here is my observation:
1. made two doc files which uses HG *GothicB Sun, HG *MinchoL Sun with
gslpatches and normal m104.
2. open them separately with Word on Win2K which does not have HG *GothicB Sun nor 
    HG *MinchoL Sun.
Unfortunately Word uses MS Mincho for both of HG *GothicB Sun and HG *MinchoL
Sun with both doc files. (option->compatibility->fontsubstitution dialog shows
"Times New Roman" for all of 4 HG Mincho and Gothic fonts.)
I'm sure it's not user expected behaviour.
And when I re-import two docs with OpenOffice.org on the same Win2K, both of
docs are shown correctly (wiht MS Mincho and MS Gothic), so I can not tell this
fix takes effect in any sense. (OO.o knows HG GothicB Sun should be substituted
by MS Gothic, so doc's hint is not nessesally in this case.)
So I believe the ideal "default" substitution at exporting to MS docs seems to
be for primary font (like HG GothicB Sun -> MS  Gothic) not just giving a
fallback hint to Word. How do you think?

forgot to reassign.

re-open issue and reassign to us@openoffice.org

reassign to us@openoffice.org

reset resolution to FIXED

Naoyuki-San, thanks for your evaluation and explanations.

As the proposed changes are correctly implemented in VCL.xcu (as far as I can
judge) I set this one to 'Verified' and will perform a follow-up from your
suggestions regarding the ms filter.
Thanks Ulf.

Verified in MWS m121.