Re: [NTG-context] future versions - synctex

2018-08-21 Thread Hans Hagen

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

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


afaik bottom up base points

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


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


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

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

vim

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


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions - synctex

2018-08-21 Thread Aditya Mahajan

On Tue, 21 Aug 2018, Hans Hagen wrote:


On 8/21/2018 3:04 PM, Aditya Mahajan wrote:

On Tue, 21 Aug 2018, Hans Hagen wrote:

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


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


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


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

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


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


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


There is a script:

mtxrun --script synctex

basically all an editor has to do is call:

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


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


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


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


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

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

Aditya
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions - synctex

2018-08-21 Thread Hans Hagen

On 8/21/2018 3:04 PM, Aditya Mahajan wrote:

On Tue, 21 Aug 2018, Hans Hagen wrote:

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


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


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


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

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


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


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


There is a script:

mtxrun --script synctex

basically all an editor has to do is call:

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

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


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions - synctex

2018-08-21 Thread Aditya Mahajan

On Tue, 21 Aug 2018, Hans Hagen wrote:

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


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


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


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


Thanks,
Aditya
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions - synctex

2018-08-21 Thread Hans Hagen

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

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


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


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


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

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


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


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


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

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


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


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



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


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



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


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


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


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / 

Re: [NTG-context] future versions - synctex

2018-08-21 Thread Procházka Lukáš Ing .

Hello,

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


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

Hi Hans, all,



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


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

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

On Wed, 25 Jul 2018 01:21:48 +0200, Hans Hagen  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

2018-07-25 Thread Henning Hraban Ramm
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

2018-07-25 Thread Hans Hagen

On 7/25/2018 3:12 PM, Weber, Matthias wrote:

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

One important feature of TeX has been the longevity of the documents. This is 
of course of little interest to those of us who
typeset a book/journal for publishing and care little about it when it’s done. 
But there is an interest in keeping the documents available in the long term,
meaning decades and possibly centuries (making assumptions about the human race 
here).  TeX has survived the transition from dvi/ps to pdf, and it is probably 
fair
to assume that pdf won’t be around forever. But it is probably also fair to 
assume that there will be straightforward ways to generate from TeX sources 
documents in a
future PDF replacement.


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



This is in particular of concern in the scientific community where 
mathematical/physical/chemical formulas and diagrams are very hard to parse 
semantically
(which, admittedly, might change in the future, too). For instance, the 
preprint server at arXiv.org has been storing scientific preprints since 1991, 
preferably in TeX or LaTeX.
It would be an enormous benefit if the arXiv would accept a ConTeXt version. 
Scientific journals might then follow suit.
At the moment I believe they use LaTeX from TeXLive 2016.

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


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



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


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


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


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



Matthias


On Jul 25, 2018, at 8:50 AM, Hans Hagen  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

2018-07-25 Thread Hans Hagen

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

2018-07-25 Thread Alan Braslau
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

2018-07-25 Thread Hans Hagen

On 7/25/2018 3:50 PM, Rik Kabel wrote:

On 7/25/2018 04:19, Henning Hraban Ramm wrote:

Am 2018-07-25 um 03:29 schrieb Rik Kabel :

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

2018-07-25 Thread Rik Kabel

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

2018-07-25 Thread Weber, Matthias
I have an entirely different suggestion, possibly fitting the description of a 
possible  “lean” version.

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

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

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

Matthias

> On Jul 25, 2018, at 8:50 AM, Hans Hagen  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

2018-07-25 Thread Hans Hagen

On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:

Agree wholeheartedly, and possibly also support for Tibetan.

define support ... what is needed

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-25 Thread Hans Hagen

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

2018-07-25 Thread Hans Hagen

On 7/25/2018 3:29 AM, Rik Kabel wrote:

On 7/24/2018 14:43, Hans Hagen wrote:


I would ask for more stylistic or semantic tagging to be added to the 
XML export. A good example is that of bibliographies, where font styles 
carry significant semantic meaning (depending on the standard used: 
italic for book titles, ibold or talic for volume and issue numbers, and 
so on.) The xml output reflects none of this.


I'll add some structure to publications but styling is upto a css and 
will never be part of the export (so on ehas to use 'detail' etc then).


I do not know whether one would want stylistic tagging (italic, bold, 
...) or semantic (booktitle, issue number). In either case, they could 
be implemented as highlights or tagged elements, both of which are 
currently carried through, and the user could then apply the appropriate 
styling with css or other transformation mechanisms.


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


The ability to point register entries to something other than page 
numbers would also be useful. For export formats (XML) this requires 
that label references be part of the export.

This needs more thinking.

Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-25 Thread Richard Mahoney | Indica et Buddhica
Agree wholeheartedly, and possibly also support for Tibetan.


Best, Richard



-- 
Richard Mahoney - Indica et Buddhica 
Littledene Bay Road Oxford New Zealand 
T: +64 3 312 1699 M: +64 210 640 216 
r.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

2018-07-25 Thread Henning Hraban Ramm
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

2018-07-25 Thread Robert Zydenbos
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

2018-07-24 Thread Rik Kabel

On 7/24/2018 14:43, Hans Hagen wrote:

Hi,

Around the upcoming context meeting we expect to release luatex 1.09 
(or 1.10 ... yet undecided) which is the prelude to the next year tex 
live version. It's another step towards a stable version in terms of 
functionality as we don't expect much more to be added (in fact, I'm 
wondering if it makes sense to come up with a leaner and meaner 
version at some point because context can probably benefit from that). 
Of course under the hood there are improvements possible and we have 
some ideas (that might materialize at some point) but generally 
spoken, this is what one gets.


That said, a logical question is how about next versions of context. 
Are there fundamental features missing? Is more needed? Keep in mind 
that we're not talking of desk top publishing (click and point and 
place stuff) and also not of word processing (office like stuff) but 
of mostly automated structured document rendering. Also, keep in mind 
the landscape that we operate in (context development is mostly user 
driven as publishers imo long ago lost interest in any research and 
development and the potential of tex and friends is largely unknown 
elsewhere).


It's not my intention to implement each possible feature as core 
feature (no one would document it anyway). Also, as development is 
basically a spare time effort, don't expect complex commercially 
interesting niches to come for free either as in that case one can 
wait till I a find a reason for implementing it for fun or development 
is driven by a project.


When thinking of future additions, tex, lua, metapost of a mix is 
possible. They should be of interest for more than one user. Of course 
it can also be that everything needed is there. Maybe existing 
mechanisms can be improved in terms of functionality or performance 
(although i think that performance wise we're ok). But again keep in 
mind that the boundary conditions (all these interacting sub 
mechanisms) also prohibit some functionality.


Hans

I would ask for more stylistic or semantic tagging to be added to the 
XML export. A good example is that of bibliographies, where font styles 
carry significant semantic meaning (depending on the standard used: 
italic for book titles, ibold or talic for volume and issue numbers, and 
so on.) The xml output reflects none of this.


I do not know whether one would want stylistic tagging (italic, bold, 
...) or semantic (booktitle, issue number). In either case, they could 
be implemented as highlights or tagged elements, both of which are 
currently carried through, and the user could then apply the appropriate 
styling with css or other transformation mechanisms.


The ability to point register entries to something other than page 
numbers would also be useful. For export formats (XML) this requires 
that label references be part of the export.


--
Rik


___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-24 Thread Hans Hagen

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

Hi Hans, all,


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


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


\ctxlua{context("foo bar")}

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


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


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


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
   tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
-
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-24 Thread Idris Samawi Hamid ادريس سماوي حامد

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

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

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

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

Pablo
-- 
http://www.ousia.tk
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-24 Thread Pablo Rodriguez
On 07/24/2018 08:43 PM, Hans Hagen wrote:
> [...] 
> It's not my intention to implement each possible feature as core feature 
> (no one would document it anyway). Also, as development is basically a 
> spare time effort, don't expect complex commercially interesting niches 
> to come for free either as in that case one can wait till I a find a 
> reason for implementing it for fun or development is driven by a project.

Hans,

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

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

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

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

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

Pablo
-- 
http://www.ousia.tk
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://context.aanhet.net
archive  : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___

Re: [NTG-context] future versions

2018-07-24 Thread Hans van der Meer
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
___