Re: [NTG-context] roadmap
If I am not mistaken, you can write :
node.new(‘noad’, nodes.noadcodes.bin)
De : Henri Menke
Envoyé le :mercredi 16 mai 2018 07:39
À : ntg-context@ntg.nl >> mailing list for ConTeXt users
Objet :Re: [NTG-context] roadmap
I just thought of another thing.
Could you expose _all_ the subtypes of _all_ the different node types
similar to node.id? (currently this is only enabled for whatsits) As of
now I always have to go to texnodes.w, find the array and count to find
out which number a subtype has. It would be much easier if we could
node.new("noad", "bin")
instead of
node.new("noad", 4)
and I would also like to see
node.subtype("noad", "bin") -- return 4
On 15/05/18 11:34, Hans Hagen wrote:
> On 5/15/2018 12:52 AM, Henri Menke wrote:
>
>> Math typesetting is really crappy in ConTeXt, but I get that this is
>> beyond your priorities. I plan to develop a module which resembles
>> the features and syntax of the amsmath LaTeX package for my PhD
>> thesis. I'm not sure how well this will integrate with the existing
>> mechanisms.
>
> hm. i have no clue what you refer to ... afaik most is configureable
>
>> - columnsets, the new ones have considerably fewer features than the
>> old ones.
>
> like ... but adding some is no problem (only predictable stuff) .. no
> column handler suits all (we now also have page columns btw)
>
>> - rowwise setups in xtables and maybe columnwise, but that is
>> computationally expensive.
>
> indeed so that's why we have categories instead
>
>>> - We can add more trickery for fonts and scripts. There are some
>>> pending extensions.
>>>
>>> - Maybe we should provide a few more general styles.
>>
>> What does that mean? Things like the TUGboat style?
>
> no, e.g. some basic educational stuff
>
>> More callbacks. I'm missing callbacks into error handling (i.e.
>> intercept errors) not just into error reporting like show_error_hook.
>
> if you want to intercept errors then that has to happen at the macro
> level, because once tex starts expanding the error can be anywhere
>
> (so, in a macro package one can set at the tex level flags that one can
> act upon in the error callback)
>
> (the eror messages themselves might become a layer but that's for later)
>
>> Throw out all non-Lua-related primitives and ntg-context@ntg.nlreplace
>> them with Lua functions. People can then define those primitives
>> themselves, e.g.
>
> way too slow ... in that case i'd drop tex completely (i.e. do all in lua)
>
> also, you can right now (re)define primitives if you like (depending on
> the definition of primitive)
>
>> \suppressoutererror
>>
>> becomes
>>
>> \protected\def\suppressoutererror{%
>> \directlua{errors.suppressoutererror()}}
>>
>> This makes it much easier to access that stuff from Lua. Also
>> interface all the \pdfvariable and \pdfextension stuff to Lua.
>
> all pdf stuff is already doable in lua (context doesn't even use \pdf*
> for quite a while)
>
>> This should have maybe been done before 1.0 but I guess with 2.0 you
>> can introduce “breaking” features.
>
> well, a 2.0 (if ever) will probably only be useable for context ...
>
>> LuaJIT will always be 5.1 compatible. That is one of the declared
>> goals of the project. However there exist compatibility layers for
>> Lua which implement recent features for older interpreters.
>> https://github.com/keplerproject/lua-compat-5.3
>
> in that case in the end it will be dropped ...
>
>> I would rather not see LuaJIT support being dropped. The VM by itself
>> (without JIT) is already a lot faster than regular Lua and I feel that
>> the ConTeXt runs benefit from that quite a lot. I use contextjit as
>> my daily driver.
>
> hm, at most 20% which is also what i get when i buy a new laptop
>
> keep in mind that luajit has some limitations (stack and such)
>
> (and the last few years i managed to squeeze out a lot from lua, and
> with lua 5.3 the gaps became narrower)
> 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
Re: [NTG-context] roadmap
I just thought of another thing.
Could you expose _all_ the subtypes of _all_ the different node types
similar to node.id? (currently this is only enabled for whatsits) As of
now I always have to go to texnodes.w, find the array and count to find
out which number a subtype has. It would be much easier if we could
node.new("noad", "bin")
instead of
node.new("noad", 4)
and I would also like to see
node.subtype("noad", "bin") -- return 4
On 15/05/18 11:34, Hans Hagen wrote:
On 5/15/2018 12:52 AM, Henri Menke wrote:
Math typesetting is really crappy in ConTeXt, but I get that this is
beyond your priorities. I plan to develop a module which resembles
the features and syntax of the amsmath LaTeX package for my PhD
thesis. I'm not sure how well this will integrate with the existing
mechanisms.
hm. i have no clue what you refer to ... afaik most is configureable
- columnsets, the new ones have considerably fewer features than the
old ones.
like ... but adding some is no problem (only predictable stuff) .. no
column handler suits all (we now also have page columns btw)
- rowwise setups in xtables and maybe columnwise, but that is
computationally expensive.
indeed so that's why we have categories instead
- We can add more trickery for fonts and scripts. There are some
pending extensions.
- Maybe we should provide a few more general styles.
What does that mean? Things like the TUGboat style?
no, e.g. some basic educational stuff
More callbacks. I'm missing callbacks into error handling (i.e.
intercept errors) not just into error reporting like show_error_hook.
if you want to intercept errors then that has to happen at the macro
level, because once tex starts expanding the error can be anywhere
(so, in a macro package one can set at the tex level flags that one can
act upon in the error callback)
(the eror messages themselves might become a layer but that's for later)
Throw out all non-Lua-related primitives and ntg-context@ntg.nlreplace
them with Lua functions. People can then define those primitives
themselves, e.g.
way too slow ... in that case i'd drop tex completely (i.e. do all in lua)
also, you can right now (re)define primitives if you like (depending on
the definition of primitive)
\suppressoutererror
becomes
\protected\def\suppressoutererror{%
\directlua{errors.suppressoutererror()}}
This makes it much easier to access that stuff from Lua. Also
interface all the \pdfvariable and \pdfextension stuff to Lua.
all pdf stuff is already doable in lua (context doesn't even use \pdf*
for quite a while)
This should have maybe been done before 1.0 but I guess with 2.0 you
can introduce “breaking” features.
well, a 2.0 (if ever) will probably only be useable for context ...
LuaJIT will always be 5.1 compatible. That is one of the declared
goals of the project. However there exist compatibility layers for
Lua which implement recent features for older interpreters.
https://github.com/keplerproject/lua-compat-5.3
in that case in the end it will be dropped ...
I would rather not see LuaJIT support being dropped. The VM by itself
(without JIT) is already a lot faster than regular Lua and I feel that
the ConTeXt runs benefit from that quite a lot. I use contextjit as
my daily driver.
hm, at most 20% which is also what i get when i buy a new laptop
keep in mind that luajit has some limitations (stack and such)
(and the last few years i managed to squeeze out a lot from lua, and
with lua 5.3 the gaps became narrower)
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] roadmap
On 5/15/2018 9:17 PM, Pablo Rodriguez wrote: On 05/14/2018 05:17 PM, Hans Hagen wrote: Hi, The ConTeXt meeting is - as usual - the right place and moment to discuss the roadmap. We never had real binding roadmaps, more informal ones. Anyway, here are some thoughts on the two main components: MkIV and LuaTeX. ConTeXt MkIV: [...] - Check what additional features users want (miss) and decide to what extent and with what priority we will put effort in this. We've reached a point where interference prevents more complex extensions. Hans, I wonder whether it would be possible to implement a feature that you mentioned in the past. In order to avoid widow and orphan lines, you mentioned that it would be possible to automatically adapt the interline space for the page, so that it may have one more line to avoid orphans (when interline space is decreased) or it may move a line to the next page to avoid widows (increasing the interline space in the present page). Would it be possible to add this feature to ConTeXt? actually it was something that came up when talking with Hermann Zapf years ago: he suggested to just vertically scale the text area (i actully implemented that an hour later) ... his opinion was that only a very small percentage of readers will notice (at that time we did experiments with hz, the expansion in pdftex: in fact nobody noticed that too, real interesting was that texies commented on all kind of things related to how tex is supposed to work: a clear demonstration that the average user knows what the virtues of tex are but not really sees it) I have another feature request for notes, but I would like to know whether the feature to avoid widow and orphan lines can be implemented in ConTeXt. you can always ask ... giving it priority is another matter 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] roadmap
On 05/14/2018 05:17 PM, Hans Hagen wrote: > Hi, > > The ConTeXt meeting is - as usual - the right place and moment to > discuss the roadmap. We never had real binding roadmaps, more informal > ones. Anyway, here are some thoughts on the two main components: MkIV > and LuaTeX. > > ConTeXt MkIV: > [...] > - Check what additional features users want (miss) and decide to what > extent and with what priority we will put effort in this. We've reached > a point where interference prevents more complex extensions. Hans, I wonder whether it would be possible to implement a feature that you mentioned in the past. In order to avoid widow and orphan lines, you mentioned that it would be possible to automatically adapt the interline space for the page, so that it may have one more line to avoid orphans (when interline space is decreased) or it may move a line to the next page to avoid widows (increasing the interline space in the present page). Would it be possible to add this feature to ConTeXt? I have another feature request for notes, but I would like to know whether the feature to avoid widow and orphan lines can be implemented in ConTeXt. Many thanks for your help, 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] roadmap
On Tue, May 15, 2018 at 4:46 PM, Christoph Reller < christoph.rel...@gmail.com> wrote: > On Tue, 15 May 2018 08:23:04 +0200 luigi scarso > wrote: > >> >> On Tue, May 15, 2018 at 8:15 AM, Christoph Reller < >> christoph.rel...@gmail.com> wrote: >> >> > >> > Our company is producing (and weekly updating) 67 manuals and >> > technical documents from more than 900 ConTeXt source files for our >> > software products. The output PDFs are converted to PDF/A-2a, which is >> > only possible due to ConTeXt's tagging. >> > >> What do you think of verapdf ? >> > > Well, verapdf is only a validator and not a converter. > > And, by the way, there is no reasonable way to convert from, say, PDF/A-2b > to PDF/A-2a without a rediculous amount of AI or manual input because the > tagging cannot be created out of the blue. It has to be there from the > document's birth. This is what makes this ConTeXt feature so precious. > > sure, the point is if verapdf is reliable as validator. -- luigi ___ 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] roadmap
On Tue, 15 May 2018 08:23:04 +0200 luigi scarso wrote: > > On Tue, May 15, 2018 at 8:15 AM, Christoph Reller < > christoph.rel...@gmail.com> wrote: > > > > > Our company is producing (and weekly updating) 67 manuals and > > technical documents from more than 900 ConTeXt source files for our > > software products. The output PDFs are converted to PDF/A-2a, which is > > only possible due to ConTeXt's tagging. > > > What do you think of verapdf ? > Well, verapdf is only a validator and not a converter. And, by the way, there is no reasonable way to convert from, say, PDF/A-2b to PDF/A-2a without a rediculous amount of AI or manual input because the tagging cannot be created out of the blue. It has to be there from the document's birth. This is what makes this ConTeXt feature so precious. Cheers, Christoph > ___ 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] roadmap
> > * References: see Massimiliano’s question, apparently there are > > options missing for code before/after the list of pages > > These hooks were added; adding a few more hooks is normally no big > deal > ... the main problem with such additions is that they seldom get > documented (in fact that imo is also a it up to the one requesting > such > features). > Touché! I've added them to the wiki. I was already updating that page of the wiki (\setupregister) on Friday, but also realized that it was way behind the syntax you can check with setup-en.pdf (the Commands manual). It missed the brand new "pageleft" and "pageright" parameters, but even much more than them. So i asked myself about the opportunity to document a brand new feature without the missing ones that have been already in place for a much longer time. Anyway, that's the spirit of a wiki: everybody can add his 2 cents of knowledge. The table of the command parameters was also difficult to read and modify in the wiki source, so i gave up for that moment and wondered about a more general solution for command documentation. Your messages today motivated me to update that page anyway. The setup-en.pdf manual is a great source of documentation and it's synchronized with every new version, because it's automatically generated from sources. It lets you know the commands, their parameters and their types. I've looked a bit into the "i-" files in the "interface" directory of the ConTeXt distribution, and i've seen that the commands are also classified into categories. What you miss in that manual is the parameters' meaning and some example of usage. I'm thinking about some companion files to the "i-" ones that carry the information about the parameters' meaning and usage. Some of those texts could be "recycled" from the current wiki pages. Then we could generate some automatic, up to date wiki pages directly from the combination of those files. I'm not going to work on that before the meeting and i've already promised more than i can achieve. But we could discuss that at the meeting. Greetings, Massi ___ 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 ___
