The ARM9.bin files are probably all going to be different without a simple method of extraction via a premade tool. Certainly you can direct a tool to trim the file to your desired sizes. http://crackerscrap.com/projects.php (filecutter) and equally http://crackerscrap.com/ under documentation has some of the better worked examples of DS Assembly hacking out there. Perhaps the most notable of tools is something to handle the binary compression (the DS binaries and overlays use a custom type of compression called BLZ which differs from the standard LZ compressions otherwise seen on the DS) - crystaltile2 has issues recompressing to the format so for anything other than simple disassembly purposes it tends not to be used. Still http://gbatemp.net/topic/313278-nintendo-dsgba-compressors/ and http://code.google.com/p/dsdecmp/ can handle extraction and compression. After that a disassembler, assembler and a debugging grade emulator for the DS are useful.
Disassembly- IDA (the standard paid debugging tool for almost all hackers although the free version might be able to get something done), crystlatile2 and ndsdis2 ( http://hp.vector.co.jp/authors/VA018359/nds/ndshack.html ) and the emulators all afford a measure of static disassembly.
Debugging emulator
no$gba is the best right now but I am still not sure if it can be purchased again and running newer games is a pain as well.
desmume has some debugging functions- disassembly, memory viewers and more but no no$gba or VBA-SDL-h grade tools.
iDeaS ( http://ciacin.site90.com/ ) has a basic run to selection command as well as stepping commands- not enough for a full tracing session but you can get an awful lot done with it.
Assembler
ARM ASM kit from http://crackerscrap.com/projects.php which is a frontend to arm-eabi which http://www.romhacking.net/utilities/456/ also does
ARMips http://www.romhacking.net/utilities/635/
Crystaltile2 and IDA have some abilities here as well.
Tools and basic usage I covered most of in the recent version of my ROM hacking guide http://filetrip.net/nds-downloads/utilities/latest-gba-and-ds-rom-hacking-guide-f29988.html
Text in the ARM9 then- many of the wifi debug messages are in the ARM9 and it is certainly not unheard of to have the text within either the ARM9.bin or an overlay for it. It it kind of unfortunate when it does as it makes life harder than it might be for the basic file level stuff most of DS translation is concerned with. It need not just be text either and I seen lots in there (mainly graphics, fonts and things like character stats) before we even get to the weird stuff like Rockman EXE Operation Shooting Star where almost everything was an overlay or otherwise in the binary.
"font table/data"
Do you want to run a debugger to find the text encoding and/or pointers because there are many easier ways to find the encoding if so.
Frankly most of it is fairly normal but for the pointers- where on the DS they might be file or section level and so be fairly simple numbers here as the binary is loaded into and run exclusively from memory (same for overlays) the pointers are either fixed width/markup style (neither unheard of) or they are memory locations (or some minor maths on a given location).
Better yet if you have the pointers you have the section lengths (or end markers for it) which can be used to guide filecutter or something like it. Short version is where your file level pointers are probably four or eight hex digits (00 padded in the case of eight) almost certainly starting at the file or the usual offset/relative stuff these will look something like 02?????? unless they have a 02?????? value to start with and then some more standard relative stuff (it is easy enough to add to a number and may even be quicker- certainly I have seen a pointer in a register and then things added to it from memory before).
Then comes the space issue- repointing is fine if you do not change the overall length but that is easier said than done for most translations as far as making it the same or shorter. Frankly if it is a single word or phrase bust out the thesaurus but otherwise you are finding a location in the RAM (often far easier said than done) or making some (remember the wifi debug messages- they are always there in RAM, usually several kilobytes in length and rarely used so go nuts).
After this I guess it is talking about font handling and similar such things. This more likely ties into graphics hacking unless you want to cover 16 to 8 bit encoding conversion which is another good way to generate more space actually. Short version is you find the location that deals with decoding the text and either get it to read 8 bits at a time or carry on with 16 but decode two characters from it.
I know you tried not to but you have asked a really general question and I agree where a lot of it has not been covered in as much depth as other parts of either graphics hacking or text hacking it will be a repeat of some stuff or otherwise typing at length.
