Hello everyone, I'm starting to translate a game from Japan but I have a problem, someone has never worked with files AFT, I ask this because I have to reduce the space of the various characters Kangi How to put the whole sentence without abbreviations

PS I tried to put the ASCII characters in the game but I see blank spaces

If memory serves AFT files were used in Jump Ultimate stars but it could well be in other games so I do not want to call it- if you want specific help you will have to say what game it is so one of us can pull it apart and point you in the right direction.

Anyhow for something more general you likely have two problems
1) Pointers (jump ultimate stars certainly had those and although they were not the easiest to work with they did nothing drastically different). In short pointers are numbers that well point at the end or start of words (hopefully not but it can happen), sentences (more common), paragraphs (not as common as sentences but common enough) and larger sections that the game reads and jumps the "cursor" to rather than scanning to text and figuring it out (a costly process and one weaker embedded devices can ill afford to waste resources doing). I usually like to make an analogy between the contents page of a book and pointers as they serve to perfom roughly the same task.
2) Text box limits. Even with the best will in the world on the part of the pointers you will probably still get a nice example of Japanese being a compact language when compared to European languages. You might get lucky and the game has a scripting engine or sorts that will allow for extra boxes to easily be added but otherwise you will be upping limits or changing what the game wants to load at various stages. This is usually quite doable though.

If you were on the GBA or dealing with text found in the binaries (can and does happen) you might have issues of how to cram it into the file but as long as you steer clear of making your translation thirty times larger than the original you should be OK if you are just editing files (one of the nice things about working with the DS and other systems that use files rather than bundle it all together). Equally not all parts of a game use pointers as they might use something to parse through or they might have sections of a fixed length but those are usually reserved for special cases (simple games in the case of the former and menus,bestiaries, in game encyclopaedias and such n the case of the latter). I should also say pointers are not always simple numbers from the start of the file and can be offset by an amount (add say 20h to the pointer and you get where it is at in the file- the 20h will usually be the length of the header or something) or be relative (where the pointer is then add the pointer value to that- if the pointer is at 34h and reads 46h you go to 7Ch).

As for the characters you have two main options
1) The game might well use shiftJIS meaning you have some Roman characters there as part of that ( http://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml )
2) Hack the game to support ASCII either by overwriting part of the Japanese font with Roman characters or actually hacking the game to use 8 bit characters (enough for just about every European language character) which is what the patch for Jump Ultimate stars eventually did although the former requires you to fiddle with a tile editor (easy enough if you have ever used paint or something like it) where the latter will see you learning some assembly for the DS. The bonus of the latter method is you usually gain more than enough space to make up for lengthier nature of European languages.

I sense you might have missed something I was trying to convey (my fault as I did not word it well)- if it is Japanese and on a modern system it will likely use a 16 bit text system but you can hack it to use a smaller one.
If however you did want to know how to change the game to use an 8bit text system rather than a 16 bit one then assuming the game does not have a simple option of changing it (not that likely) you get to find the text/font handling code and change it from reading a 16 bit value and determining the letter to using an 8 bit value and going from there (if you want to get really flash you can also hack to to do a variable width font (Japanese characters are all roughly the same width where the likes of lij1 and punctuation tend to be smaller/want to be closer together to look right) but we will leave that for a moment).

Also I think I went off topic- I grabbed the rom (and a surprising amount of it has the same underlying logic as Jump Ultimate stars but given they are both Jump related properties that is not that surprising- if you are curious though perhaps have a look at http://gbatemp.net/topic/60809-jump-ultimate-superstars-aar-archive/page__st__60 ) AFT files appear to be the fonts themselves rather than text or something like it and the script directory has very little in it. Alas I never thought to grab the Jump Stuff before deufeufeu's site went (I should know better but hey) and I know that included a nice bit on the somewhat custom font used by it.

Still a quick mess around with a tile editor gives them as GBA 8bpp and 256 pixels wide and in the case of opjkfont 14 high. They mostly appear to have Roman characters in there as well.
All start with
414C 4654 000? 5442
AL FT .. TB
Where ? is 1 or 2
The ones with 2 in (all of them save DSFont.aft) also have a DSIG stamp later in the file. 2 to indicate sections/files perhaps?

oppj8font and oppjkfont have similarities but none of the others do.
If you lop off everything before the DSIG you get a pretty much identical section save for a chunk between 0A and 2c of the new file and oppj8font has 40404000 at 24c where the others are all 0000 0000

opjkfont has DSIG at 149C and ends at 0002 A20C
opj8font has DSIG at 02BC and ends at 0000 430C
opjnfont has DSIG at 0094 and ends at 0000 100C
opjskfont has DSIG at 0A60 and ends at 0001 280C

This would seem to correspond the file size (and so amount of characters contained within)

Moving back to the ALFT section it seems to be composed of entries 6 bytes long which when setting the editor to 6 bytes per row gives the leftmost two byte entry counting up in hex give or take a few misses where the other two two byte entries repeat (often) or have a marginally different two byte (less often). That (once flipped) most of the non counting entries start with 8 or 9 (or E or F) wants to point to a shiftJIS encoding but that is probably getting ahead of things ( save you scrolling back up- http://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml ).
The first entry after the TB line appears to be the amount of entries in the list.

It looks like I will have to be productive today though so I will have to leave you here.