Re: [NTG-context] future versions - synctex
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
___
Re: [NTG-context] future versions - synctex
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: [NTG-context] future versions - synctex
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: [NTG-context] future versions - synctex
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: [NTG-context] future versions - synctex
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 /
Re: [NTG-context] future versions - synctex
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 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:l...@pontex.cz
Pontex s. r. o. | mailto:pon...@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: [NTG-context] future versions
Am 2018-07-25 um 19:50 schrieb Hans Hagen : >> 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: [NTG-context] future versions
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 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: [NTG-context] future versions
On 7/25/2018 6:18 PM, Alan Braslau wrote:
On Wed, 25 Jul 2018 09:50:58 -0400
Rik Kabel wrote:
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel
:
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: [NTG-context] future versions
On Wed, 25 Jul 2018 09:50:58 -0400
Rik Kabel wrote:
> On 7/25/2018 04:19, Henning Hraban Ramm wrote:
> > Am 2018-07-25 um 03:29 schrieb Rik Kabel
> > :
> >> 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: [NTG-context] future versions
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 :
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: [NTG-context] future versions
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel :
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: [NTG-context] future versions
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 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: [NTG-context] future versions
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: [NTG-context] future versions
On 7/25/2018 9:45 AM, Robert Zydenbos wrote: On 24. Jul 2018, at 20:43, Hans Hagen 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: [NTG-context] future versions
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: [NTG-context] future versions
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.maho...@indica-et-buddhica.org http://indica-et-buddhica.org/ -Original Message- From: Robert Zydenbos Reply-to: mailing list for ConTeXt users To: mailing list for ConTeXt users 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 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: [NTG-context] future versions
Am 2018-07-25 um 03:29 schrieb Rik Kabel :
> 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: [NTG-context] future versions
On 24. Jul 2018, at 20:43, Hans Hagen 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: [NTG-context] future versions
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: [NTG-context] future versions
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: [NTG-context] future versions
Hi Hans, all, On Tue, 24 Jul 2018 12:43:51 -0600, 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. 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: [NTG-context] future versions
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: [NTG-context] future versions
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: [NTG-context] future versions
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 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 > ___ ___ 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 ___
[NTG-context] future versions
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 ___
