* future versions
@ 2018-07-24 18:43 Hans Hagen
2018-07-24 19:07 ` Hans van der Meer
` (4 more replies)
0 siblings, 5 replies; 26+ messages in thread
From: Hans Hagen @ 2018-07-24 18:43 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 18:43 future versions 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
` (3 subsequent siblings)
4 siblings, 1 reply; 26+ messages in thread
From: Hans van der Meer @ 2018-07-24 19:07 UTC (permalink / raw)
To: NTG ConTeXt
[-- 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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 18:43 future versions Hans Hagen
2018-07-24 19:07 ` Hans van der Meer
@ 2018-07-24 20:30 ` Pablo Rodriguez
2018-07-24 21:02 ` Idris Samawi Hamid ادريس سماوي حامد
` (2 subsequent siblings)
4 siblings, 0 replies; 26+ messages in thread
From: Pablo Rodriguez @ 2018-07-24 20:30 UTC (permalink / raw)
To: ntg-context
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 19:07 ` Hans van der Meer
@ 2018-07-24 20:35 ` Pablo Rodriguez
0 siblings, 0 replies; 26+ messages in thread
From: Pablo Rodriguez @ 2018-07-24 20:35 UTC (permalink / raw)
To: ntg-context
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 18:43 future versions Hans Hagen
2018-07-24 19:07 ` Hans van der Meer
2018-07-24 20:30 ` Pablo Rodriguez
@ 2018-07-24 21:02 ` Idris Samawi Hamid ادريس سماوي حامد
2018-07-24 23:21 ` Hans Hagen
2018-07-25 1:29 ` future versions Rik Kabel
2018-07-25 7:45 ` Robert Zydenbos
4 siblings, 1 reply; 26+ messages in thread
From: Idris Samawi Hamid ادريس سماوي حامد @ 2018-07-24 21:02 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
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.
0 siblings, 1 reply; 26+ messages in thread
From: Hans Hagen @ 2018-07-24 23:21 UTC (permalink / raw)
To: mailing list for ConTeXt users,
Idris Samawi Hamid ادريس
سماوي حامد
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 18:43 future versions Hans Hagen
` (2 preceding siblings ...)
2018-07-24 21:02 ` Idris Samawi Hamid ادريس سماوي حامد
@ 2018-07-25 1:29 ` Rik Kabel
2018-07-25 8:19 ` Henning Hraban Ramm
2018-07-25 11:36 ` Hans Hagen
2018-07-25 7:45 ` Robert Zydenbos
4 siblings, 2 replies; 26+ messages in thread
From: Rik Kabel @ 2018-07-25 1:29 UTC (permalink / raw)
To: ntg-context
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-24 18:43 future versions Hans Hagen
` (3 preceding siblings ...)
2018-07-25 1:29 ` future versions Rik Kabel
@ 2018-07-25 7:45 ` Robert Zydenbos
2018-07-25 10:03 ` Richard Mahoney | Indica et Buddhica
2018-07-25 11:38 ` Hans Hagen
4 siblings, 2 replies; 26+ messages in thread
From: Robert Zydenbos @ 2018-07-25 7:45 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 1:29 ` future versions Rik Kabel
@ 2018-07-25 8:19 ` Henning Hraban Ramm
2018-07-25 13:50 ` Rik Kabel
2018-07-25 11:36 ` Hans Hagen
1 sibling, 1 reply; 26+ messages in thread
From: Henning Hraban Ramm @ 2018-07-25 8:19 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
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 11:38 ` Hans Hagen
1 sibling, 1 reply; 26+ messages in thread
From: Richard Mahoney | Indica et Buddhica @ 2018-07-25 10:03 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 1:29 ` future versions Rik Kabel
2018-07-25 8:19 ` Henning Hraban Ramm
@ 2018-07-25 11:36 ` Hans Hagen
1 sibling, 0 replies; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 11:36 UTC (permalink / raw)
To: mailing list for ConTeXt users, Rik Kabel
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 7:45 ` Robert Zydenbos
2018-07-25 10:03 ` Richard Mahoney | Indica et Buddhica
@ 2018-07-25 11:38 ` Hans Hagen
1 sibling, 0 replies; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 11:38 UTC (permalink / raw)
To: mailing list for ConTeXt users, Robert Zydenbos
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 10:03 ` Richard Mahoney | Indica et Buddhica
@ 2018-07-25 12:50 ` Hans Hagen
2018-07-25 13:12 ` Weber, Matthias
0 siblings, 1 reply; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 12:50 UTC (permalink / raw)
To: mailing list for ConTeXt users, Richard Mahoney | Indica et Buddhica
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 12:50 ` Hans Hagen
@ 2018-07-25 13:12 ` Weber, Matthias
2018-07-25 17:50 ` Hans Hagen
0 siblings, 1 reply; 26+ messages in thread
From: Weber, Matthias @ 2018-07-25 13:12 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 8:19 ` Henning Hraban Ramm
@ 2018-07-25 13:50 ` Rik Kabel
2018-07-25 16:06 ` Hans Hagen
2018-07-25 16:18 ` Alan Braslau
0 siblings, 2 replies; 26+ messages in thread
From: Rik Kabel @ 2018-07-25 13:50 UTC (permalink / raw)
To: ntg-context
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 13:50 ` Rik Kabel
@ 2018-07-25 16:06 ` Hans Hagen
2018-07-25 16:18 ` Alan Braslau
1 sibling, 0 replies; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 16:06 UTC (permalink / raw)
To: mailing list for ConTeXt users, Rik Kabel
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
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
1 sibling, 1 reply; 26+ messages in thread
From: Alan Braslau @ 2018-07-25 16:18 UTC (permalink / raw)
To: Rik Kabel; +Cc: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 16:18 ` Alan Braslau
@ 2018-07-25 17:01 ` Hans Hagen
0 siblings, 0 replies; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 17:01 UTC (permalink / raw)
To: Alan Braslau, Rik Kabel; +Cc: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 13:12 ` Weber, Matthias
@ 2018-07-25 17:50 ` Hans Hagen
2018-07-25 20:22 ` Henning Hraban Ramm
0 siblings, 1 reply; 26+ messages in thread
From: Hans Hagen @ 2018-07-25 17:50 UTC (permalink / raw)
To: mailing list for ConTeXt users, Weber, Matthias
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions
2018-07-25 17:50 ` Hans Hagen
@ 2018-07-25 20:22 ` Henning Hraban Ramm
0 siblings, 0 replies; 26+ messages in thread
From: Henning Hraban Ramm @ 2018-07-25 20:22 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
2018-07-24 23:21 ` Hans Hagen
@ 2018-08-21 8:00 ` Procházka Lukáš Ing.
2018-08-21 8:33 ` Hans Hagen
0 siblings, 1 reply; 26+ messages in thread
From: Procházka Lukáš Ing. @ 2018-08-21 8:00 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
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
0 siblings, 1 reply; 26+ messages in thread
From: Hans Hagen @ 2018-08-21 8:33 UTC (permalink / raw)
To: mailing list for ConTeXt users, Procházka Lukáš Ing.
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
2018-08-21 8:33 ` Hans Hagen
@ 2018-08-21 13:04 ` Aditya Mahajan
2018-08-21 13:19 ` Hans Hagen
0 siblings, 1 reply; 26+ messages in thread
From: Aditya Mahajan @ 2018-08-21 13:04 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
2018-08-21 13:04 ` Aditya Mahajan
@ 2018-08-21 13:19 ` Hans Hagen
2018-08-21 14:46 ` Aditya Mahajan
0 siblings, 1 reply; 26+ messages in thread
From: Hans Hagen @ 2018-08-21 13:19 UTC (permalink / raw)
To: mailing list for ConTeXt users, Aditya Mahajan
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
2018-08-21 13:19 ` Hans Hagen
@ 2018-08-21 14:46 ` Aditya Mahajan
2018-08-21 15:17 ` Hans Hagen
0 siblings, 1 reply; 26+ messages in thread
From: Aditya Mahajan @ 2018-08-21 14:46 UTC (permalink / raw)
To: mailing list for ConTeXt users
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: future versions - synctex
2018-08-21 14:46 ` Aditya Mahajan
@ 2018-08-21 15:17 ` Hans Hagen
0 siblings, 0 replies; 26+ messages in thread
From: Hans Hagen @ 2018-08-21 15:17 UTC (permalink / raw)
To: mailing list for ConTeXt users, Aditya Mahajan
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
___________________________________________________________________________________
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2018-08-21 15:17 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-07-24 18:43 future versions 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 ` future versions Rik Kabel
2018-07-25 8:19 ` 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
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).