Re: [NTG-context] roadmap

[Christoph Reller]

On Tue, 15 May 2018 16:51:13 +0200 luigi scarso  wrote:
>
> 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.

In my opinion, verapdf has one advantage a couple of disadvantages:

+ If everything works out as planned then verapdf may become one of
the most widely adopted validators, free of charge and open source

- verapdf is yet relatively new and hence inmature
- verapdf currently only validates against the PDF/A specifications
and not (really) against the PDF specifications. This is bad because
the latter are integral parts of the former.
- verapdf does not validate embedded streams such as images, font
files and color profiles.

In short: Only if you are sure that the input document is a valid PDF,
then verapdf can be used to test PDF/A conformance.

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

[Hans Hagen]

On 5/17/2018 5:47 PM, Otared Kavian wrote:

Hi Mohammad Hossein,

Thanks for your work regarding the RawSteps!
However I tried just now the examples you have on github, but it seems that it 
does not work out of the box: ConTeXt reports an error at line 114 of 
p-rsteps.tex, complaining about an « Undefined control sequence » which points 
to
\catcode`\^^M=\active

Maybe you have fixed the issue now, but regarding the feature request put 
forward by Fabrice, I agree with him that such a stepping feature would be nice 
to have in mkiv, since the steps commands which exist now cannot be used in all 
circumstances.

Best regards: OK


On 17 May 2018, at 16:24, Mohammad Hossein Bateni  wrote:

Fabrice,

Accepting the caveats Hans pointed out for problematic spacing and some issues 
with references, you might find [https://github.com/bateni/rawsteps-mkiv] 
useful.  I ported RawSteps to MkIV and have used it in a few presentations.  
The version on github might be buggy, but a good start if you really insist on 
using RawSteps.

I've added

  s-present-steps.mkiv

  examples/present-steps-001.tex

to the beta, a quick hack assuming sane coding.

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

[Otared Kavian]

Hi Mohammad Hossein,

Thanks for your work regarding the RawSteps! 
However I tried just now the examples you have on github, but it seems that it 
does not work out of the box: ConTeXt reports an error at line 114 of 
p-rsteps.tex, complaining about an « Undefined control sequence » which points 
to
\catcode`\^^M=\active

Maybe you have fixed the issue now, but regarding the feature request put 
forward by Fabrice, I agree with him that such a stepping feature would be nice 
to have in mkiv, since the steps commands which exist now cannot be used in all 
circumstances.

Best regards: OK

> On 17 May 2018, at 16:24, Mohammad Hossein Bateni  wrote:
> 
> Fabrice,
> 
> Accepting the caveats Hans pointed out for problematic spacing and some 
> issues with references, you might find 
> [https://github.com/bateni/rawsteps-mkiv] useful.  I ported RawSteps to MkIV 
> and have used it in a few presentations.  The version on github might be 
> buggy, but a good start if you really insist on using RawSteps.

___
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

[Mohammad Hossein Bateni]

Fabrice,

Accepting the caveats Hans pointed out for problematic spacing and some
issues with references, you might find [
https://github.com/bateni/rawsteps-mkiv] useful.  I ported RawSteps to MkIV
and have used it in a few presentations.  The version on github might be
buggy, but a good start if you really insist on using RawSteps.

On Thu, May 17, 2018 at 9:07 AM Hans Hagen  wrote:

> On 5/16/2018 9:14 PM, Fabrice L wrote:
> > Dear all,
> >
> >  > - Check what additional features users want (miss) and decide to what
> > extent and with what priority we will put effort in this.
> >
> > As asked, I add a wish to the list...
> >
> > One feature which I depend a lot on is to be able to do animations: I
> > actually use the Raw Steps module, by David Munger (dated from 2006),
> > which still worked, but in MKII only. This is essential for me for my
> > teaching and talks. During teaching, I have designed courses notes in
> > ConText using a lot modes of context: the notes are different for
> > the teacher, are available in two formats for the students (paper and
> > for completion on tablets), and there is a last version for use in the
> > class by me. In class, this is essential for me that the material is
> > presented by steps, otherwise students have a tendency to not listen, or
> > to not try to solve a problem is the solution is already on the screen.
> > I can not use the animation tools available in ConTexT using javascript,
> > since I use to show notes in class an iPad, and I use the stylus to fill
> > blanks present in the notes (which work great by the way !).
> > The facility to use modes in the courses notes like this have convinced
> > several of my colleagues to use ConTeXt for their teaching needs.
> >
> > Following threads on this list on animations, my understanding is that
> > Hans is not a great supporter of the method of animations in the Raw
> > Steps module, for technical reasons.
> >
> > I have switch to MKIV for others documents, but I'm still on MKII for
> > this reason for my courses notes, which are 90% one my needs in TeX.
> > Fabrice.
> A few remarks:
>
> (1) The mkiv approach uses not that much javascript actually, it uses
> layers that get turned on and off and it has a simplicity that i like,
> also because there is no interference with repetition (e.g. of
> references) cq. are no side effects (like bad spacing). Unfortunately
> layers are hardly supported and the trivial javascript to control some
> aspects of viewing neither. (Luigi and I have been thinking of adding
> lua to a mupdf based viewer ... maybe we should pick up that thread.)
>
> (2) Steps i.e. repetitive content has the problem that one then needs to
> make sure references get flushes only ones which also demands care by
> the user, and spacing not be influenced too badly by redoing chunks.
> This is why I made some explicit steppers (there are some in the mkiv
> part as s-present* files).
>
> I can give it some thought but it's not that trivial to do it right
> (according to my specs).
>
> 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
___

Re: [NTG-context] roadmap

[Hans Hagen]

On 5/16/2018 9:14 PM, Fabrice L wrote:

Dear all,

 > - Check what additional features users want (miss) and decide to what 
extent and with what priority we will put effort in this.


As asked, I add a wish to the list...

One feature which I depend a lot on is to be able to do animations: I 
actually use the Raw Steps module, by David Munger (dated from 2006), 
which still worked, but in MKII only. This is essential for me for my 
teaching and talks. During teaching, I have designed courses notes in 
ConText using a lot modes of context: the notes are different for 
the teacher, are available in two formats for the students (paper and 
for completion on tablets), and there is a last version for use in the 
class by me. In class, this is essential for me that the material is 
presented by steps, otherwise students have a tendency to not listen, or 
to not try to solve a problem is the solution is already on the screen. 
I can not use the animation tools available in ConTexT using javascript, 
since I use to show notes in class an iPad, and I use the stylus to fill 
blanks present in the notes (which work great by the way !). 
The facility to use modes in the courses notes like this have convinced 
several of my colleagues to use ConTeXt for their teaching needs.


Following threads on this list on animations, my understanding is that 
Hans is not a great supporter of the method of animations in the Raw 
Steps module, for technical reasons.


I have switch to MKIV for others documents, but I'm still on MKII for 
this reason for my courses notes, which are 90% one my needs in TeX.

Fabrice.

A few remarks:

(1) The mkiv approach uses not that much javascript actually, it uses 
layers that get turned on and off and it has a simplicity that i like, 
also because there is no interference with repetition (e.g. of 
references) cq. are no side effects (like bad spacing). Unfortunately 
layers are hardly supported and the trivial javascript to control some 
aspects of viewing neither. (Luigi and I have been thinking of adding 
lua to a mupdf based viewer ... maybe we should pick up that thread.)


(2) Steps i.e. repetitive content has the problem that one then needs to 
make sure references get flushes only ones which also demands care by 
the user, and spacing not be influenced too badly by redoing chunks. 
This is why I made some explicit steppers (there are some in the mkiv 
part as s-present* files).


I can give it some thought but it's not that trivial to do it right 
(according to my specs).


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

[Fabrice L]

Dear all,

> - Check what additional features users want (miss) and decide to what
extent and with what priority we will put effort in this.

As asked, I add a wish to the list...

One feature which I depend a lot on is to be able to do animations: I
actually use the Raw Steps module, by David Munger (dated from 2006), which
still worked, but in MKII only. This is essential for me for my teaching
and talks. During teaching, I have designed courses notes in ConText using
a lot modes of context: the notes are different for the teacher, are
available in two formats for the students (paper and for completion on
tablets), and there is a last version for use in the class by me. In class,
this is essential for me that the material is presented by steps, otherwise
students have a tendency to not listen, or to not try to solve a problem is
the solution is already on the screen. I can not use the animation
tools available in ConTexT using javascript, since I use to show notes in
class an iPad, and I use the stylus to fill blanks present in the notes
(which work great by the way !). The facility to use modes in the courses
notes like this have convinced several of my colleagues to use ConTeXt for
their teaching needs.

Following threads on this list on animations, my understanding is that Hans
is not a great supporter of the method of animations in the Raw Steps
module, for technical reasons.

I have switch to MKIV for others documents, but I'm still on MKII for this
reason for my courses notes, which are 90% one my needs in TeX.
Fabrice.

2018-05-14 11:17 GMT-04:00 Hans Hagen :

> 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 if some mechanism can (by now) be simplified due to LuaTeX
> extension introduced the last few years that can be considered stable by
> now. This has a low impact as we already use Lua a lot.
>
> - Figure out what mechanism in ConTeXt are bottlenecks in performance if
> there are such bottlenecks at all. We need user input on this.
>
> - Get rid of inconsistencies in the user interface e.g. by introducing new
> commands with settings.
>
> - 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.
>
> - Try to improve tricky mechanisms, like columns and tables. Improvements
> are of course always on the agenda.
>
> - We can add more trickery for fonts and scripts. There are some pending
> extensions.
>
> - Maybe we should provide a few more general styles.
>
> - Are there reasonable challenges left.
>
> LuaTeX 1.09:
>
> - This version is pretty close to what is the final version (seen from the
> functional point of view). We're still debating where to move after this.
> LuaTeX 2.0? A stripped down (lean and mean) version specific for ConTeXt?
> Keep in mind that we cannot fundamentally change something, even if we want
> to, because other macro packages use it and don't expect it to change much.
>
> - There will probably be some more options in controlling math (given
> issues with fonts). We have to accept that not everything has a generic
> programmable solution (which is why we have Lua on board).
>
> - There might be a few more callbacks but probably nothing fundamental is
> planned.
>
> - We keep cleaning up the code base (less code is better, less
> dependencies too, some documentation is missing or not yet adapted to the
> new code). For instance the pdf inclusion code will soon be redone (and
> then tested in the ConTeXt distribution as usual).
>
> - When possible we will try to improve performance but there is not much
> to gain to be expected there.
>
> - We will also keep up with Lua (currently 5.3, some day 5.4). It is
> unclear to what extent LuaJit follows. When it stays behind we need to
> decide if support in ConTeXt will stay (to some extent we can have dual
> code paths as we have now).
>
> - We expect the ffi interface to external libraries to become more stable
> over time. ConTeXt will not introduce dependencies (what can be done in Lua
> will happen in Lua) but on the other hand we might put some libraries in
> the distribution e.g. for database support.
>
> - We might add some extensions to MetaPost in MPLib.
>
> In addition we could formulate ideas with respect to the distribution,
> garden, documentation and so on.
>
> You can react on this list but if you come to the meeting, you can
> participate in discussions.
>
> So far for now,
>
> Hans
>
> -
>   Hans Hagen | PRAGMA ADE
>   Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
>tel: 038 477 53 69 | www.pragma-ade.nl | 

Re: [NTG-context] roadmap

[Pablo Rodriguez]

On 05/15/2018 11:26 PM, Hans Hagen wrote:
> On 5/15/2018 9:17 PM, Pablo Rodriguez wrote:
>> [...]
>> 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 must confess that I can recognize hanging characters, but quality
expansion is impossible to see (at least, for me).

I would even say that if expansion can be seen by a human reader, the
results will be crappy.

How can I use the vertical scale feature to prevent widows and orphans?

Many thanks for your help,

Pablo

>> 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
> ___
> 


-- 
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

[Hans Hagen]

On 5/16/2018 7:38 AM, Henri Menke wrote:

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


luatex 1.10 will have that (as it take s bit of effort to enter al the 
data which i'm doing as part of some other cleanups)


anyway, you can do:

local n = node.new("noad") n.subtype = node.subtypes("noad").bin print(n)

local n = node.new("noad") n.subtype = node.subtypes("noad").rel print(n)

there was never a need to look into a 'w' file, also because sometimes 
subtypes get added we provided this list



     node.new("noad", "bin")

instead of

     node.new("noad", 4)

and I would also like to see

     node.subtype("noad", "bin") -- return 4


node.subtypes("noad").bin
returns a number

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

[Joseph Canedo]

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 : n

Re: [NTG-context] roadmap

[Henri Menke]

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

[Hans Hagen]

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

[Pablo Rodriguez]

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

[luigi scarso]

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

[Christoph Reller]

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

[MF]

> > * 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
___

Re: [NTG-context] roadmap

[Hans Hagen]

On 5/15/2018 8:15 AM, Christoph Reller wrote:

On Tue, May 15, 2018 at 12:53 AM, <ntg-context-requ...@ntg.nl> wrote:



Message: 3
Date: Mon, 14 May 2018 23:26:28 +0200
From: Hans Hagen <j.ha...@xs4all.nl>
To: Henning Hraban Ramm <te...@fiee.net>, mailing list for ConTeXt
 users <ntg-context@ntg.nl>
Subject: Re: [NTG-context] roadmap
Message-ID: <c504ea08-a021--4eba-c2894d72d...@xs4all.nl>
Content-Type: text/plain; charset=utf-8; format=flowed

On 5/14/2018 9:36 PM, Henning Hraban Ramm wrote:

Hi Hans, thank you so much!


Keep up the good work!


* PDF/* (X, A, UA - probably only reasonable with external tools, but it seems 
like there’s not a lot that’s usable)


we support various formats (to some extend the backend even adapts to
it) ... tagged pdf ... already there for quite a while but i never had
any demand for it so i never really check the current state (also
because imo it's a it weird feature ... only there because publishers
don't want to distribute sources that are suitable for rendering
variations ... so we're stuck with some pseudo structure related to
visuals)

(i might upgrade tagging and exports as they closely relate but it's not
easy to get motivated for something that one has no real use for so at
most it will cold winter evening stuff)


To us, tagged PDF is important. Specifically, for PDF/A with
compliance level a, tagging is mandatory. ConTeXt is the only (!)
TeX-based PDF creation suite that can produce correct and reliable
tagging.

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.

 From what we hear of our customers, PDF/A level a and PDF/UA are
becoming increasingly important, be it because of archiving issues or
because of legislation requirements. So please, maintain this
invaluable feature!
Ah, it's good to hear that it's working ok. (Of course it is/will be 
maintained ... it's just that because I don't need it myself it's up to 
folks like you to check if it's ok.)


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

[luigi scarso]

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 ?

-- 
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

[Christoph Reller]

On Tue, May 15, 2018 at 12:53 AM, <ntg-context-requ...@ntg.nl> wrote:
>
>
> Message: 3
> Date: Mon, 14 May 2018 23:26:28 +0200
> From: Hans Hagen <j.ha...@xs4all.nl>
> To: Henning Hraban Ramm <te...@fiee.net>, mailing list for ConTeXt
> users <ntg-context@ntg.nl>
> Subject: Re: [NTG-context] roadmap
> Message-ID: <c504ea08-a021--4eba-c2894d72d...@xs4all.nl>
> Content-Type: text/plain; charset=utf-8; format=flowed
>
> On 5/14/2018 9:36 PM, Henning Hraban Ramm wrote:
> > Hi Hans, thank you so much!

Keep up the good work!

> > * PDF/* (X, A, UA - probably only reasonable with external tools, but it 
> > seems like there’s not a lot that’s usable)
>
> we support various formats (to some extend the backend even adapts to
> it) ... tagged pdf ... already there for quite a while but i never had
> any demand for it so i never really check the current state (also
> because imo it's a it weird feature ... only there because publishers
> don't want to distribute sources that are suitable for rendering
> variations ... so we're stuck with some pseudo structure related to
> visuals)
>
> (i might upgrade tagging and exports as they closely relate but it's not
> easy to get motivated for something that one has no real use for so at
> most it will cold winter evening stuff)

To us, tagged PDF is important. Specifically, for PDF/A with
compliance level a, tagging is mandatory. ConTeXt is the only (!)
TeX-based PDF creation suite that can produce correct and reliable
tagging.

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.

From what we hear of our customers, PDF/A level a and PDF/UA are
becoming increasingly important, be it because of archiving issues or
because of legislation requirements. So please, maintain this
invaluable feature!

Cheers, and thank you for all the effort.

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

[luigi scarso]

On Tue, May 15, 2018 at 12:52 AM, Henri Menke  wrote:

>
> Math typesetting is really crappy in ConTeXt
>

hm

-- 
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

[Hans Hagen]

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

[Henri Menke]

On 15/05/18 03:17, 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 if some mechanism can (by now) be simplified due to LuaTeX 
extension introduced the last few years that can be considered stable by 
now. This has a low impact as we already use Lua a lot.


- Figure out what mechanism in ConTeXt are bottlenecks in performance if 
there are such bottlenecks at all. We need user input on this.


- Get rid of inconsistencies in the user interface e.g. by introducing 
new commands with settings.


- 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.


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.




- Try to improve tricky mechanisms, like columns and tables. 
Improvements are of course always on the agenda.


- columnsets, the new ones have considerably fewer features than the old 
ones.
- rowwise setups in xtables and maybe columnwise, but that is 
computationally expensive.




- 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?



- Are there reasonable challenges left.

LuaTeX 1.09:

- This version is pretty close to what is the final version (seen from 
the functional point of view). We're still debating where to move after 
this. LuaTeX 2.0? A stripped down (lean and mean) version specific for 
ConTeXt? Keep in mind that we cannot fundamentally change something, 
even if we want to, because other macro packages use it and don't expect 
it to change much.


More callbacks.  I'm missing callbacks into error handling (i.e. 
intercept errors) not just into error reporting like show_error_hook.


Throw out all non-Lua-related primitives and replace them with Lua 
functions.  People can then define those primitives themselves, e.g.


\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.


This should have maybe been done before 1.0 but I guess with 2.0 you can 
introduce “breaking” features.




- There will probably be some more options in controlling math (given 
issues with fonts). We have to accept that not everything has a generic 
programmable solution (which is why we have Lua on board).


- There might be a few more callbacks but probably nothing fundamental 
is planned.


- We keep cleaning up the code base (less code is better, less 
dependencies too, some documentation is missing or not yet adapted to 
the new code). For instance the pdf inclusion code will soon be redone 
(and then tested in the ConTeXt distribution as usual).


- When possible we will try to improve performance but there is not much 
to gain to be expected there.


- We will also keep up with Lua (currently 5.3, some day 5.4). It is 
unclear to what extent LuaJit follows. When it stays behind we need to 
decide if support in ConTeXt will stay (to some extent we can have dual 
code paths as we have now).


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

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.




- We expect the ffi interface to external libraries to become more 
stable over time. ConTeXt will not introduce dependencies (what can be 
done in Lua will happen in Lua) but on the other hand we might put some 
libraries in the distribution e.g. for database support.


- We might add some extensions to MetaPost in MPLib.

In addition we could formulate ideas with respect to the distribution, 
garden, documentation and so on.


You can react on this list but if you come to the meeting, you can 
participate in discussions.


So far for now,

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

Re: [NTG-context] roadmap

[Hans Hagen]

On 5/14/2018 9:36 PM, Henning Hraban Ramm wrote:

Hi Hans, thank you so much!

Am 2018-05-14 um 17:17 schrieb Hans Hagen :


- Get rid of inconsistencies in the user interface e.g. by introducing new 
commands with settings.


+1


- 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.


* Recently I had some difficulties with (foot)notes, you’ll remember the margin 
notes thread. There are still some things that don’t work/look as I’d like them 
to, and I hope also others would welcome more flexible/simpler placement 
options.


Notes and margins will always be somewhat tricky esp used with other 
features because in the end tex has to make a choice .. in that respect 
i think that fully automated typesetting will never be ok.



* User/list/structure variables: Probably it’s just me, but there are a few 
difficulties.


hm, they're just data carried with whatever items that have accessors 
... and thre tightly bound so real problems cannot happen there



* 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).



* ePub: I got requests for ePubs again and will look into what’s still 
wrong/difficult. Last time I checked, footnote markers were accumulating in 
strange places. Maybe some more default constructs could get a representation 
in export XML, e.g. \bf, \it


It's hard to comment on that one without examples ... keep in mind that 
the xport is *not* meant as visual companion to the pdf but as a kind of 
representation of structure as seen by context ... any reordering due to 
typesetting can reflect that unless one does the obvious: for the expor 
make a special run with dedicated settings (like making notes end notes) 
... notes (and other inserts) are a separate thing in the tex engine and 
have an asynchronous character. The better the input structure the 
better the export, and fro real robust multiple usage just code in xml.


Visual properties (e.g. fonts) are not part of a structure, but you can 
just use highlights and such as these get tagged (with classes) so one 
then can relate them to e.g. fonts or colors. Keep in mind that \bf is 
not a construct, but a highlight named 'important' is. We can't make 
structure from non-structure.


(FWIW: as long as we don't have projects that need this the priority for 
such features - the export basically started as a proof of concept - 
they get a low priority.)



* There are a few things missing in image handling - when I wrote my placement 
macros I needed image size calculations that already exist in ConTeXt but were 
not easily accessible.


hm, there's a lot available (actually also already in mkii) but i fear 
that there are too many variantions in demands .. there is a rather 
extensive plugin mechanism too (but not that documented) ... if some 
info is missing it can be added (although i don't think that there is 
more available in the engine that we expose)



* Would it be possible (or is it already?) to place stuff on layers and let 
"everything else" run around it? E.g. for half-page images I’m having a hard 
time using the float placement, while I could simply place images on a layer.


I'm not sure what you mean here but for the main flow we only hav eside 
floats. However, normally everything can be put on / moved to layers 
(iir the details manual shows some of that) but tex will never be loks 
dtp. Again, when i'd need that (given that I know what that means) for a 
project thaen i'd probably look into it. I've learned that much can be 
done in tex but not all without interference with other mechanisms.



- Are there reasonable challenges left.


* ePub


the export + a (dedicated) css ... exports have to be generic ... i must 
admit that i gave away my ebook reader as i never use(d) it and bying a 
new one is not on the agenda/budget (now)



* PDF/* (X, A, UA - probably only reasonable with external tools, but it seems 
like there’s not a lot that’s usable)


we support various formats (to some extend the backend even adapts to 
it) ... tagged pdf ... already there for quite a while but i never had 
any demand for it so i never really check the current state (also 
because imo it's a it weird feature ... only there because publishers 
don't want to distribute sources that are suitable for rendering 
variations ... so we're stuck with some pseudo structure related to 
visuals)


(i might upgrade tagging and exports as they closely relate but it's not 
easy to get motivated for something that one has no real use for so at 
most it will cold winter evening stuff)



* even 

Re: [NTG-context] roadmap

[Henning Hraban Ramm]

Hi Hans, thank you so much!

Am 2018-05-14 um 17:17 schrieb Hans Hagen :

> - Get rid of inconsistencies in the user interface e.g. by introducing new 
> commands with settings.

+1

> - 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.

* Recently I had some difficulties with (foot)notes, you’ll remember the margin 
notes thread. There are still some things that don’t work/look as I’d like them 
to, and I hope also others would welcome more flexible/simpler placement 
options.

* User/list/structure variables: Probably it’s just me, but there are a few 
difficulties.

* References: see Massimiliano’s question, apparently there are options missing 
for code before/after the list of pages

* ePub: I got requests for ePubs again and will look into what’s still 
wrong/difficult. Last time I checked, footnote markers were accumulating in 
strange places. Maybe some more default constructs could get a representation 
in export XML, e.g. \bf, \it

* There are a few things missing in image handling - when I wrote my placement 
macros I needed image size calculations that already exist in ConTeXt but were 
not easily accessible.

* Would it be possible (or is it already?) to place stuff on layers and let 
"everything else" run around it? E.g. for half-page images I’m having a hard 
time using the float placement, while I could simply place images on a layer.

> - Are there reasonable challenges left.

* ePub

* PDF/* (X, A, UA - probably only reasonable with external tools, but it seems 
like there’s not a lot that’s usable)

* even better error messages - often you get some obscure errors if you just 
miss a brace or bracket somewhere. I guess that’s a big hurdle for beginners.

* documentation... (sigh) While I’m trying to enhance our wiki and my book on 
ConTeXt, I often need to search the code base for undocumented options or usage 
examples, sometimes on stuff that looks simple or would be simple to do in 
InDesign...

> LuaTeX 1.09:
> - We expect the ffi interface to external libraries to become more stable 
> over time. ConTeXt will not introduce dependencies (what can be done in Lua 
> will happen in Lua) but on the other hand we might put some libraries in the 
> distribution e.g. for database support.

Sounds good. I could use JSON, SQLite and/or MySQL support and some user 
interface stuff – at the moment my invoicing solution is a mixture of Bash, 
Python, Lua und ConTeXt, I’m already using a minimal OO library (classy.lua) 
and was looking into tekui, but got stuck... Maybe I should better look into 
the ConTeXt web framework as GUI. Or finally finish my (Django based) web shop 
and write a ConTeXt backend for PDF generation... Anyway.

Some default imaging solution would be nice (GraphicsMagick library).


Greetlings, Hraban
---
https://www.fiee.net
http://wiki.contextgarden.net
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
___

[NTG-context] roadmap

[Hans Hagen]

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 if some mechanism can (by now) be simplified due to LuaTeX 
extension introduced the last few years that can be considered stable by 
now. This has a low impact as we already use Lua a lot.


- Figure out what mechanism in ConTeXt are bottlenecks in performance if 
there are such bottlenecks at all. We need user input on this.


- Get rid of inconsistencies in the user interface e.g. by introducing 
new commands with settings.


- 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.


- Try to improve tricky mechanisms, like columns and tables. 
Improvements are of course always on the agenda.


- We can add more trickery for fonts and scripts. There are some pending 
extensions.


- Maybe we should provide a few more general styles.

- Are there reasonable challenges left.

LuaTeX 1.09:

- This version is pretty close to what is the final version (seen from 
the functional point of view). We're still debating where to move after 
this. LuaTeX 2.0? A stripped down (lean and mean) version specific for 
ConTeXt? Keep in mind that we cannot fundamentally change something, 
even if we want to, because other macro packages use it and don't expect 
it to change much.


- There will probably be some more options in controlling math (given 
issues with fonts). We have to accept that not everything has a generic 
programmable solution (which is why we have Lua on board).


- There might be a few more callbacks but probably nothing fundamental 
is planned.


- We keep cleaning up the code base (less code is better, less 
dependencies too, some documentation is missing or not yet adapted to 
the new code). For instance the pdf inclusion code will soon be redone 
(and then tested in the ConTeXt distribution as usual).


- When possible we will try to improve performance but there is not much 
to gain to be expected there.


- We will also keep up with Lua (currently 5.3, some day 5.4). It is 
unclear to what extent LuaJit follows. When it stays behind we need to 
decide if support in ConTeXt will stay (to some extent we can have dual 
code paths as we have now).


- We expect the ffi interface to external libraries to become more 
stable over time. ConTeXt will not introduce dependencies (what can be 
done in Lua will happen in Lua) but on the other hand we might put some 
libraries in the distribution e.g. for database support.


- We might add some extensions to MetaPost in MPLib.

In addition we could formulate ideas with respect to the distribution, 
garden, documentation and so on.


You can react on this list but if you come to the meeting, you can 
participate in discussions.


So far for now,

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
___