ntg-context - mailing list for ConTeXt users
 help / color / mirror / Atom feed
From: Rik Kabel <context@rik.users.panix.com>
To: ntg-context@ntg.nl
Subject: Re: future versions
Date: Tue, 24 Jul 2018 21:29:30 -0400	[thread overview]
Message-ID: <a5f1ba45-9f24-edf7-dcff-3a8305bd7f99@rik.users.panix.com> (raw)
In-Reply-To: <83409155-cf0a-118b-3f80-d7bac8b1ef91@xs4all.nl>

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


___________________________________________________________________________________
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
___________________________________________________________________________________

  parent reply	other threads:[~2018-07-25  1:29 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-07-24 18:43 Hans Hagen
2018-07-24 19:07 ` Hans van der Meer
2018-07-24 20:35   ` Pablo Rodriguez
2018-07-24 20:30 ` Pablo Rodriguez
2018-07-24 21:02 ` Idris Samawi Hamid ادريس سماوي حامد
2018-07-24 23:21   ` Hans Hagen
2018-08-21  8:00     ` future versions - synctex Procházka Lukáš Ing.
2018-08-21  8:33       ` Hans Hagen
2018-08-21 13:04         ` Aditya Mahajan
2018-08-21 13:19           ` Hans Hagen
2018-08-21 14:46             ` Aditya Mahajan
2018-08-21 15:17               ` Hans Hagen
2018-07-25  1:29 ` Rik Kabel [this message]
2018-07-25  8:19   ` future versions Henning Hraban Ramm
2018-07-25 13:50     ` Rik Kabel
2018-07-25 16:06       ` Hans Hagen
2018-07-25 16:18       ` Alan Braslau
2018-07-25 17:01         ` Hans Hagen
2018-07-25 11:36   ` Hans Hagen
2018-07-25  7:45 ` Robert Zydenbos
2018-07-25 10:03   ` Richard Mahoney | Indica et Buddhica
2018-07-25 12:50     ` Hans Hagen
2018-07-25 13:12       ` Weber, Matthias
2018-07-25 17:50         ` Hans Hagen
2018-07-25 20:22           ` Henning Hraban Ramm
2018-07-25 11:38   ` Hans Hagen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a5f1ba45-9f24-edf7-dcff-3a8305bd7f99@rik.users.panix.com \
    --to=context@rik.users.panix.com \
    --cc=ntg-context@ntg.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).