On 7/24/2018 14:43, Hans Hagen wrote:
Hi,
Around the upcoming context meeting we expect to release luatex 1.09 (or 1.10 ... yet undecided) which is the prelude to the next year tex live version. It's another step towards a stable version in terms of functionality as we don't expect much more to be added (in fact, I'm wondering if it makes sense to come up with a leaner and meaner version at some point because context can probably benefit from that). Of course under the hood there are improvements possible and we have some ideas (that might materialize at some point) but generally spoken, this is what one gets.
That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? Keep in mind that we're not talking of desk top publishing (click and point and place stuff) and also not of word processing (office like stuff) but of mostly automated structured document rendering. Also, keep in mind the landscape that we operate in (context development is mostly user driven as publishers imo long ago lost interest in any research and development and the potential of tex and friends is largely unknown elsewhere).
It's not my intention to implement each possible feature as core feature (no one would document it anyway). Also, as development is basically a spare time effort, don't expect complex commercially interesting niches to come for free either as in that case one can wait till I a find a reason for implementing it for fun or development is driven by a project.
When thinking of future additions, tex, lua, metapost of a mix is possible. They should be of interest for more than one user. Of course it can also be that everything needed is there. Maybe existing mechanisms can be improved in terms of functionality or performance (although i think that performance wise we're ok). But again keep in mind that the boundary conditions (all these interacting sub mechanisms) also prohibit some functionality.
Hans
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this. I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms. The ability to point register entries to something other than page numbers would also be useful. For export formats (XML) this requires that label references be part of the export. -- Rik