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.ha...@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
___________________________________________________________________________________
