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 -----------------------------------------------------------------
I am using XML a lot for structured data and typesetting them with hopefully not too much attention to detail — although I must confess often being a hopeless perfectionist. If there are general improvements that can be made in that direction, I would welcome them. Although I apologise not being able to propose concrete suggestions at the moment, I hope this post will incite those more knowledgeable than me, to do so. They are thanked beforehand.
Hans van der Meer
On 24 Jul 2018, at 20:43, Hans Hagen j.hagen@xs4all.nl wrote:
Hi,
Around the upcoming context meeting we expect to release luatex 1.09 (or 1.10 ... yet undecided) which is the prelude to the next year tex live version. It's another step towards a stable version in terms of functionality as we don't expect much more to be added (in fact, I'm wondering if it makes sense to come up with a leaner and meaner version at some point because context can probably benefit from that). Of course under the hood there are improvements possible and we have some ideas (that might materialize at some point) but generally spoken, this is what one gets.
That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? Keep in mind that we're not talking of desk top publishing (click and point and place stuff) and also not of word processing (office like stuff) but of mostly automated structured document rendering. Also, keep in mind the landscape that we operate in (context development is mostly user driven as publishers imo long ago lost interest in any research and development and the potential of tex and friends is largely unknown elsewhere).
It's not my intention to implement each possible feature as core feature (no one would document it anyway). Also, as development is basically a spare time effort, don't expect complex commercially interesting niches to come for free either as in that case one can wait till I a find a reason for implementing it for fun or development is driven by a project.
When thinking of future additions, tex, lua, metapost of a mix is possible. They should be of interest for more than one user. Of course it can also be that everything needed is there. Maybe existing mechanisms can be improved in terms of functionality or performance (although i think that performance wise we're ok). But again keep in mind that the boundary conditions (all these interacting sub mechanisms) also prohibit some functionality.
Hans
Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
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
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
Hi Hans, all,
On Tue, 24 Jul 2018 12:43:51 -0600, Hans Hagen j.hagen@xs4all.nl wrote:
Hi,
Around the upcoming context meeting we expect to release luatex 1.09 (or 1.10 ... yet undecided) which is the prelude to the next year tex live version. It's another step towards a stable version in terms of functionality as we don't expect much more to be added (in fact, I'm wondering if it makes sense to come up with a leaner and meaner version at some point because context can probably benefit from that). Of course under the hood there are improvements possible and we have some ideas (that might materialize at some point) but generally spoken, this is what one gets.
That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? Keep in mind that we're not talking of desk top publishing (click and point and place stuff) and also not of word processing (office like stuff) but of mostly automated structured document rendering. Also, keep in mind the landscape that we operate in (context development is mostly user driven as publishers imo long ago lost interest in any research and development and the potential of tex and friends is largely unknown elsewhere).
It's not my intention to implement each possible feature as core feature (no one would document it anyway). Also, as development is basically a spare time effort, don't expect complex commercially interesting niches to come for free either as in that case one can wait till I a find a reason for implementing it for fun or development is driven by a project.
When thinking of future additions, tex, lua, metapost of a mix is possible. They should be of interest for more than one user. Of course it can also be that everything needed is there. Maybe existing mechanisms can be improved in terms of functionality or performance (although i think that performance wise we're ok). But again keep in mind that the boundary conditions (all these interacting sub mechanisms) also prohibit some functionality.
One needed feature that would be of general use is better support for synctex. Thinking especially of structural elements such as headings, footnotes, etc. which mostly do not work with synctex - i.e., clicking on these elements in the pdf do not take one back to the correct location in the relevant TEX file.
Best wishes Idris
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 -----------------------------------------------------------------
Hello,
a bit later - I was thinking if to react here, after reading all about synctex and complicated support for complicatedly assembled source files - but my personal experience/wish...
On 7/24/2018 11:02 PM, Idris Samawi Hamid ادريس سماوي حامد wrote:
Hi Hans, all,
One needed feature that would be of general use is better support for synctex. Thinking especially of structural elements such as headings, footnotes, etc. which mostly do not work with synctex - i.e., clicking on these elements in the pdf do not take one back to the correct location in the relevant TEX file.
When building a document (or more precisely: documentation which consists of many documents), I'm widely referring to other files via \input, \component etc., I'm widely using \defs, \defines and \buffers defined in separate files (as these defs are used at more places - so let them being defined in one source file) and I'm often generating texts by Lua (e.g. tables - being read and parsed from a text in a \start/\stopluacode block or e.g. Excel named range read via LuaXls or from a .xml - and typeset by a Lua function, which allows simply change all \NC into \VL in a particular place).
The lengthy process is to EDIT (almost) finished docs/documentation. And at this place, it would be very handy if synctex worked. So I vote for a better click-in-PDF-go-to-source support.
On Wed, 25 Jul 2018 01:21:48 +0200, Hans Hagen j.hagen@xs4all.nl wrote:
Synctex is a beast. Basically it is not that useable for context which is why we have a different implementation with a rather clean, minimal, and predictable output. Unfortunately the usual approahc is to use a library for interoreting the synctex files which has too much heuristics built in. More flexible would be to let the viewer cann an external program which then can interpret the synctex file based on a page and position. This also would make it possible to have more clever synchronization and/or adapt to a macro package. Anyway, were sort of stuck and can only try to make the best of it.
That said, the context generated synctex file is nornally okay unless we render from lua, which happens for instance with titles. Just try
\ctxlua{context("foo bar")}
and you will also see that there is no line related positioning. Tweaking luatex for this is not really an options because whatever decision we make here will backfire at some point. (I can look into some option later but it needs bit of thinking)
I don't know anything deep about how sync is provided. But my layman point of view would be that whenever a character (or a "box") is to be placed on the page (or into output stream), ConTeXt should know which is the "deepest - currently read" source file, the line, moreover the column - and that position could result into "pick-and-go" position.
In this approach - "boxes" generated by Lua-in-ConTeXt should "jump" on \startluacode, \ctxlua, \cldcommand statement...
Anyway, i can cheat at the tex/lua end if needed and support e.g. titles but i'm not going to pollute the code with every place where we come from lua (also because in most cases there is no relation with the source anyway then). Also, I will not add code that can have an impact on performance when synctex is turned off.
Synctex should be turned on/off before source files are compiled into PDF - via command line option "--synctex" or \enabledirectives[system.synctex] before \starttext (\enabledirectives[system.synctex] after \starttext (\startcomponent) should be ignored?) - that could cause hooking picked Lua functions (or taking their "synctex-on" alternatives) - so normally (with synctex off) there wouldn't be any performance impact; worse performance would come only with synctex on - but it's user's choice.
But for a subset of constructs that are relatively short in usage it is doable (but doesn't really qualify as fun -- also, i don't use it myself).
Anyway, a better support for "pick-in-PDF-and-go-to-source" (synctex), namely when user "tunes" the docs to their final stage, would be great.
Best regards,
Lukas
(One complication is that for instance fixing it for some constructs will break it for xml input which also supports synctex.)
Hans
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
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
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 -----------------------------------------------------------------
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.
Am 2018-07-25 um 03:29 schrieb Rik Kabel context@rik.users.panix.com:
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this.
I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms.
Generally, you get stylistic tagging by using \definehighlight. I replaced \em and \bf by \emph{} and \strong{} in my projects.
Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
The ability to point register entries to something other than page numbers would also be useful. For export formats (XML) this requires that label references be part of the export.
Seconded. Same with other references like footnotes. (I need to try the current state, my last ePub was somewhen last year, and there the locations of footnotes were messed up.)
Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel context@rik.users.panix.com:
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this.
I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms.
Generally, you get stylistic tagging by using \definehighlight. I replaced \em and \bf by \emph{} and \strong{} in my projects.
Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
\definehighlight does not (by default) nest. You can handle this to some degree in css or xslt for XML exports, but it is not an acceptable replacement for font switches with pdf output. And since the syntax for highlights ( \highlight{text} ) differs from that for font switches ( {\highlight text} ), it is not simply a matter of different environments for each output format, although perhaps \groupedcommand might help (I have not tried this).
But that is in some ways beside the point. A user should not have to find and modify every instance in the source where such setups occur. When exports or tagging are enabled, it would be good if this were automatically done.
On 7/25/2018 3:50 PM, Rik Kabel wrote:
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel context@rik.users.panix.com:
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this.
I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms.
Generally, you get stylistic tagging by using \definehighlight. I replaced \em and \bf by \emph{} and \strong{} in my projects.
Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
\definehighlight does not (by default) nest. You can handle this to some degree in css or xslt for XML exports, but it is not an acceptable replacement for font switches with pdf output. And since the syntax for highlights ( \highlight{text} ) differs from that for font switches ( {\highlight text} ), it is not simply a matter of different environments for each output format, although perhaps \groupedcommand might help (I have not tried this).
font switches using 'style' are bound to a structural element
But that is in some ways beside the point. A user should not have to find and modify every instance in the source where such setups occur. When exports or tagging are enabled, it would be good if this were automatically done.
you can't expect reliable structure from non-structured input so if you want an export that is ok, the penalty is proper structuring
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
On Wed, 25 Jul 2018 09:50:58 -0400 Rik Kabel context@rik.users.panix.com wrote:
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel context@rik.users.panix.com:
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this.
I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms.
Generally, you get stylistic tagging by using \definehighlight. I replaced \em and \bf by \emph{} and \strong{} in my projects.
Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
\definehighlight does not (by default) nest. You can handle this to some degree in css or xslt for XML exports, but it is not an acceptable replacement for font switches with pdf output. And since the syntax for highlights ( \highlight{text} ) differs from that for font switches ( {\highlight text} ), it is not simply a matter of different environments for each output format, although perhaps \groupedcommand might help (I have not tried this).
But that is in some ways beside the point. A user should not have to find and modify every instance in the source where such setups occur. When exports or tagging are enabled, it would be good if this were automatically done.
Do you know about
\savebtxdataset [default] [bibliography.xml] [alternative=xml, criterium=all]
You can thus save your bibliography data for use, rather than or in addition to the rendered list.
Alan
On 7/25/2018 6:18 PM, Alan Braslau wrote:
On Wed, 25 Jul 2018 09:50:58 -0400 Rik Kabel context@rik.users.panix.com wrote:
On 7/25/2018 04:19, Henning Hraban Ramm wrote:
Am 2018-07-25 um 03:29 schrieb Rik Kabel context@rik.users.panix.com:
I would ask for more stylistic or semantic tagging to be added to the XML export. A good example is that of bibliographies, where font styles carry significant semantic meaning (depending on the standard used: italic for book titles, ibold or talic for volume and issue numbers, and so on.) The xml output reflects none of this.
I do not know whether one would want stylistic tagging (italic, bold, ...) or semantic (booktitle, issue number). In either case, they could be implemented as highlights or tagged elements, both of which are currently carried through, and the user could then apply the appropriate styling with css or other transformation mechanisms.
Generally, you get stylistic tagging by using \definehighlight. I replaced \em and \bf by \emph{} and \strong{} in my projects.
Didn’t try real bibliographies or xml input yet, but I guess you can change the setup to use those.
\definehighlight does not (by default) nest. You can handle this to some degree in css or xslt for XML exports, but it is not an acceptable replacement for font switches with pdf output. And since the syntax for highlights ( \highlight{text} ) differs from that for font switches ( {\highlight text} ), it is not simply a matter of different environments for each output format, although perhaps \groupedcommand might help (I have not tried this).
But that is in some ways beside the point. A user should not have to find and modify every instance in the source where such setups occur. When exports or tagging are enabled, it would be good if this were automatically done.
Do you know about
\savebtxdataset [default] [bibliography.xml] [alternative=xml, criterium=all]
You can thus save your bibliography data for use, rather than or in addition to the rendered list.
I'll upload a beta with
- tagged publications - embedded bib data in xml format and bibtex format
that should be enough for postprocessing magic. Of course we cannot catch cases where users mess around with specific setups which is no big deal as fo rexporting purposes one can use a simple standard style.
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
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 -----------------------------------------------------------------
On 24. Jul 2018, at 20:43, Hans Hagen j.hagen@xs4all.nl wrote:
Hi,
[…] That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? […]
At the risk of sounding like a scratched, repeating gramophone record -- support for Indic scripts would be wonderful.
RZ
Agree wholeheartedly, and possibly also support for Tibetan.
Best, Richard
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 -----------------------------------------------------------------
I have an entirely different suggestion, possibly fitting the description of a possible “lean” version.
One important feature of TeX has been the longevity of the documents. This is of course of little interest to those of us who typeset a book/journal for publishing and care little about it when it’s done. But there is an interest in keeping the documents available in the long term, meaning decades and possibly centuries (making assumptions about the human race here). TeX has survived the transition from dvi/ps to pdf, and it is probably fair to assume that pdf won’t be around forever. But it is probably also fair to assume that there will be straightforward ways to generate from TeX sources documents in a future PDF replacement. This is in particular of concern in the scientific community where mathematical/physical/chemical formulas and diagrams are very hard to parse semantically (which, admittedly, might change in the future, too). For instance, the preprint server at arXiv.org has been storing scientific preprints since 1991, preferably in TeX or LaTeX. It would be an enormous benefit if the arXiv would accept a ConTeXt version. Scientific journals might then follow suit. At the moment I believe they use LaTeX from TeXLive 2016.
It is of course a question whether a potentially much larger user base is desirable, because it likely means more requests for support/documentation etc.
In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be retypeset over years (like my lecture notes that need an update every few years).
Matthias
On Jul 25, 2018, at 8:50 AM, Hans Hagen j.hagen@xs4all.nl wrote:
On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:
Agree wholeheartedly, and possibly also support for Tibetan.
define support ... what is needed
Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
On 7/25/2018 3:12 PM, Weber, Matthias wrote:
I have an entirely different suggestion, possibly fitting the description of a possible “lean” version.
One important feature of TeX has been the longevity of the documents. This is of course of little interest to those of us who typeset a book/journal for publishing and care little about it when it’s done. But there is an interest in keeping the documents available in the long term, meaning decades and possibly centuries (making assumptions about the human race here). TeX has survived the transition from dvi/ps to pdf, and it is probably fair to assume that pdf won’t be around forever. But it is probably also fair to assume that there will be straightforward ways to generate from TeX sources documents in a future PDF replacement.
so far no replacemtn showed up (ok, html is an alternatiev but that's a different thing) .. even pdf 2.0 (which we support) isn't revolutionary different from 1.7
This is in particular of concern in the scientific community where mathematical/physical/chemical formulas and diagrams are very hard to parse semantically (which, admittedly, might change in the future, too). For instance, the preprint server at arXiv.org has been storing scientific preprints since 1991, preferably in TeX or LaTeX. It would be an enormous benefit if the arXiv would accept a ConTeXt version. Scientific journals might then follow suit. At the moment I believe they use LaTeX from TeXLive 2016.
It is of course a question whether a potentially much larger user base is desirable, because it likely means more requests for support/documentation etc.
I don't think that a larger user base is a problem. It might actually trigger users into writing more manuals, wiki entries, tutorials. But 'marketing' in a world where tex is equivalent to latex is not trivial.
In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be retypeset over years (like my lecture notes that need an update every few years).
When we have luatex 1.10 that will be easier because older code can run on a newer engine then.
But even then, if we make snapshots that can be downloaded for a long time, we need some way to recognize them (by year?).
Using snapshots in parallel is no big deal. One problem is that one also needs to save the fonts (it will probably take a few years before the lm/gyre collection is long term stable).
Matthias
On Jul 25, 2018, at 8:50 AM, Hans Hagen j.hagen@xs4all.nl wrote:
On 7/25/2018 12:03 PM, Richard Mahoney | Indica et Buddhica wrote:
Agree wholeheartedly, and possibly also support for Tibetan.
define support ... what is needed
Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
If your question is of interest to others as well, please add an entry to the Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___________________________________________________________________________________
Am 2018-07-25 um 19:50 schrieb Hans Hagen j.hagen@xs4all.nl:
In any case, I would very much appreciate another “frozen” release like MK II that one can use for documents that need to be retypeset over years (like my lecture notes that need an update every few years).
When we have luatex 1.10 that will be easier because older code can run on a newer engine then.
But even then, if we make snapshots that can be downloaded for a long time, we need some way to recognize them (by year?).
LilyPond (as a somewhat similar program) requires a version statement in every source file; and then there’s a converter script that understands and updates all constructs that are part of the official syntax - of course, if you use custom scripting (Scheme in this case), you are on your own again.
Greetlings, Hraban --- https://www.fiee.net http://wiki.contextgarden.net https://www.dreiviertelhaus.de GPG Key ID 1C9B22FD
On 7/25/2018 9:45 AM, Robert Zydenbos wrote:
On 24. Jul 2018, at 20:43, Hans Hagen j.hagen@xs4all.nl wrote:
Hi,
[…] That said, a logical question is how about next versions of context. Are there fundamental features missing? Is more needed? […]
At the risk of sounding like a scratched, repeating gramophone record -- support for Indic scripts would be wonderful.
I know. There's only a small piece of definitions missing. So that will happen eventually. (Kai is looking into that as he also has sample texts.)
Hans
----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------
-
Aditya Mahajan -
Alan Braslau -
Hans Hagen -
Hans van der Meer -
Henning Hraban Ramm -
Idris Samawi Hamid ادريس سماوي ح امد -
Pablo Rodriguez -
Procházka Lukáš Ing. -
Richard Mahoney | Indica et Buddhica -
Rik Kabel -
Robert Zydenbos -
Weber, Matthias