Windows 10: fonts - remapping number system

I have a pack of fonts, that when used with office 2013, it shows up as gibirish.
I have them since office 2003, and had the same problem when I upgraded, and used them with office 2007, a friend of mine, was able to remap them (some type of number system), and it worked great. And it worked fine with office 2010 as well, but when I started using office 2013, I ran into the problem again, the above friend was able to remap some of them, but it takes him between 30 minutes to an hour each font. And not worth his time.
My question is, if someone would know how to do it, and I can do it myself, or maybe there is a really simple way how to fix it quickly.

The fonts in question, are right to left language fonts, hebrew fonts.
They work fine in all the programs I tried them, except for office 2013 and above. I have tried on different systems, windows vista up to windows 10, and the problem shows up only in office 2013 and above.

Thanks in advanced.

:)

 

Add button setting is missing

With the freeware tool
Remap Softkeys or
Softkey Manager it is possible to remap the softkey buttons.

 

How to deal with bad sector in "\ProgramData\Microsoft\Diagnosis\events01.rbs"

Here's how I understand it. The drive's controller can mark bad sectors and also remap them without the knowledge of the OS running on it. If during the remap all the data isn't copied properly to the spare sector then of course
chkdsk /f will detect file system (FS) corruption and fix it using the backup file table or error correction or whatever.
chkdsk /r can also hit upon a bad sector that the firmware hasn't detected yet, and this will make it add to the OS' own bad cluster table that tells the file system not to use that cluster in future. The job of marking and swapping the bad sector
on disk is still the controller's.

The Current Pending Sector count (counter 197) is just the number of sectors currently
marked as unstable (not marked as bad like you wrote) and which
might be remapped on the next failed write attempt (see
here for a more detailed description). The counter is decremented once the sectors have been successfully remapped. So it seems you have an unstable sector that hasn't been remapped yet by the controller, but IMO running the manufacturer's utility should
hopefully stress it enough that it should get marked and remapped so that the Pending Sector count falls back to 0. Once that is done either
chkdsk /f will detect no FS issues due to a successful copy of the data and you'll be good to go, or it will detect an issue and attempt to repair the FS.

Now perhaps running chkdsk /r again will also cause the unstable sector to error out and get marked/remapped, but if you are going to test the drive anyway I recommend the manufacturer's utility over chkdsk (that you've run once as it is). Your
choice though.