What I see with 131108 is:
i (preceded by space?)
For each case, the grey area of the popup shows:
This is as planned, except for the page numbered "1.1". s_e doesn't recognize that format. That pdf has page numbering in the following order: 1 2 i ii iii ... xiv 1.1 2.1 3 4 5 6 7 ... 229
I may tweak s_e to handle the 1.1 pages better. But the 1 and 2 at the start is a challenge.
Coding background: I've indexed pagenumbers with roman numerals as the numeral value minus 100. E.g. xii --> 7 - 100 = -93. That gets the ordering right for the next/prev jumps. Earmarks at i, xii, 2, 6, 12 would make up the index -99, -93, 2, 6, 12. So If I'm at page i (-99) and jump to next earmark s_e would correctly jump to xii (-93) which is the next item to the right in the index. I think I can index 1.1 as 0.1 and get the right ordering. But fitting the first 1 in that pdf into this way of doing things is trickier. A more general worry is that people may in practice use various different page naming schemes. A general fix would have to for each pdf first read *all* its page numbers to an index/array in order and, when the user earmarks a page, mark that page in the index. For that I'll first need to find a way to read all page numbers of any pdf using autohotkey.edit:
command "dump_data" gives useful output. The relevant bit for faif-2.0.pdf :
But to work with this I'd have to recode much of s_e and add pdftk.exe as a dependancy. And I'm not sure if pdftk dump_data would work on all pdf files. And pdftk cannot handle djvu files. So I hesitate to go there.
I choose to translate the roman i ii iii ... xii into a made up format i1 i2 i3 ... i7 to avoid a lot of column spacing in the grid view if someone earmarks xxviiii.