[NTG-context] Math kerning broken in latest beta

2018-04-10 Thread Henri Menke
Dear list,

The math kerning seems to be broken in recent versions of LuaTeX.  When I
process the MWE below with TeX Live 2017 (LuaTeX 1.0.4) I get a different result
from the latest beta (LuaTeX 1.07.0).  However, I could only observe this
behaviour with some fonts, e.g. stixtwo or lucidaot.  No difference was
encountered for modern and xits.

Cheers, Henri

---

\setupbodyfont[stixtwo] % or lucidaot
\startTEXpage
$V_A$
\stopTEXpage


104.pdf
Description: Adobe PDF document


1070.pdf
Description: Adobe PDF document
___
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] \ifcase changes default align in xtables

2018-04-10 Thread Wolfgang Schuster

In your example the argument for the align key is always empty which results
in the default alignment for a frame which put the content in the middle 
of the box.


Wolfgang

Pablo Rodriguez 
10. April 2018 um 21:05
Dear list,

I have the following sample:

\setupxtable[mytable]
[option={stretch, height},
align={\ifcase\currentxtablerow\fi}]
\starttext
\startxtable[mytable]
\startxrow
\startxcell 1 \stopxcell
\startxcell 2 \stopxcell
\stopxrow
\startxrow
\startxcell 3 \stopxcell
\startxcell 4 \stopxcell
\stopxrow
\stopxtable
\startxtable[option={stretch, height}]
\startxrow
\startxcell 1 \stopxcell
\startxcell 2 \stopxcell
\stopxrow
\startxrow
\startxcell 3 \stopxcell
\startxcell 4 \stopxcell
\stopxrow
\stopxtable
\stoptext

For some strange reason, when using \ifcase in align, default is changed
from {high, left} to {lohi, center}. Shouldn’t defaults be the same?

BTW, if I set align to {\ifodd\currentxtablerow\fi}. I wonder whether
this might be a bug.

Many thanks for your help,

Pablo


___
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] conditional format in xtables

2018-04-10 Thread Wolfgang Schuster

The normal \doif... commands don’t work because they aren’t expandable
but you can use the \expdoif... commands (look into setup-en.pdf for all 
of them).


Wolfgang

Pablo Rodriguez 
10. April 2018 um 19:18
Dear list,

thanks to Wolfgang, I learnt to set conditional format in xtables, such
as in:

\setupxtable
[foregroundcolor={\ifnum\currentxtablecolumn=2 red\else green\fi}]
\starttext
\startxtable
\startxrow
\startxcell one \stopxcell
\startxcell two \stopxcell
\startxcell tree \stopxcell
\startxcell four \stopxcell
\stopxrow
\stopxtable
\stoptext

My question is whether I can use ConTeXt conditionals instead of the
ones from TeX. {\doifelse{\currentxtablecolumn}{2}{red}{green}} doesn’t
work here.

Many thanks for your help,

Pablo


___
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] Build for Alpine Linux

2018-04-10 Thread Arthur Reutenauer
On Tue, Apr 10, 2018 at 11:05:12AM +, Brian Hunt wrote:
>>  The caret in itself was not the problem, only that it was not escaped
>> for the shell.  Testing a regexp, with -E of course, is just as robust,
>> and allows us to be more specific about what we test.
> 
> Either is fine I am sure

  That’s what I was saying.  But you seemed to imply that grep -F 'musl'
was preferable to grep -E '^musl' from a portability and robustness
point of view.

>>  grep -E '^musl' works just as well; and as I explained, -q may return 0
>> even if there are errors, so should be avoided.
> 
> The -q is superfluous with the >/dev/null, and should be removed;
> incidentally though, is it not harmless in this case?

  It is not.  In Thomas’ case, using grep >/dev/null would have avoided
a 0 exit status and thus prevented his system from being erroneously
detected as supporting musl.

Best,

Arthur
___
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] \ifcase changes default align in xtables

2018-04-10 Thread Pablo Rodriguez
Dear list,

I have the following sample:

\setupxtable[mytable]
[option={stretch, height},
 align={\ifcase\currentxtablerow\fi}]
\starttext
\startxtable[mytable]
\startxrow
\startxcell 1 \stopxcell
\startxcell 2 \stopxcell
\stopxrow
\startxrow
\startxcell 3 \stopxcell
\startxcell 4 \stopxcell
\stopxrow
\stopxtable
\startxtable[option={stretch, height}]
\startxrow
\startxcell 1 \stopxcell
\startxcell 2 \stopxcell
\stopxrow
\startxrow
\startxcell 3 \stopxcell
\startxcell 4 \stopxcell
\stopxrow
\stopxtable
\stoptext

For some strange reason, when using \ifcase in align, default is changed
from {high, left} to {lohi, center}. Shouldn’t defaults be the same?

BTW, if I set align to {\ifodd\currentxtablerow\fi}. I wonder whether
this might be a bug.

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
___

[NTG-context] conditional format in xtables

2018-04-10 Thread Pablo Rodriguez
Dear list,

thanks to Wolfgang, I learnt to set conditional format in xtables, such
as in:

\setupxtable
  [foregroundcolor={\ifnum\currentxtablecolumn=2 red\else green\fi}]
\starttext
\startxtable
\startxrow
\startxcell one \stopxcell
\startxcell two \stopxcell
\startxcell tree \stopxcell
\startxcell four \stopxcell
\stopxrow
\stopxtable
\stoptext

My question is whether I can use ConTeXt conditionals instead of the
ones from TeX. {\doifelse{\currentxtablecolumn}{2}{red}{green}} doesn’t
work here.

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] Build for Alpine Linux

2018-04-10 Thread Alan Braslau
On Tue, 10 Apr 2018 11:05:12 +
Brian Hunt  wrote:

> from a code maintenance and testing
> perspective I'd be more concerned about a regression or
> misinterpretation to an unescaped carat that breaks the detection on
> zsh

Doesn't *everybody* use zsh?

;-)
___
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] xmlrefatt

2018-04-10 Thread dr. Hans van der Meer
There is a slight restriction on \xmlrefatt that makes its use problematic, 
because it does not differentiate between an absent attribute and an attribute 
consisting of an empty string.
The use for \xmlrefatt I had in mind was (a) do nothing if the attribute is 
absent, and (b) reset some value to its default value when the attribute is 
present but an empty string.

Is it an option that its implementation is changed? A boolean return value will 
be fine, because false then can signify the attribute’s absence and true its 
presence. In the latter case it is safe to retrieve the attribute which then 
might be an empty string.

Summarizing: the fact that \xmlrefatt tries to do two different things at the 
same time (signalling presence/absence) and returning an attribute, in a 
certain sense cripples its use.

dr. Hans van der Meer


___
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] Build for Alpine Linux

2018-04-10 Thread Brian Hunt
A few more notes:

1. Missing texlua - found
The missing `texlua` from `bin/` and `tex/texmf-linuxmusl-64/bin` appears
to be a problem originating at the rsync source, notably it appears that
`texlua` is missing from these paths:

http://standalone.contextgarden.net/setup/linuxmusl-64/
http://standalone.contextgarden.net/current/bin/luatex/linuxmusl-64/bin/

The `texluac` also appears to be missing from these paths (but I have not
experienced errors that appear relating to its absence).

2. mtxrun not finding paths
Running `context` results in an error because it cannot find
`mtx-context.lua`.

I can confirm that mtx-context.lua is in an expected path with:

$ /context # find . -name mtx-context.lua
./tex/texmf-context/scripts/context/lua/mtx-context.lua

I noted mtxrun checks and sets the `platform` (`os.platform`) variable, and
will use `linux-64` by default.  When musl is being used this ought to be
`linuxmusl-64`.  Two potential solutions are:

 a. have mtxrun detect musl with a call to `ldd --version` when setting
`platform`; or
 b. symlink texmf-linux-64 -> texmf-linuxmusl-64

I tried both but `context` still cannot find `mtx-context.lua`.

The path resolution is complex and challenging to debug, and I expect the
issue may be immediately apparent to some.

I've attached a log of a call to `context` with a number of the traces
turned on, that hopefully sheds some light on the problem.

I'm happy to delve or investigate further as may be helpful, and any
assistance is appreciated.

Cheers,
Brian

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*


context-output.log
Description: Binary data
___
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] Build for Alpine Linux

2018-04-10 Thread Brian Hunt
>  The caret in itself was not the problem, only that it was not escaped
> for the shell.  Testing a regexp, with -E of course, is just as robust,
> and allows us to be more specific about what we test.

Either is fine I am sure, but from a code maintenance and testing
perspective I'd be more concerned about a regression or misinterpretation
to an unescaped carat that breaks the detection on zsh (and perhaps
elsewhere), as opposed to anticipating a hypothetical new or different
standard C library that needs detection for an alternative build.

>  grep -E '^musl' works just as well; and as I explained, -q may return 0
even if there are errors, so should be avoided.

The -q is superfluous with the >/dev/null, and should be removed;
incidentally though, is it not harmless in this case?  Avoiding it is
probably good measure for the reason mentioned (i.e. error on directories),
but I'm not sure that such an error in grep is possible when piped from
ldd, is it?  I'm curious when such could occur.

Cheers,
Brian


On Mon, 9 Apr 2018 at 15:35 Arthur Reutenauer <
arthur.reutena...@normalesup.org> wrote:

> > A few notes:
> > a.) On some platforms fgrep has been deprecated (in favour of `grep -F`)
> so
> > it's not future-proof
>
>   I don’t think the aliases fgrep and egrep have ever been supposed to
> be portable.  POSIX has grep -F and grep -E, and that’s what we should
> use.
>
> > b.) The caret (^) passed to `grep -F` will not be interpreted as a regex,
> > since -F forces non-regexp, meaning the '^' will be interpreted literally
> > (and the string "^musl" is not in the ldd output).
>
>   The caret in itself was not the problem, only that it was not escaped
> for the shell.  Testing a regexp, with -E of course, is just as robust,
> and allows us to be more specific about what we test.
>
> > if command -v ldd >/dev/null && ldd --version 2>&1 | grep -Fq 'musl' >
> /dev/null
>
>   grep -E '^musl' works just as well; and as I explained, -q may return
> 0 even if there are errors, so should be avoided.
>
> Best,
>
> Arthur
>
> ___
> 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
>
> ___

-- 

*from the personal account of:*

*Brian M Hunt *
Direct: +1-289-684-4677
LinkedIn: https://linkedin.com/in/brianmhunt

*This e-mail may contain information that is private, privileged,
confidential and/or exempt from disclosure. Except as per this notice no
waiver of any kind is intended by sending this e-mail, and this email is
intended only for the named recipient(s) or the subscribers of a forwarding
service the email is sent directly to and to which service you are an
authorized recipient. Use, dissemination or copying without authorization
is prohibited. Please notify the sender and destroy all copies of this
e-mail if you have received this email in error.*
___
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
___