Currently, mmultiscripts can't be handled in generality because there can be an arbitrary number of pre-/post-scripts. The code handles 2 prescripts and 4 postscripts and sort of punts by dumping out the rest without proper speech. No one ever writes that many scripts, so really the main problem is the ugliness of handling (2+4)*2 (sub/super) cases.
One way to deal with this is to add a special pattern match rule like:
I think that is most cases, only the positions matter. The xpath might in some cases need to check the number of pre/postscripts, if an entry is none, if the preceeding/following is none, or it is the first/only of scripts, but that is still doable and likely not too bad.
Internally the code would process the base first, then the prescripts (sub followed by super), and then do the same for the postscripts.
I have not checked to make sure this ordering works in all cases. If not, maybe some process-order key could be added that specifies the order.
Currently, mmultiscripts can't be handled in generality because there can be an arbitrary number of pre-/post-scripts. The code handles 2 prescripts and 4 postscripts and sort of punts by dumping out the rest without proper speech. No one ever writes that many scripts, so really the main problem is the ugliness of handling (2+4)*2 (sub/super) cases.
One way to deal with this is to add a special pattern match rule like:
I think that is most cases, only the positions matter. The xpath might in some cases need to check the number of pre/postscripts, if an entry is none, if the preceeding/following is none, or it is the first/only of scripts, but that is still doable and likely not too bad.
Internally the code would process the base first, then the prescripts (sub followed by super), and then do the same for the postscripts.
I have not checked to make sure this ordering works in all cases. If not, maybe some
process-orderkey could be added that specifies the order.