Re: [NTG-context] roadmap

On 5/14/2018 9:36 PM, Henning Hraban Ramm wrote:

Hi Hans, thank you so much!

Am 2018-05-14 um 17:17 schrieb Hans Hagen :

...

- Get rid of inconsistencies in the user interface e.g. by introducing new commands with settings.

+1

...

- Check what additional features users want (miss) and decide to what extent and with what priority we will put effort in this. We've reached a point where interference prevents more complex extensions.

* Recently I had some difficulties with (foot)notes, you’ll remember the margin notes thread. There are still some things that don’t work/look as I’d like them to, and I hope also others would welcome more flexible/simpler placement options.

Notes and margins will always be somewhat tricky esp used with other features because in the end tex has to make a choice .. in that respect i think that fully automated typesetting will never be ok.

* User/list/structure variables: Probably it’s just me, but there are a few difficulties.

hm, they're just data carried with whatever items that have accessors ... and thre tightly bound so real problems cannot happen there

* References: see Massimiliano’s question, apparently there are options missing for code before/after the list of pages

These hooks were added; adding a few more hooks is normally no big deal ... the main problem with such additions is that they seldom get documented (in fact that imo is also a it up to the one requesting such features).

* ePub: I got requests for ePubs again and will look into what’s still wrong/difficult. Last time I checked, footnote markers were accumulating in strange places. Maybe some more default constructs could get a representation in export XML, e.g. \bf, \it

It's hard to comment on that one without examples ... keep in mind that the xport is *not* meant as visual companion to the pdf but as a kind of representation of structure as seen by context ... any reordering due to typesetting can reflect that unless one does the obvious: for the expor make a special run with dedicated settings (like making notes end notes) ... notes (and other inserts) are a separate thing in the tex engine and have an asynchronous character. The better the input structure the better the export, and fro real robust multiple usage just code in xml. Visual properties (e.g. fonts) are not part of a structure, but you can just use highlights and such as these get tagged (with classes) so one then can relate them to e.g. fonts or colors. Keep in mind that \bf is not a construct, but a highlight named 'important' is. We can't make structure from non-structure. (FWIW: as long as we don't have projects that need this the priority for such features - the export basically started as a proof of concept - they get a low priority.)

* There are a few things missing in image handling - when I wrote my placement macros I needed image size calculations that already exist in ConTeXt but were not easily accessible.

hm, there's a lot available (actually also already in mkii) but i fear that there are too many variantions in demands .. there is a rather extensive plugin mechanism too (but not that documented) ... if some info is missing it can be added (although i don't think that there is more available in the engine that we expose)

* Would it be possible (or is it already?) to place stuff on layers and let "everything else" run around it? E.g. for half-page images I’m having a hard time using the float placement, while I could simply place images on a layer.

I'm not sure what you mean here but for the main flow we only hav eside floats. However, normally everything can be put on / moved to layers (iir the details manual shows some of that) but tex will never be loks dtp. Again, when i'd need that (given that I know what that means) for a project thaen i'd probably look into it. I've learned that much can be done in tex but not all without interference with other mechanisms.

...

- Are there reasonable challenges left.

* ePub

the export + a (dedicated) css ... exports have to be generic ... i must admit that i gave away my ebook reader as i never use(d) it and bying a new one is not on the agenda/budget (now)

* PDF/* (X, A, UA - probably only reasonable with external tools, but it seems like there’s not a lot that’s usable)

we support various formats (to some extend the backend even adapts to it) ... tagged pdf ... already there for quite a while but i never had any demand for it so i never really check the current state (also because imo it's a it weird feature ... only there because publishers don't want to distribute sources that are suitable for rendering variations ... so we're stuck with some pseudo structure related to visuals) (i might upgrade tagging and exports as they closely relate but it's not easy to get motivated for something that one has no real use for so at most it will cold winter evening stuff)

* even better error messages - often you get some obscure errors if you just miss a brace or bracket somewhere. I guess that’s a big hurdle for beginners.

not trivial ... related ot the fact that expansion is involved and macro languages are like that

* documentation... (sigh) While I’m trying to enhance our wiki and my book on ConTeXt, I often need to search the code base for undocumented options or usage examples, sometimes on stuff that looks simple or would be simple to do in InDesign...

well, there's already a lot (also in the distribution) and i try to keep up with new things but i don't see it as my duty to sit down and write tons more (luatex/context comes for free and it takes a lot of time and effort ... one can hardly complain so i don't feel too guilty about is .. documentation is also up to the users)

...

LuaTeX 1.09: - We expect the ffi interface to external libraries to become more stable over time. ConTeXt will not introduce dependencies (what can be done in Lua will happen in Lua) but on the other hand we might put some libraries in the distribution e.g. for database support.

Sounds good. I could use JSON, SQLite and/or MySQL support and some user interface stuff – at the moment my invoicing solution is a mixture of Bash, Python, Lua und ConTeXt, I’m already using a minimal OO library (classy.lua) and was looking into tekui, but got stuck... Maybe I should better look into the ConTeXt web framework as GUI. Or finally finish my (Django based) web shop and write a ConTeXt backend for PDF generation... Anyway.

sure, variation is welcome .. docker is also on some users' radar json: there's already a parser in context for many years (i needed one in the past), there's also a good performing sql framework present with support for mysql and sqlite (i also needed that in the past .. in fact some of our rendering on demand runs on luatex (lua interoreter) that way). (Many years ago i demo-ed sql support at a ctx meeting.)

Some default imaging solution would be nice (GraphicsMagick library).

i've played with that but in the end doing extensive manipulations runtime makes no sense .. i might pick up that thread when i can find a reason (but it's a huge set if libs and as such fragile wrr versions) Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------