Re: roadmap

[Hans Hagen <j.hagen@xs4all.nl>]

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 <j.hagen@xs4all.nl>:
> 
>> - 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
-----------------------------------------------------------------
___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki     : http://contextgarden.net
___________________________________________________________________________________