Going forward with SILE 0.15.14 and beyond

[Omikhleia]

Towards 0.15.14

I let some time pass after my last contributions to SILE 0.15.14, to have a better perspective on the changes, and check how they behave in the long run in my own workflow and a dedicated custom build of SILE...

I think the proposed changes are quite solid and I would like them to be merged into the main branch. I am not in a hurry, so @alerque and others, read this as a "whenever time permits" kind of request -- no pressure, and see further comments below, as the situation is a bit more complex than just merging PRs and cutting a new release.

There are a few open issues...

1. We do have currently an issue with several fonts (Gentium: Bridge the bungled default font scenario with Gentium naming: "" → Basic → Plus → "" #2286, Change default font to Gentium Book #2287; SBL_Hbrw and AmiriQuran CI/tests: fonts SBL_Hbrw and AmiriQuran's addresses changed and now CI breaks #2297).
   These would have to be fixed, so CI passes again, and all other proposed changes can be rebased on top of that, in appropriate order...
2. Most of the changes ascribed to 0.15.14 so far are breaking several existing tests. This is not a problem per se, in my view, but none of the PRs current contain updated tests, for a good reason: besides the above font issue , the outcome also depends on the order in which PRs are merged.
   • We'd need these PRs to be reviewed -- and our community help would be very welcome here, so they can be merged to the main branch, and then the tests checked and updated accordingly, one at a time, to clearly check the impact of each change, and avoid unexpected regressions.
   • Subsequent PRs can then be rebased on top of the main branch, and so forth, until all are merged...

In this respect, I would really like to help more actively, but I am not sure how to proceed.

Towards 0.15.15 and 0.15.16

I'll be honest, I looked at what's currently ascribed to 0.16.x -- and seeing "registries" etc. (that is, new paradigms and big internal changes), I am a bit hesitant to proceed in that direction, at least for now. It does seem premature to me, and I would rather see SILE stabilizing a bit more first, before embarking on such any major changes. On stabilization over radical changes: There are a number of topics that wouldn't require such a leap, and that I think would be good to address first, at least to put them behind us, with knowledgeable understanding of the current code base and its limitations. That is, changes that not only simplify and improve the code base, but also add new features or fix existing issues, with proper typographical results, and not just "theoretical" ones.

In that respect, I recently added a few issues to the 0.15.x label, which I think would be good to address. None of the are really funny or glamorous, but I think they would help SILE being more solid and reliable -- and again, I would be happy to help with them.

I haven't reported some of my ideas yet (esp. about math, and micro-typography), but I'd like to challenge some of the current assumptions, and propose some new ideas. For instance, I have an experiment that extracts some of the math code to a different module, and can more or less be used outside SILE as well. It is still a bit rough around the edges, but I think it could be a good starting point for further discussions, on how to both benefit SILE and a more general "Lua-on-steroids" approach, even outside or beyond SILE itself. I can detail the vision, but it would be better to discuss it once we have stabilized SILE a bit more first.