Very odd table "unicode" 0D0A-> 000D 000A for what I guess is a new line.
Pointers, I find it easier if you change the hex editor so the column width is approximately the same as the pointers (I would say exactly but sometimes the header means the pointers can end up on different lines).
Still trying to see the end of line/section marks in the text. I assume it is not compressed or it has already been uncompressed. Several candidates in the the new line, 00 09 00 or my personal favourite is 5c 00 (in your text conversion it comes out as a yen sign with a subscript p) as it seems to correspond the roughly arabic numbers counting up (I count nine such incidences) and when they do not appear the text is fairly short (all able to appear on one screen?), I will also note the " appearing alongside the yen sign and in some of the smaller sections as well.
The pointers are not plain leading me to call either relative or offset type and more likely relative. By the looks of the repeating numbers the pointer file may also house some text formatting/ownership as well (another reason for lining things up).
Going the other way and looking at the pointers the text file finishes at 2CD, I see nothing like that in the end of the text
0086
00CE
0128
0163
01AA
0203
0244
0270
02BA
Relative differences between them are
48
5A
3B
47
59
41
2C
4A
Nothing obvious there.
Ignoring the header (ASCII section) of the pointers gives about 170 (C5-1B) to play with- assuming 168 that means for the 14 "sections" in the text there are 12 per pointer although this can narrow if there are other things in there.
I shall have to play around with this one further.