future versions

future versions

[Hans Hagen]

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


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

Re: future versions

[Hans van der Meer]

[-- Attachment #1.1: Type: text/plain, Size: 3407 bytes --]

I am using XML a lot for structured data and typesetting them with hopefully not too much attention to detail — although I must confess often being a hopeless perfectionist.
If there are general improvements that can be made in that direction, I would welcome them. Although I apologise not being able to propose concrete suggestions at the moment, I hope this post will incite those more knowledgeable than me, to do so. They are thanked beforehand.

Hans van der Meer

> On 24 Jul 2018, at 20:43, Hans Hagen <j.hagen@xs4all.nl> 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
> 
> 
> -----------------------------------------------------------------
>                                          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
> ___________________________________________________________________________________



[-- Attachment #1.2: Type: text/html, Size: 5754 bytes --]

[-- Attachment #2: Type: text/plain, Size: 492 bytes --]

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

Re: future versions

[Pablo Rodriguez]

On 07/24/2018 08:43 PM, Hans Hagen wrote:
> [...] 
> 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.

Hans,

if that were possible, I would like to make two proposals (that come
from the roadmap thread
[https://mailman.ntg.nl/pipermail/ntg-context/2018/091512.html]). It
took me two months to catch up.

I think it could be interesting to have the implementation of vertical
scaling (as Hermann Zapf suggested to you) to avoid orphan an widows in
MkIV (https://mailman.ntg.nl/pipermail/ntg-context/2018/091541.html).

As mentioned in the past
(https://mailman.ntg.nl/pipermail/ntg-context/2018/091525.html), I would
like to have notes that handle automatically page registers.

Unfortunately, I cannot attend the ConTeXt Meeting. But the notes with
automatic page registers may qualify as unusual usage of ConTeXt. These
are relevant for language-learning texts (such as
https://geoffreysteadman.com/platos-crito/).

Many thanks for your excellent work with ConTeXt, LuaTeX and MetaPost,

Pablo
-- 
http://www.ousia.tk
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: future versions

[Pablo Rodriguez]

On 07/24/2018 09:07 PM, Hans van der Meer wrote:
> I am using XML a lot for structured data and typesetting them with
> hopefully not too much attention to detail — although I must confess
> often being a hopeless perfectionist.

But is it possible to use ConTeXt without paying attention to the
details? 🙂

I mean, aren’t we using ConTeXt to attain perfection (or at least, to
evince it)?

Pablo
-- 
http://www.ousia.tk
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: future versions

[Idris Samawi Hamid ادريس سماوي حامد]

Hi Hans, all,

On Tue, 24 Jul 2018 12:43:51 -0600, Hans Hagen <j.hagen@xs4all.nl> 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.

One needed feature that would be of general use is better support for  
synctex. Thinking especially of structural elements such as headings,  
footnotes, etc. which mostly do not work with synctex - i.e., clicking on  
these elements in the pdf do not take one back to the correct location in  
the relevant TEX file.

Best wishes
Idris
-- 
Idris Samawi Hamid, Professor
Department of Philosophy
Colorado State University
Fort Collins, CO 80512
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: future versions

[Hans Hagen]

On 7/24/2018 11:02 PM, Idris Samawi Hamid ادريس سماوي حامد wrote:
> Hi Hans, all,

> One needed feature that would be of general use is better support for 
> synctex. Thinking especially of structural elements such as headings, 
> footnotes, etc. which mostly do not work with synctex - i.e., clicking 
> on these elements in the pdf do not take one back to the correct 
> location in the relevant TEX file.
Synctex is a beast. Basically it is not that useable for context which 
is why we have a different implementation with a rather clean, minimal, 
and predictable output. Unfortunately the usual approahc is to use a 
library for interoreting the synctex files which has too much heuristics 
built in. More flexible would be to let the viewer cann an external 
program which then can interpret the synctex file based on a page and 
position. This also would make it possible to have more clever 
synchronization and/or adapt to a macro package. Anyway, were sort of 
stuck and can only try to make the best of it.

That said, the context generated synctex file is nornally okay unless we 
render from lua, which happens for instance with titles. Just try

\ctxlua{context("foo bar")}

and you will also see that there is no line related positioning. 
Tweaking luatex for this is not really an options because whatever 
decision we make here will backfire at some point. (I can look into some 
option later but it needs bit of thinking)

Anyway, i can cheat at the tex/lua end if needed and support e.g. titles 
but i'm not going to pollute the code with every place where we come 
from lua (also because in most cases there is no relation with the 
source anyway then). Also, I will not add code that can have an impact 
on performance when synctex is turned off. But for a subset of 
constructs that are relatively short in usage it is doable (but doesn't 
really qualify as fun -- also, i don't use it myself).

(One complication is that for instance fixing it for some constructs 
will break it for xml input which also supports synctex.)

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
___________________________________________________________________________________

Re: future versions

[Rik Kabel]

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
___________________________________________________________________________________

Re: future versions

[Robert Zydenbos]

On 24. Jul 2018, at 20:43, Hans Hagen <j.hagen@xs4all.nl> wrote:

> Hi,
> 
> […]
> That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? […]

At the risk of sounding like a scratched, repeating gramophone record -- support for Indic scripts would be wonderful.

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

Re: future versions

[Henning Hraban Ramm]

Am 2018-07-25 um 03:29 schrieb Rik Kabel <context@rik.users.panix.com>:

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

Generally, you get stylistic tagging by using \definehighlight.
I replaced \em and \bf by \emph{} and \strong{} in my projects.

Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.

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

Seconded. Same with other references like footnotes. (I need to try the current state, my last ePub was somewhen last year, and there the locations of footnotes were messed up.)

Greetlings, Hraban
---
https://www.fiee.net
http://wiki.contextgarden.net
https://www.dreiviertelhaus.de
GPG Key ID 1C9B22FD

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

Re: future versions

[Richard Mahoney | Indica et Buddhica]

Agree wholeheartedly, and possibly also support for Tibetan.


Best, Richard



-- 
Richard Mahoney - Indica et Buddhica 
Littledene Bay Road Oxford New Zealand 
T: +64 3 312 1699 M: +64 210 640 216 
r.mahoney@indica-et-buddhica.org 

http://indica-et-buddhica.org/ 

-----Original Message-----
From: Robert Zydenbos <context@zydenbos.net>
Reply-to: mailing list for ConTeXt users <ntg-context@ntg.nl>
To: mailing list for ConTeXt users <ntg-context@ntg.nl>
Subject: Re: [NTG-context] future versions
Date: Wed, 25 Jul 2018 09:45:47 +0200
Mailer: Apple Mail (2.3445.8.2)

On 24. Jul 2018, at 20:43, Hans Hagen <j.hagen@xs4all.nl> wrote:

> Hi,
> 
> […]
> That said, a logical question is how about next versions of context.
> Are there fundamental features missing? Is more needed? […]

At the risk of sounding like a scratched, repeating gramophone record
-- support for Indic scripts would be wonderful.

RZ
_______________________________________________________________________
____________
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
_______________________________________________________________________
____________
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: future versions

[Hans Hagen]

On 7/25/2018 3:29 AM, Rik Kabel wrote:
> On 7/24/2018 14:43, Hans Hagen wrote:

> 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'll add some structure to publications but styling is upto a css and 
will never be part of the export (so on ehas to use 'detail' etc then).

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

Indeed. So basic subtags is one thing. The other is including the whole 
blob for whatever usage.

> 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.
This needs more thinking.

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
___________________________________________________________________________________

Re: future versions

[Hans Hagen]

On 7/25/2018 9:45 AM, Robert Zydenbos wrote:
> On 24. Jul 2018, at 20:43, Hans Hagen <j.hagen@xs4all.nl> wrote:
> 
>> Hi,
>>
>> […]
>> That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? […]
> 
> At the risk of sounding like a scratched, repeating gramophone record -- support for Indic scripts would be wonderful.
I know. There's only a small piece of definitions missing. So that will 
happen eventually. (Kai is looking into that as he also has sample texts.)

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
___________________________________________________________________________________

Re: future versions

[Hans Hagen]

On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:
> Agree wholeheartedly, and possibly also support for Tibetan.
define support ... what is needed

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

Re: future versions

[Weber, Matthias]

I have an entirely different suggestion, possibly fitting the description of a possible  “lean” version.

One important feature of TeX has been the longevity of the documents. This is of course of little interest to those of us who
typeset a book/journal for publishing and care little about it when it’s done. But there is an interest in keeping the documents available in the long term,
meaning decades and possibly centuries (making assumptions about the human race here).  TeX has survived the transition from dvi/ps to pdf, and it is probably fair
to assume that pdf won’t be around forever. But it is probably also fair to assume that there will be straightforward ways to generate from TeX sources documents in a
future PDF replacement. 
This is in particular of concern in the scientific community where mathematical/physical/chemical formulas and diagrams are very hard to parse semantically
(which, admittedly, might change in the future, too). For instance, the preprint server at arXiv.org has been storing scientific preprints since 1991, preferably in TeX or LaTeX.
It would be an enormous benefit if the arXiv would accept a ConTeXt version. Scientific journals might then follow suit. 
At the moment I believe they use LaTeX from TeXLive 2016. 

It is of course a question whether a potentially much larger user base is desirable, because it likely means more requests for support/documentation etc.

In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be  retypeset over years
(like my lecture notes that need an update every few years).

Matthias

> On Jul 25, 2018, at 8:50 AM, Hans Hagen <j.hagen@xs4all.nl> wrote:
> 
> On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:
>> Agree wholeheartedly, and possibly also support for Tibetan.
> define support ... what is needed
> 
> -----------------------------------------------------------------
>                                          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
> ___________________________________________________________________________________

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

Re: future versions

[Rik Kabel]

On 7/25/2018 04:19, Henning Hraban Ramm wrote:
> Am 2018-07-25 um 03:29 schrieb Rik Kabel <context@rik.users.panix.com>:
>
>> 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.
> Generally, you get stylistic tagging by using \definehighlight.
> I replaced \em and \bf by \emph{} and \strong{} in my projects.
>
> Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
>

\definehighlight does not (by default) nest. You can handle this to some 
degree in css or xslt for XML exports, but it is not an acceptable 
replacement for font switches with pdf output. And since the syntax for 
highlights ( \highlight{text} ) differs from that for font switches ( 
{\highlight text} ), it is not simply a matter of different environments 
for each output format, although perhaps \groupedcommand might help (I 
have not tried this).

But that is in some ways beside the point. A user should not have to 
find and modify every instance in the source where such setups occur. 
When exports or tagging are enabled, it would be good if this were 
automatically done.

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

Re: future versions

[Hans Hagen]

On 7/25/2018 3:50 PM, Rik Kabel wrote:
> On 7/25/2018 04:19, Henning Hraban Ramm wrote:
>> Am 2018-07-25 um 03:29 schrieb Rik Kabel <context@rik.users.panix.com>:
>>
>>> 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.
>> Generally, you get stylistic tagging by using \definehighlight.
>> I replaced \em and \bf by \emph{} and \strong{} in my projects.
>>
>> Didn’t try real bibliographies or xml input yet, but I guess you can 
>> change the setup to use those.
>>
> 
> \definehighlight does not (by default) nest. You can handle this to some 
> degree in css or xslt for XML exports, but it is not an acceptable 
> replacement for font switches with pdf output. And since the syntax for 
> highlights ( \highlight{text} ) differs from that for font switches ( 
> {\highlight text} ), it is not simply a matter of different environments 
> for each output format, although perhaps \groupedcommand might help (I 
> have not tried this).
font switches using 'style' are bound to a structural element

> But that is in some ways beside the point. A user should not have to 
> find and modify every instance in the source where such setups occur. 
> When exports or tagging are enabled, it would be good if this were 
> automatically done.
you can't expect reliable structure from non-structured input so if you 
want an export that is ok, the penalty is proper structuring

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
___________________________________________________________________________________

Re: future versions

[Alan Braslau]

On Wed, 25 Jul 2018 09:50:58 -0400
Rik Kabel <context@rik.users.panix.com> wrote:

> On 7/25/2018 04:19, Henning Hraban Ramm wrote:
> > Am 2018-07-25 um 03:29 schrieb Rik Kabel
> > <context@rik.users.panix.com>: 
> >> 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.  
> > Generally, you get stylistic tagging by using \definehighlight.
> > I replaced \em and \bf by \emph{} and \strong{} in my projects.
> >
> > Didn’t try real bibliographies or xml input yet, but I guess you
> > can change the setup to use those. 
> 
> \definehighlight does not (by default) nest. You can handle this to
> some degree in css or xslt for XML exports, but it is not an
> acceptable replacement for font switches with pdf output. And since
> the syntax for highlights ( \highlight{text} ) differs from that for
> font switches ( {\highlight text} ), it is not simply a matter of
> different environments for each output format, although perhaps
> \groupedcommand might help (I have not tried this).
> 
> But that is in some ways beside the point. A user should not have to 
> find and modify every instance in the source where such setups occur. 
> When exports or tagging are enabled, it would be good if this were 
> automatically done.
> 

Do you know about

\savebtxdataset
  [default]
  [bibliography.xml]
  [alternative=xml,
   criterium=all]

You can thus save your bibliography data for use, rather than or in
addition to the rendered list.

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

Re: future versions

[Hans Hagen]

On 7/25/2018 6:18 PM, Alan Braslau wrote:
> On Wed, 25 Jul 2018 09:50:58 -0400
> Rik Kabel <context@rik.users.panix.com> wrote:
> 
>> On 7/25/2018 04:19, Henning Hraban Ramm wrote:
>>> Am 2018-07-25 um 03:29 schrieb Rik Kabel
>>> <context@rik.users.panix.com>:
>>>> 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.
>>> Generally, you get stylistic tagging by using \definehighlight.
>>> I replaced \em and \bf by \emph{} and \strong{} in my projects.
>>>
>>> Didn’t try real bibliographies or xml input yet, but I guess you
>>> can change the setup to use those.
>>
>> \definehighlight does not (by default) nest. You can handle this to
>> some degree in css or xslt for XML exports, but it is not an
>> acceptable replacement for font switches with pdf output. And since
>> the syntax for highlights ( \highlight{text} ) differs from that for
>> font switches ( {\highlight text} ), it is not simply a matter of
>> different environments for each output format, although perhaps
>> \groupedcommand might help (I have not tried this).
>>
>> But that is in some ways beside the point. A user should not have to
>> find and modify every instance in the source where such setups occur.
>> When exports or tagging are enabled, it would be good if this were
>> automatically done.
>>
> 
> Do you know about
> 
> \savebtxdataset
>    [default]
>    [bibliography.xml]
>    [alternative=xml,
>     criterium=all]
> 
> You can thus save your bibliography data for use, rather than or in
> addition to the rendered list.
I'll upload a beta with

- tagged publications
- embedded bib data in xml format and bibtex format

that should be enough for postprocessing magic. Of course we cannot 
catch cases where users mess around with specific setups which is no big 
deal as fo rexporting purposes one can use a simple standard style.

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
___________________________________________________________________________________

Re: future versions

[Hans Hagen]

On 7/25/2018 3:12 PM, Weber, Matthias wrote:
> I have an entirely different suggestion, possibly fitting the description of a possible  “lean” version.
> 
> One important feature of TeX has been the longevity of the documents. This is of course of little interest to those of us who
> typeset a book/journal for publishing and care little about it when it’s done. But there is an interest in keeping the documents available in the long term,
> meaning decades and possibly centuries (making assumptions about the human race here).  TeX has survived the transition from dvi/ps to pdf, and it is probably fair
> to assume that pdf won’t be around forever. But it is probably also fair to assume that there will be straightforward ways to generate from TeX sources documents in a
> future PDF replacement.

so far no replacemtn showed up (ok, html is an alternatiev but that's a 
different thing) .. even pdf 2.0 (which we support) isn't revolutionary 
different from 1.7

> This is in particular of concern in the scientific community where mathematical/physical/chemical formulas and diagrams are very hard to parse semantically
> (which, admittedly, might change in the future, too). For instance, the preprint server at arXiv.org has been storing scientific preprints since 1991, preferably in TeX or LaTeX.
> It would be an enormous benefit if the arXiv would accept a ConTeXt version. Scientific journals might then follow suit.
> At the moment I believe they use LaTeX from TeXLive 2016.
> 
> It is of course a question whether a potentially much larger user base is desirable, because it likely means more requests for support/documentation etc.

I don't think that a larger user base is a problem. It might actually 
trigger users into writing more manuals, wiki entries, tutorials. But 
'marketing' in a world where tex is equivalent to latex is not trivial.

> In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be  retypeset over years
> (like my lecture notes that need an update every few years).

When we have luatex 1.10 that will be easier because older code can run 
on a newer engine then.

But even then, if we make snapshots that can be downloaded for a long 
time, we need some way to recognize them (by year?).

Using snapshots in parallel is no big deal. One problem is that one also 
needs to save the fonts (it will probably take a few years before the 
lm/gyre collection is long term stable).

> Matthias
> 
>> On Jul 25, 2018, at 8:50 AM, Hans Hagen <j.hagen@xs4all.nl> wrote:
>>
>> On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:
>>> Agree wholeheartedly, and possibly also support for Tibetan.
>> define support ... what is needed
>>
>> -----------------------------------------------------------------
>>                                           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
>> ___________________________________________________________________________________
> 
> ___________________________________________________________________________________
> 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
> ___________________________________________________________________________________
> 


-- 

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

Re: future versions

[Henning Hraban Ramm]

Am 2018-07-25 um 19:50 schrieb Hans Hagen <j.hagen@xs4all.nl>:

>> In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be  retypeset over years
>> (like my lecture notes that need an update every few years).
> 
> When we have luatex 1.10 that will be easier because older code can run on a newer engine then.
> 
> But even then, if we make snapshots that can be downloaded for a long time, we need some way to recognize them (by year?).

LilyPond (as a somewhat similar program) requires a version statement in every source file; and then there’s a converter script that understands and updates all constructs that are part of the official syntax - of course, if you use custom scripting (Scheme in this case), you are on your own again.

Greetlings, Hraban
---
https://www.fiee.net
http://wiki.contextgarden.net
https://www.dreiviertelhaus.de
GPG Key ID 1C9B22FD

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

Re: future versions - synctex

[Procházka Lukáš Ing.]

Hello,

a bit later - I was thinking if to react here, after reading all about synctex and complicated support for complicatedly assembled source files - but my personal experience/wish...

> On 7/24/2018 11:02 PM, Idris Samawi Hamid ادريس سماوي حامد wrote:
>> Hi Hans, all,
>
>> One needed feature that would be of general use is better support for
>> synctex. Thinking especially of structural elements such as headings,
>> footnotes, etc. which mostly do not work with synctex - i.e., clicking
>> on these elements in the pdf do not take one back to the correct
>> location in the relevant TEX file.

When building a document (or more precisely: documentation which consists of many documents), I'm widely referring to other files via \input, \component etc., I'm widely using \defs, \defines and \buffers defined in separate files (as these defs are used at more places - so let them being defined in one source file) and I'm often generating texts by Lua (e.g. tables - being read and parsed from a text in a \start/\stopluacode block or e.g. Excel named range read via LuaXls or from a .xml - and typeset by a Lua function, which allows simply change all \NC into \VL in a particular place).

The lengthy process is to EDIT (almost) finished docs/documentation. And at this place, it would be very handy if synctex worked. So I vote for a better click-in-PDF-go-to-source support.

On Wed, 25 Jul 2018 01:21:48 +0200, Hans Hagen <j.hagen@xs4all.nl> wrote:

> Synctex is a beast. Basically it is not that useable for context which
> is why we have a different implementation with a rather clean, minimal,
> and predictable output. Unfortunately the usual approahc is to use a
> library for interoreting the synctex files which has too much heuristics
> built in. More flexible would be to let the viewer cann an external
> program which then can interpret the synctex file based on a page and
> position. This also would make it possible to have more clever
> synchronization and/or adapt to a macro package. Anyway, were sort of
> stuck and can only try to make the best of it.
>
> That said, the context generated synctex file is nornally okay unless we
> render from lua, which happens for instance with titles. Just try
>
> \ctxlua{context("foo bar")}
>
> and you will also see that there is no line related positioning.
> Tweaking luatex for this is not really an options because whatever
> decision we make here will backfire at some point. (I can look into some
> option later but it needs bit of thinking)

I don't know anything deep about how sync is provided. But my layman point of view would be that whenever a character (or a "box") is to be placed on the page (or into output stream), ConTeXt should know which is the "deepest - currently read" source file, the line, moreover the column - and that position could result into "pick-and-go" position.

In this approach - "boxes" generated by Lua-in-ConTeXt should "jump" on \startluacode, \ctxlua, \cldcommand statement...

> Anyway, i can cheat at the tex/lua end if needed and support e.g. titles
> but i'm not going to pollute the code with every place where we come
> from lua (also because in most cases there is no relation with the
> source anyway then). Also, I will not add code that can have an impact
> on performance when synctex is turned off.

Synctex should be turned on/off before source files are compiled into PDF - via command line option "--synctex" or \enabledirectives[system.synctex] before \starttext (\enabledirectives[system.synctex] after \starttext (\startcomponent) should be ignored?) - that could cause hooking picked Lua functions (or taking their "synctex-on" alternatives) - so normally (with synctex off) there wouldn't be any performance impact; worse performance would come only with synctex on - but it's user's choice.

> But for a subset of
> constructs that are relatively short in usage it is doable (but doesn't
> really qualify as fun -- also, i don't use it myself).

Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user "tunes" the docs to their final stage, would be great.

Best regards,

Lukas

> (One complication is that for instance fixing it for some constructs
> will break it for xml input which also supports synctex.)
>
> Hans


-- 
Ing. Lukáš Procházka | mailto:LPr@pontex.cz
Pontex s. r. o.      | mailto:pontex@pontex.cz | http://www.pontex.cz | IDDS:nrpt3sn
Bezová 1658
147 14 Praha 4

Mob.: +420 702 033 396

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

Re: future versions - synctex

[Hans Hagen]

On 8/21/2018 10:00 AM, Procházka Lukáš Ing. wrote:

> When building a document (or more precisely: documentation which 
> consists of many documents), I'm widely referring to other files via 
> \input, \component etc., I'm widely using \defs, \defines and \buffers 
> defined in separate files (as these defs are used at more places - so 
> let them being defined in one source file) and I'm often generating 
> texts by Lua (e.g. tables - being read and parsed from a text in a 
> \start/\stopluacode block or e.g. Excel named range read via LuaXls or 
> from a .xml - and typeset by a Lua function, which allows simply change 
> all \NC into \VL in a particular place).
> 
> The lengthy process is to EDIT (almost) finished docs/documentation. And 
> at this place, it would be very handy if synctex worked. So I vote for a 
> better click-in-PDF-go-to-source support.

in principle you can push  / pop input states but for such a variety of 
input you have to do that yourself in the styles ... and it will quickly 
become a performance issue then

the core will not get that kind of hard coded synctex flip-flopping

fwiw, the xml sub mechanism does support that kind of functionality as 
option (only because a collegue uses xml with deeply nested inclusions 
spread all over a direcory structure)

> I don't know anything deep about how sync is provided. But my layman 
> point of view would be that whenever a character (or a "box") is to be 
> placed on the page (or into output stream), ConTeXt should know which is 
> the "deepest - currently read" source file, the line, moreover the 
> column - and that position could result into "pick-and-go" position.

only partly ... you don't know where a macro comes from (or what lua 
code generated something) and it makes no sense either to go bakc to 
some macro ... in fact, synctex support in context blocks going to 
styles because those who edit files are not supposed to change styles

things like headers and footers come from styles, not user input

and even much structure stuff comes from elsewhere (like titles of 
sections: they go via lua so there we already need to cheat input 
registration)

> In this approach - "boxes" generated by Lua-in-ConTeXt should "jump" on 
> \startluacode, \ctxlua, \cldcommand statement...

won't happen ... way too much overhead and it would polute the source 
too (i follow the principle that any new mechanism that gets added will 
not slow down compilation in a measurable way)

>> Anyway, i can cheat at the tex/lua end if needed and support e.g. titles
>> but i'm not going to pollute the code with every place where we come
>> from lua (also because in most cases there is no relation with the
>> source anyway then). Also, I will not add code that can have an impact
>> on performance when synctex is turned off.
> 
> Synctex should be turned on/off before source files are compiled into 
> PDF - via command line option "--synctex" or 
> \enabledirectives[system.synctex] before \starttext 
> (\enabledirectives[system.synctex] after \starttext (\startcomponent) 
> should be ignored?) - that could cause hooking picked Lua functions (or 
> taking their "synctex-on" alternatives) - so normally (with synctex off) 
> there wouldn't be any performance impact; worse performance would come 
> only with synctex on - but it's user's choice.
> 
>> But for a subset of
>> constructs that are relatively short in usage it is doable (but doesn't
>> really qualify as fun -- also, i don't use it myself).
> 
> Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), 
> namely when user "tunes" the docs to their final stage, would be great.
I think that the current approach to hard code synctex libraries into a 
viewer is a limitation (instead an editor should call an external 
program with the page and coordinates so that an external program can 
then look at the synctex file and decide where to go in the editor. That 
way more sophisticated support is possible than the now hard coded 
heuristics. Keep in mind that these heuristics are tuned for latex and 
from context we generate the real minimal amount of synctex code that 
works without clashing with these heuristics. If that were not that case 
is would be unuseable.

Anyhow, there's only so much i can do about it (i'm not going to patch 
viewers). Currently synctex is mostly working for decent structured 
source (can be multiple files).

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
___________________________________________________________________________________

Re: future versions - synctex

[Aditya Mahajan]

On Tue, 21 Aug 2018, Hans Hagen wrote:

>> Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), 
>> namely when user "tunes" the docs to their final stage, would be great.
> I think that the current approach to hard code synctex libraries into a 
> viewer is a limitation (instead an editor should call an external 
> program with the page and coordinates so that an external program can 
> then look at the synctex file and decide where to go in the editor. That 
> way more sophisticated support is possible than the now hard coded 
> heuristics. Keep in mind that these heuristics are tuned for latex and 
> from context we generate the real minimal amount of synctex code that 
> works without clashing with these heuristics. If that were not that case 
> is would be unuseable.
>
> Anyhow, there's only so much i can do about it (i'm not going to patch 
> viewers). Currently synctex is mostly working for decent structured 
> source (can be multiple files).

Which of the existing viewers have this functionality? Last time I tried 
using synctex on linux, almost all viewers gave an error that they could 
not parse synctex file.

Is there some documentation on what is the format of the synctex file 
written by ConTeXt and how the external program should be called with page 
and coordinates? With that we can try to raise an issue asking the pdf 
viewers to support that.

Thanks,
Aditya
___________________________________________________________________________________
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
___________________________________________________________________________________

Re: future versions - synctex

[Hans Hagen]

On 8/21/2018 3:04 PM, Aditya Mahajan wrote:
> On Tue, 21 Aug 2018, Hans Hagen wrote:
> 
>>> Anyway, a better support for "pick-in-PDF-and-go-to-source" 
>>> (synctex), namely when user "tunes" the docs to their final stage, 
>>> would be great.
>> I think that the current approach to hard code synctex libraries into 
>> a viewer is a limitation (instead an editor should call an external 
>> program with the page and coordinates so that an external program can 
>> then look at the synctex file and decide where to go in the editor. 
>> That way more sophisticated support is possible than the now hard 
>> coded heuristics. Keep in mind that these heuristics are tuned for 
>> latex and from context we generate the real minimal amount of synctex 
>> code that works without clashing with these heuristics. If that were 
>> not that case is would be unuseable.
>>
>> Anyhow, there's only so much i can do about it (i'm not going to patch 
>> viewers). Currently synctex is mostly working for decent structured 
>> source (can be multiple files).
> 
> Which of the existing viewers have this functionality? Last time I tried 
> using synctex on linux, almost all viewers gave an error that they could 
> not parse synctex file.

I think that is because the format of the synctex file changed.

> Is there some documentation on what is the format of the synctex file 
> written by ConTeXt and how the external program should be called with 
> page and coordinates? With that we can try to raise an issue asking the 
> pdf viewers to support that.

context outputs a bare minimum of synctex info: basically it identifies 
text and marks that, so we don't need the whole nested box mess that can 
confuse the parser (think of boxes that lap or are moved or lie about 
dimensions)

is you have a context synctex file you only see a few levels (basically 
words / lines) marked

There is a script:

mtxrun --script synctex

basically all an editor has to do is call:

mtxrun --script synctex
   --page=123 --x=400 --y=500
   --editor=scite
   foo.synctex

the script will look into the synctex file and figure out where to go 
to. Basically all the viewer needs to do is react to a click/cursor/key 
combination and call mtxrun .... with the page and positions (basepoints 
in pdf coordinate space)

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
___________________________________________________________________________________

Re: future versions - synctex

[Aditya Mahajan]

On Tue, 21 Aug 2018, Hans Hagen wrote:

> On 8/21/2018 3:04 PM, Aditya Mahajan wrote:
>> On Tue, 21 Aug 2018, Hans Hagen wrote:
>> 
>>>> Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), 
>>>> namely when user "tunes" the docs to their final stage, would be great.
>>> I think that the current approach to hard code synctex libraries into a 
>>> viewer is a limitation (instead an editor should call an external program 
>>> with the page and coordinates so that an external program can then look at 
>>> the synctex file and decide where to go in the editor. That way more 
>>> sophisticated support is possible than the now hard coded heuristics. Keep 
>>> in mind that these heuristics are tuned for latex and from context we 
>>> generate the real minimal amount of synctex code that works without 
>>> clashing with these heuristics. If that were not that case is would be 
>>> unuseable.
>>> 
>>> Anyhow, there's only so much i can do about it (i'm not going to patch 
>>> viewers). Currently synctex is mostly working for decent structured source 
>>> (can be multiple files).
>> 
>> Which of the existing viewers have this functionality? Last time I tried 
>> using synctex on linux, almost all viewers gave an error that they could 
>> not parse synctex file.
>
> I think that is because the format of the synctex file changed.
>
>> Is there some documentation on what is the format of the synctex file 
>> written by ConTeXt and how the external program should be called with page 
>> and coordinates? With that we can try to raise an issue asking the pdf 
>> viewers to support that.
>
> context outputs a bare minimum of synctex info: basically it identifies text 
> and marks that, so we don't need the whole nested box mess that can confuse 
> the parser (think of boxes that lap or are moved or lie about dimensions)
>
> is you have a context synctex file you only see a few levels (basically words 
> / lines) marked
>
> There is a script:
>
> mtxrun --script synctex
>
> basically all an editor has to do is call:
>
> mtxrun --script synctex
>  --page=123 --x=400 --y=500
>  --editor=scite
>  foo.synctex

Are the x and y values in pts (post script points or big points?) 
measured from the top-left corner?

> the script will look into the synctex file and figure out where to go to. 
> Basically all the viewer needs to do is react to a click/cursor/key 
> combination and call mtxrun .... with the page and positions (basepoints in 
> pdf coordinate space)

How do I configure the editor command, e.g., with VIM, mtxrun will need to 
call:

`vim --servername=VIM --remote +{line_number} {filename}`

What should be the value of `editor` in this case?

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

Re: future versions - synctex

[Hans Hagen]

On 8/21/2018 4:46 PM, Aditya Mahajan wrote:

> Are the x and y values in pts (post script points or big points?) 
> measured from the top-left corner?

afaik bottom up base points

>> the script will look into the synctex file and figure out where to go 
>> to. Basically all the viewer needs to do is react to a 
>> click/cursor/key combination and call mtxrun .... with the page and 
>> positions (basepoints in pdf coordinate space)
> 
> How do I configure the editor command, e.g., with VIM, mtxrun will need 
> to call:
> 
> `vim --servername=VIM --remote +{line_number} {filename}`
> 
> What should be the value of `editor` in this case?
vim

but we can of course make that configureable (easy in lua) .. see 
mtx-synctex.lua

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