[NTG-context] Re: Very bizarre bug

[Thomas A. Schmitz]

On 4/7/24 22:33, Hans Hagen wrote:

No problem, is it a rpi 5? If so, how does that one perform?


Yes, it's a Pi 5 with 8GB of RAM, and I'm very satisfied with the 
performance. I use it headless for backup, file serving, and the 
occasional context job that ties the cpu up for a long time, and it's 
plenty fast for what I do with it. Runs less hot than the 3B that I have 
in my office for the same purpose (and supposedly the 4, but I've never 
had one of those).


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

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: Very bizarre bug

[Hans Hagen]

On 4/7/2024 10:14 PM, Thomas A. Schmitz wrote:

On 4/7/24 19:44, Hans Hagen wrote:
ok, so this "on" ... where does it come from .. you can try to run 
with \tracingall and then quit the run after the first and search the 
log for !on to get a clue


Hans


Found it - and I'm embarrassed to say it was in my own environment file, 
not in the lmtx distribution. I have a Lua function that prints 
information about the computer model and the operating system into a 
layer. Unfortunately, there was an "elseif" in there somewhere which 
should catch exceptions (such as a raspberry pi), but instead of 
concatenating the relevant return values to display in the layer, I had 
a ' context (" on ")' in there (probably for debugging) which I forgot 
about.


Sorry for the noise - I was getting too sophisticated for my own good...

No problem, is it a rpi 5? If so, how does that one perform?

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 / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: Very bizarre bug

[Thomas A. Schmitz]

On 4/7/24 19:44, Hans Hagen wrote:
ok, so this "on" ... where does it come from .. you can try to run with 
\tracingall and then quit the run after the first and search the log for 
!on to get a clue


Hans


Found it - and I'm embarrassed to say it was in my own environment file, 
not in the lmtx distribution. I have a Lua function that prints 
information about the computer model and the operating system into a 
layer. Unfortunately, there was an "elseif" in there somewhere which 
should catch exceptions (such as a raspberry pi), but instead of 
concatenating the relevant return values to display in the layer, I had 
a ' context (" on ")' in there (probably for debugging) which I forgot 
about.


Sorry for the noise - I was getting too sophisticated for my own good...

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

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: Very bizarre bug

[Hans Hagen]

On 4/7/2024 7:37 PM, Thomas A. Schmitz wrote:

On 4/7/24 19:21, Hans Hagen wrote:
can you make a format with line 25 of context.mkxl uncommented to see 
if you get a message (not production, just a test)


Hans


That should give a message "some spurious input in line..." in the 
output or the log, right? No, did not see such a message.
ok, so this "on" ... where does it come from .. you can try to run with 
\tracingall and then quit the run after the first and search the log for 
!on to get a clue


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 / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: Very bizarre bug

[Thomas A. Schmitz]

On 4/7/24 19:21, Hans Hagen wrote:
can you make a format with line 25 of context.mkxl uncommented to see if 
you get a message (not production, just a test)


Hans


That should give a message "some spurious input in line..." in the 
output or the log, right? No, did not see such a message.


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

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] Re: Very bizarre bug

[Hans Hagen]

On 4/7/2024 7:08 PM, Thomas A. Schmitz wrote:

Hi everybody,

this is bizarre, but hear me out: a file that I have has a mixture of 
xml, TeX and Lua. It compiles cleanly, no problem, on macos and linux. I 
also have a little raspberry pi on which I have installed lmtx. The file 
compiles, BUT: it has one additional page. The first page of the 
document is empty and has the word "on" in the upper left hand corner of 
the text area. I have checked several times, it always comes out like 
this. Everything else is exactly the same - context version, file and 
environment files (everything under git, so really identical). The "on" 
does not appear if I just make a "hello world" document on the raspi. So 
my question is: how can I begin to explore where this word creeps in? I 
suspect it's something in the linux-aarch64 tree or some test for this 
architecture that is the culprit, but what would be a good way to trace it?


can you make a format with line 25 of context.mkxl uncommented to see if 
you get a message (not production, just a test)


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 / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

[NTG-context] vim syntax highlighting bug?

[Damien Thiriet via ntg-context]

Hello,


Happy New Year!

I got into a bug in my Vim syntax highlighting version.
Highlight stays in lua mode after ctxlua macro is closed.
Here is a MWE, where «this should not be highlitghted as
a comment indeed is.

\starttext

Hello!
\ctxlua{context("does the parser work?")}

-- this should not be highlighted as a comment

\stoptext

Do other Vim users come into this?
Is my syntax file outdated?

I am using this Vim version on OpenBSD 7.3 -stable:
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Sep  6 2023 08:55:14)
Included patches: 1-1876

Best regards,

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

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Re: [NTG-context] \setupcolors and \underbar bug?

[Henning Hraban Ramm]

> Am 14.01.2021 um 21:48 schrieb Henning Hraban Ramm :
> 
> 
> 
>> Am 14.01.2021 um 16:58 schrieb Alan Bowen :
>> 
>> The mwe
>> 
>> \starttext
>> \setupcolors[state=stop]
>> {\darkred Test}
>> 
>> \underbar{Here}
>> \stoptext
>> 
>> fails: “Here” does not appear above the underbar (which has the correct 
>> length).
>> 
>> When \setupcolors[state=stop] is commented out, the file runs as it should.
> 
> It happens also if you set rgb=no, and the result in my project is even worse:

Hans, the fix you sent to Alan fixes the problem for me. Thank you!

Hraban
___
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] \setupcolors and \underbar bug?

[Henning Hraban Ramm]

> Am 14.01.2021 um 16:58 schrieb Alan Bowen :
> 
> The mwe
> 
> \starttext
> \setupcolors[state=stop]
> {\darkred Test}
> 
> \underbar{Here}
> \stoptext
> 
> fails: “Here” does not appear above the underbar (which has the correct 
> length).
> 
> When \setupcolors[state=stop] is commented out, the file runs as it should.

It happens also if you set rgb=no, and the result in my project is even worse:



\setupcolors[rgb=no]

\starttext

Liszt bat den Klavierfabrikanten darum, Dankesgrüße für den 
\quotation{\underbar{belorbeerten} schönen Blumenstrauss} anlässlich seines 
Geburtstages auszurichten.
\stoptext


The PDF contains only:

 schönen Blumenstrauss“ anlässlich seines Geburtstages auszurichten.


Hraban
___
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] \setupcolors and \underbar bug?

[Alan Bowen]

The mwe

\starttext
\setupcolors[state=stop]
{\darkred Test}

\underbar{Here}
\stoptext

fails: “Here” does not appear above the underbar (which has the correct
length).

When \setupcolors[state=stop] is commented out, the file runs as it should.

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

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

[NTG-context] Defining \qed (was: Bug with \wordright...)

[Otared Kavian]

Hi Wolfgang,

Thanks for your explanations and the correct definition of the close symbol in 
an enumeration.
Following up the discussions with Hans, in order to put a close sympbol at the 
end of a formula, I have the following for the definition of \qed:

%% begin example-qed.tex
\showframe
\definesymbol[Fin][\mathematics{\square}]
\def\qed{%
\ifmmode
\inrightmargin{\hskip-7.5mm\symbol[Fin]} % --> attention here
\else
\dontleavehmode\wordright{\symbol[Fin]}
\fi}

\setupformulas[location=left]

\starttext

One sees that
\placeformula
\startformula
   a^2 + b^2 = c^2
\stopformula
which is the Pythagoras theorem. \qed

Another proof of Pythagors theorem is based on the figure below in which one 
sees that:
\placeformula
\startformula
(a+b)^2 = c^2 + 2ab \quad \imply \quad a^2 + b^2 = c^2. \qed
\stopformula

\stoptext
%% end example-qed.tex

Now how can I replace « \hskip-7.5mm » (which was found by trial and error…) in 
a robust manner so that the close symbols in the formulas are vertically 
aligned with the close symbols in the text?
In other terms can one compute automatically the amount of negative \hskip so 
that the definition is correct when one changes the font size and the layout?

Thanks in advance: Otared

> On 5 Aug 2020, at 21:15, Wolfgang Schuster 
>  wrote:
> […]
> 
> Below is a cleaner version to put a symbol at the end of each proof. The 
> \blank setting in the \PlaceProofSymbol definition moves the symbol back in 
> the math formula to avoid the vertical space between them, you can remove it 
> but I would at leas use \blank[back] to get rid of the empty line between the 
> formula and the symbol.
> 
> \define[1]\PlaceProofSymbol
>  {\blank[back,overlay]%
>   \dontleavehmode\wordright{#1}}
> 
> \defineenumeration
>  [proof]
>  [ closesymbol={\symbol[square]},
>   closecommand=\PlaceProofSymbol]
> 
> \starttext
> 
> \startproof
>  \startformula
>a^2 + b^2 = c^2
>  \stopformula
> \stopproof
> 
> \stoptext
> 
> Wolfgang
> ___
> 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] Is there a bug in lmt_shade[...=...,...=...]

[Keith McKay]

Thanks again Hans, lmt_shade now works as before.

Keith

On 29/07/2020 16:13, Keith McKay wrote:

Thanks Hans! Much appreciated.

Keith

On 29/07/2020 16:04, Hans Hagen wrote:

On 7/29/2020 3:43 PM, Keith McKay wrote:


Has a bug appeared in the command lmt_shade[ ]?
Looks that way. I'll fix it (upload later today). We now have some 
better (potentially more efficient) ways to feed back results into mp 
so that's where the cycle property seems to get lost.


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] Is there a bug in lmt_shade[...=...,...=...]

[Keith McKay]

Thanks Hans! Much appreciated.

Keith

On 29/07/2020 16:04, Hans Hagen wrote:

On 7/29/2020 3:43 PM, Keith McKay wrote:


Has a bug appeared in the command lmt_shade[ ]?
Looks that way. I'll fix it (upload later today). We now have some 
better (potentially more efficient) ways to feed back results into mp 
so that's where the cycle property seems to get lost.


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] Is there a bug in lmt_shade[...=...,...=...]

[Hans Hagen]

On 7/29/2020 3:43 PM, Keith McKay wrote:


Has a bug appeared in the command lmt_shade[ ]?
Looks that way. I'll fix it (upload later today). We now have some 
better (potentially more efficient) ways to feed back results into mp so 
that's where the cycle property seems to get lost.


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
___

[NTG-context] Is there a bug in lmt_shade[...=...,...=...]

[Keith McKay]

Hi

Has a bug appeared in the command lmt_shade[ ]?

This used to work before I upgraded.

\setuppapersize [A5, portrait][A4, landscape]

\setuparranging[2UP]

\starttext

\startMPpage

StartPage;

width := PaperWidth ; height := PaperHeight ; unit := cm ;

definecolor [ name = "MyColor1", r = 0.781, g = 0.5, b = 0.5 ] ;

definecolor [ name = "MyColor3", r = 1, g = 1, b = 0.7983 ] ;

draw lmt_shade [

path = unitsquare xscaled width yscaled height,

direction = "up",

alternative = "linear",

colors = { "MyColor1", "MyColor3" },

] ;

StopPage;

\stopMPpage

\stoptext

The console output gives this:

system >

system > ConTeXt ver: 2020.07.29 14:08 LMTX fmt: 2020.7.29 int: 
english/english


system >

metapost > log >

metapost > log > loading metafun, including plain.mp version 1.004 for 
metafun iv and xl


metapost > log >

metapost > log > ! Not a cycle.

metapost > log > 

metapost > log > withprescript

metapost > log >  ...i.fill.mfun_shade_path.withprescript

metapost > log > "sh_domain="

metapost > log >

metapost > log > image->...ture;currentpicture:=nullpicture;(TEXT3)

metapost > log > ;currentpicture.if.str(SUF...

metapost > log >

metapost > log > lmt_do_shade->...shed.evenly;fi.fi.popparameters;)

metapost > log > endgroup

metapost > log >  lmt_do_shade

metapost > log >

metapost > log > <*> ...ar", colors = { "MyColor1", "MyColor3" }, ]

metapost > log > ; StopPage; ;

metapost > log >

system > print height forced to paper height

system > print width forced to paper width

Thanks

Keith

___
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] SOLVED Re: \bTABLE bug, please help !

[Taco Hoekwater]

> On 10 Mar 2020, at 16:20, Hans Hagen  wrote:
> 
> On 3/10/2020 3:07 PM, Taco Hoekwater wrote:
>> Hi,
>> Never mind, I got it (starting at \loggingall output for a while). This
>> patch to my input fixes it:
>>   \unprotect
>>   \setupfootertexts[{\tabl_ntb_next_level \getbuffer[mytable] 
>> \tabl_ntb_prev_level}]
>>   \protect
> 
> you beat me on this ... (still puzzled because nesting shoudl kind of work)

Well, they are not _really_ nested, which is the problem, of course.

> I'll add this:
> 
> %D This is for the special cases where for instance a table is in a header or 
> footer
> %D line and we have a split table in progress. (See mail to list from Taco.)
> 
> \unexpanded\def\bTABLEnested{\tabl_ntb_next_level\bTABLE}
> \unexpanded\def\eTABLEnested{\eTABLE\tabl_ntb_next_level}

That last macro should be \tabl_ntb_prev_level ;)

Taco

___
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] SOLVED Re: \bTABLE bug, please help !

[Hans Hagen]

On 3/10/2020 3:07 PM, Taco Hoekwater wrote:

Hi,

Never mind, I got it (starting at \loggingall output for a while). This
patch to my input fixes it:

   \unprotect
   \setupfootertexts[{\tabl_ntb_next_level \getbuffer[mytable] 
\tabl_ntb_prev_level}]
   \protect


you beat me on this ... (still puzzled because nesting shoudl kind of work)

I'll add this:

%D This is for the special cases where for instance a table is in a 
header or footer

%D line and we have a split table in progress. (See mail to list from Taco.)

\unexpanded\def\bTABLEnested{\tabl_ntb_next_level\bTABLE}
\unexpanded\def\eTABLEnested{\eTABLE\tabl_ntb_next_level}

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
___

[NTG-context] SOLVED Re: \bTABLE bug, please help !

[Taco Hoekwater]

Hi,

Never mind, I got it (starting at \loggingall output for a while). This
patch to my input fixes it:

  \unprotect
  \setupfootertexts[{\tabl_ntb_next_level \getbuffer[mytable] 
\tabl_ntb_prev_level}]
  \protect

Best wishes,
Taco

> On 10 Mar 2020, at 14:47, Taco Hoekwater  wrote:
> 
> Hi,
> 
> Please see the attached example. The \bTABLE in the footer of the page 
> ‘inherits' the
> first line of the split \bTABLE in the running text. I have no idea how to 
> fix this
> or why this even happens. Help!
> 
> I’ll need a way to work around this problem in my current ConTeXt 
> installation for
> this project. That is now nearly 4 years old, but the same bug is still 
> happens with
> a new beta of mkiv.
> 
> I cannot switch to \startxtable because I would need \startembeddedxtable, 
> and that
> has way too many limitations to be useful in this project.
> 
> Best wishes,
> Taco
> 
> 
> 
> 
> 
> 
> ___
> 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
> ___

Taco Hoekwater
Elvenkind BV




___
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] Is this a bug in header marking?

[Rik]

I have resolved the issue in a practical, but unsatisfactory, manner.

I have resorted to creating an interlude, a new heading derived from 
title, setting it for left pages with no displayed head:


   \definehead[ChapterEpigraph][title]
   \setuphead [ChapterEpigraph][
  page={yes,left},
  insidesection=\vfill,
  aftersection={\vfill\vfill},
  header=empty,
  placehead=no,
 ]

Thus, \startChapterEpigraph can safely be placed before each 
\startchapter (and between the last \stopchapter of a part and the start 
of the next part) when that last chapter ends on a recto). This clears 
the chapter marking in the headings of the new verso. When there is an 
epigraph to set, it is placed in the ChapterEpigraph section.


This is unsatisfactory because it implements an inaccurate semantic 
model of the document – the epigraphs belong to the following chapter, 
not the numberless, nameless interlude.


And there is almost certainly a bug lurking here. I had considered 
adding the marking of the next chapter to the interlude to better tie 
the interlude to the place it belongs. When I made ChapterEpigraph 
derivative of chapter:


   \definehead[ChapterEpigraph][chapter]
   \setuphead [ChapterEpigraph][
  page={yes,left},
  insidesection=\vfill,
  aftersection={\vfill\vfill},
  header=yes,
  number=no,
  placehead=no,
 ]

and provided a marking:

   \startChapterEpigraph[marking={Same as next chapter marking}]

The resulting page displayed the marking of the previous chapter, not 
the marking provided. This appears to be the same behavior as in the 
example below in my first note, although I can provide another working 
example using this apparatus if anyone wants it.


Can we please have a \setuphead or \setupheads option to clear markings 
at the end of the level, and not simply override them when the next 
equivalent level starts? (Although perhaps, based on the observed issue 
described just above, there is some other logic at work here.)


--
Rik

On 2017-10-15 23:54, Rik Kabel wrote:


As a followup to my query on suppressing header marking, I have 
prepared an example which clearly shows odd, if not buggy behavior.


The book places chapter openings on recto pages which follow a verso 
that may have an epigraph. When there is no epigraph, the blank verso 
is properly unmarked by a header, but when there is an epigraph, the 
header from the previous chapter appears on the page. How can I 
eliminate this orphan header?


\setuppagenumbering [alternative=doublesided,location=]
\setupheadertexts   [][{\it\getmarking[section]}]
    [{\it\getmarking[chapter]}][]

\starttexdefinition unexpanded startSectionEpigraph
    \dostartbuffer  [SectionEpigraph]
[startSectionEpigraph][stopSectionEpigraph]
\stoptexdefinition

\setuphead  [chapter][
beforesection=\setups{chapter:epigraph}]

\startsetups chapter:epigraph
    \page[yes,left]% same result with yes,header,footer,left
    \doifelsebuffer{SectionEpigraph}
    {\getbuffer[SectionEpigraph]
 \resetbuffer[SectionEpigraph]}
    {\donothing}
    \page[yes,header,footer,right]
\stopsetups

\starttext

    \completecontent

    \startfrontmatter
    \startchapter[title=Preface]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \stopfrontmatter
    \startbodymatter

    \startchapter[title=Chapter First]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startSectionEpigraph
    Why does this page have the heading
    from the previous chapter?
    \stopSectionEpigraph

    \startchapter[title=Chapter Second]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startSectionEpigraph
  Look up!
    \stopSectionEpigraph

    \startchapter[title=Chapter Third]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startchapter[title=Chapter Final]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \stopbodymatter

\stoptext

--
Rik


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

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

[NTG-context] Is this a bug in header marking?

[Rik Kabel]

As a followup to my query on suppressing header marking, I have prepared 
an example which clearly shows odd, if not buggy behavior.


The book places chapter openings on recto pages which follow a verso 
that may have an epigraph. When there is no epigraph, the blank verso is 
properly unmarked by a header, but when there is an epigraph, the header 
from the previous chapter appears on the page. How can I eliminate this 
orphan header?


   \setuppagenumbering [alternative=doublesided,location=]
   \setupheadertexts   [][{\it\getmarking[section]}]
    [{\it\getmarking[chapter]}][]

   \starttexdefinition unexpanded startSectionEpigraph
    \dostartbuffer  [SectionEpigraph]
   [startSectionEpigraph][stopSectionEpigraph]
   \stoptexdefinition

   \setuphead  [chapter][
 beforesection=\setups{chapter:epigraph}]

   \startsetups chapter:epigraph
    \page[yes,left]% same result with yes,header,footer,left
    \doifelsebuffer{SectionEpigraph}
    {\getbuffer[SectionEpigraph]
 \resetbuffer[SectionEpigraph]}
    {\donothing}
    \page[yes,header,footer,right]
   \stopsetups

   \starttext

    \completecontent

    \startfrontmatter
    \startchapter[title=Preface]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \stopfrontmatter
    \startbodymatter

    \startchapter[title=Chapter First]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startSectionEpigraph
    Why does this page have the heading
    from the previous chapter?
    \stopSectionEpigraph

    \startchapter[title=Chapter Second]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startSectionEpigraph
  Look up!
    \stopSectionEpigraph

    \startchapter[title=Chapter Third]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \startchapter[title=Chapter Final]
    \startparagraph
    \input ward
    \stopparagraph
    \stopchapter

    \stopbodymatter

   \stoptext

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

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

[NTG-context] is there a bug in the startappendices commend?

[Matthias Wende]

Hello list,

After using the \startappendices command the entire document becomes an
appendix. After the command the numbering restarts.

Here is a simple example.

-
\setuplabeltext
[appendix=Appendix~]
\setuphead
[chapter]
[page=no]
\setuphead
[section]
[appendixlabel=appendix]
\setuplist
[section]
[label=yes]

\starttext

\title{Contents}
\placelist[title,chapter,section][criterium=all,alternative=c]

\chapter{First Chapter}
\section{First Section}
\chapter{Second Chapter}

\startappendices

\chapter{Appendices}
\section{First Appendix}

\stopappendices

\stoptext
-

Thank you, Matthias
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] is there a bug in the startappendices commend?

[Wolfgang Schuster]

Matthias Wende 
21. Januar 2016 um 14:04
Hello list,

After using the \startappendices command the entire document becomes an
appendix. After the command the numbering restarts.

You forgot the start/stop commands for the frontpart and bodypart!

Here is a simple example.

-
\setuplabeltext
[appendix=Appendix~]
\setuphead
[chapter]
[page=no]
\setuphead
[section]
[appendixlabel=appendix]
\setuplist
[section]
[label=yes]

\starttext

\startfrontmatter

\title{Contents}
\placelist[title,chapter,section][criterium=all,alternative=c]

\stopfrontmatter

\startbodymatter

\chapter{First Chapter}
\section{First Section}
\chapter{Second Chapter}

\stopbodymatter

\startappendices

\chapter{Appendices}
\section{First Appendix}

\stopappendices

\stoptext

Wolfgang
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] Is this a bug?

[Matt Gushee]

Hello, all--

I asked this question a few days ago, in the context of solving a problem I
was having. That problem is solved, thanks to Wolfgang, but I haven't seen
any response to my mention of what I think is a bug.

The issue I was having was that, when I tried to process an old project
with mkIV, there was no output because the project structure was obsolete:
it contained a project and several products, but no components.

But even though there was no output, there was also no error message, and
in fact the log file falsely reported that a PDF file had been saved. That
can't be right, can it? Seems like a bug.

My ConTeXt version is:
current version: 2015.05.18 12:26

--
Matt Gushee
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] Counter[way=bypage] bug in latest beta?

[mf]

  
 BTW: The names for the counter commands are \...counter, e.g.
 
 \definecounter[testcounter][way=bypage]
 
 \define\TestCounter
   {\incrementcounter[testcounter]
   %\convertedcounter[testcounter]
\rawcountervalue [testcounter]}
 
 \starttext
 \dorecurse{3}{\TestCounter\page}
 \stoptext
 
 Wolfgang

Thanks Wolfgang.
I used \definenumber, \incrementnumber, etc. because I read this:
http://wiki.contextgarden.net/Counters

Should that page be updated? I can do it, but I'd like to know
something more about the two forms:

Is \definenumber the mkII way and \definecounter the mkIV one?

Or are they simply synomyms, being \definecounter the preferred one?

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] Counter[way=bypage] bug in latest beta?

[mf]

Hello list,
consider this example, involving a number (counter) to be reset at each
page:

\starttext
\definenumber[MyNumber][way=bypage] % MyNumber=0
\incrementnumber[MyNumber] % MyNumber=1
\incrementnumber[MyNumber] % MyNumber=2
mynumber is \rawcountervalue[MyNumber]. % prints 2
\page % MyNumber=0
\incrementnumber[MyNumber] % MyNumber=1
At the new page, mynumber is \rawcountervalue[MyNumber].
\stoptext

In ConTeXt 2014.05.21 22:04 (the one I get as Debian package) it works
as expected, giving MyNumber=1 at page 2, because MyNumber gets reset
at page break.
In the latest beta (and also in 2014.04.01) the counter does not reset
and it's equal to 3 at the end of page 2.

Another question: when you comment out the increment at page 2, the
counter does not reset, and you get 2 even in version 2014.05.21.

\starttext
\definenumber[MyNumber][way=bypage] % MyNumber=0
\incrementnumber[MyNumber] % MyNumber=1
\incrementnumber[MyNumber] % MyNumber=2
mynumber is \rawcountervalue[MyNumber]. % prints 2
\page % MyNumber=0
% \incrementnumber[MyNumber] COMMENTED OUT
At the new page, mynumber is \rawcountervalue[MyNumber]. % prints 2
\stoptext

Is this a bug or is it the way it should work when you don't increment
it?
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \placefigure and title bug in latest beta

[Alan Bowen]

Hans--

In today's beta, the following produces a figure entitled Figure 1 title:

\setupexternalfigures[location={local,default}]
\starttext
\useexternalfigure[cow.pdf]
\startplacefigure[title={A cow}]
{\externalfigure[Graphic][cow.pdf]}
\stopplacefigure
\stoptext

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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \placefigure and title bug in latest beta

[Otared Kavian]

Hi,

I can confirm this…
This is probably due to the new features Hans added today.

Also, the new feature 

\placelist[figure][criterium=text]

places indeed the list of the figures, but the names of the figures, or rather 
their captions are all indicated by the word « list ».

Best regards: OK


On 6 avr. 2014, at 16:26, Alan Bowen bowenala...@gmail.com wrote:

 Hans—
 
 In today’s beta, the following produces a figure entitled “Figure 1 title”:
 
 \setupexternalfigures[location={local,default}]
 \starttext
 \useexternalfigure[cow.pdf]
 \startplacefigure[title={A cow}]
   {\externalfigure[Graphic][cow.pdf]}
 \stopplacefigure
 \stoptext
 
 Alan
 ___
 If your question is of interest to others as well, please add an entry to the 
 Wiki!
 
 maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
 webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] Obscure math/color bug (namespace clash)

[Hans Hagen]

On 2/19/2014 9:53 AM, Alan BRASLAU wrote:

Hello,

I came across the following obscure math/color namespace clash:



\definecolor [tan] [h=d2b48c] % Taken from \setupcolor [x11]

\starttext
$\tan θ$
\stoptext



One solution would be to give precedence in math mode to the standard 
mathematical tokens (here \tan).

Another solution would be simply to avoid the use of tan (as a color). In colo-imp-x11.mkiv it 
could be renamed tan0 (there is already tan1, tan2, tan3). This is somewhat unfortunate as 
tan is a standard X11 color name. On the other hand, one would like to be able to use colors in 
math mode as well...

So I propose the following patch:

121c121
 \definecolor [tan0] [h=d2b48c] % ! namespace clash with $\tan$
---

\definecolor [tan]  [h=d2b48c]


\definecolor [tan] [h=d2b48c] % Taken from \setupcolor [x11]

\starttext
$\mathcommand{tan} θ$

\let\tan\relax

\color[tan]{Alan}
\stoptext


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] Obscure math/color bug (namespace clash)

[Alan BRASLAU]

Hello,

I came across the following obscure math/color namespace clash:



\definecolor [tan] [h=d2b48c] % Taken from \setupcolor [x11]

\starttext
$\tan θ$
\stoptext



One solution would be to give precedence in math mode to the standard 
mathematical tokens (here \tan).

Another solution would be simply to avoid the use of tan (as a color). In 
colo-imp-x11.mkiv it could be renamed tan0 (there is already tan1, tan2, 
tan3). This is somewhat unfortunate as tan is a standard X11 color name. On 
the other hand, one would like to be able to use colors in math mode as well...

So I propose the following patch:

121c121
 \definecolor [tan0] [h=d2b48c] % ! namespace clash with $\tan$
---
 \definecolor [tan]  [h=d2b48c]

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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \setuptyping[lines=yes] bug in beta?

[Wolfgang Schuster]

Am 22.10.2013 um 19:47 schrieb Pablo Rodriguez oi...@gmx.es:

 Dear list,
 
 the following sample:
 
 \showframe
 \setuppapersize[S6]
 \setuptyping[option=TEX,lines=yes]

You can use this setup for the moment:

\setuptyping[option=TEX,align={right,broad}]

Wolfgang

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \setuptyping[lines=yes] bug in beta?

[Pablo Rodriguez]

On 10/23/2013 12:28 PM, Wolfgang Schuster wrote:
 Am 22.10.2013 um 19:47 schrieb Pablo Rodriguez oi...@gmx.es:
 
 Dear list,

 the following sample:

 \showframe
 \setuppapersize[S6]
 \setuptyping[option=TEX,lines=yes]
 
 You can use this setup for the moment:
 
 \setuptyping[option=TEX,align={right,broad}]

Many thanks again for your help, Wolfgang.

This is exactly what I need.


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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \setuptyping[lines=yes] bug in beta?

[Pablo Rodriguez]

Dear list,

the following sample:

\showframe
\setuppapersize[S6]
\setuptyping[option=TEX,lines=yes]
\starttext
\starttyping
\startvariante[MRU]{{\em om} X}En un lugar de la Mancha, de cuyo nombre
no quiero acordarme, no ha mucho tiempo que vivía un hidalgo de los de
lanza en astillero, adarga antigua, rocín flaco y galgo
corredor.\stopvariante[MRU]
\stoptyping
\stoptext

gets lines broken wrong in beta from 15.10 (I have just updated the
ConTeXt Suite, but I get no newer beta), but lines are broken right with
MkIV in http://live.contextgarden.net.

I think this may 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] [PATCH] chart-line-bug-fix.patch

[邱红文]

The following patch(pasted below and also attached as an attachment) fixes
the bug that \setupFLOWlines[rulethickness=whatever] have no effects:
--- m-chart.lua.orig2013-03-12 09:22:42.0 +0800
+++ m-chart.lua 2013-08-15 10:52:08.617268698 +0800
@@ -499,7 +499,7 @@
 local linesettings = settings.line
 context(flow_shape_line_color := \\MPcolor{%s} ;,
linesettings.color)
 context(flow_shape_fill_color := \\MPcolor{%s} ;,
linesettings.backgroundcolor)
-context(flow_shape_line_width := %s ; ,
points(linesettingsrulethickness))
+context(flow_shape_line_width := %s ; ,
points(linesettings.rulethickness))
 elseif focus[cell.focus] or focus[cell.name] then
 local focussettings = settings.focus
 context(flow_shape_line_color := \\MPcolor{%s} ;,
focussettings.framecolor)
@@ -580,7 +580,7 @@
 context(flow_touchshape := %s ;,
linesettings.offset == v_none and true or false)
 context(flow_dsp_x := %s ; flow_dsp_y := %s
;,connection.dx or 0, connection.dy or 0)
 context(flow_connection_line_color :=
\\MPcolor{%s} ;,linesettings.color)
-context(flow_connection_line_width := 2pt
;,points(linesettings.rulethickness))
+context(flow_connection_line_width := %s
;,points(linesettings.rulethickness))
 context(flow_connect_%s_%s (%s) (%s,%s,%s)
(%s,%s,%s)
;,where_cell,where_other,j,cellx,celly,what_cell,otherx,othery,what_other)
 context(flow_dsp_x := 0 ; flow_dsp_y := 0 ;)
 end


chart-line-bug-fix.patch
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Hans Hagen]

On 8/2/2013 12:12 AM, Philipp Gesang wrote:

···date: 2013-08-02, Friday···from: Marco Patzer···


On 2013–08–01 Philipp Gesang wrote:


···date: 2013-08-01, Thursday···from: Otared Kavian···


I tested your example: no problem here on Mac OS X 10.8.4, with
either TeXShop, Adobe Redaer or Preview, with the latest beta
(ConTeXt  ver: 2013.08.01 01:31 MKIV beta  fmt: 2013.8.1  int:
english/english).


x64 linux here, but it’s the same with the windows version in
wine32. I get the bad output with okular (poppler), acroread, and
mupdf, but strangely not with zathura (mupdf-based).


Just to add to the list:

x64 linux here, and it works with the following poppler based
viewers (zathura-poppler, xpdf, evince)


i'm a bit puzzled


For those who want to test the git version, the commits are:

 last good: a61813ccdd4b7bcc81932317e1360fda6c79962d
 first bad: 6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8

Don’t forget to delete the cache.

I suspect I found the troublesome changes. The problem vanishes
if I revert this modification to font-map.lua:

 -local separator   = S(_.)
 -local other   = C((1 - separator)^1)
 -local ligsplitter = Ct(other * (separator * other)^0)
 +local ligseparator = P(_)
 +local varseparator = P(.)
 +local namesplitter = Ct(C((1 - ligseparator - varseparator)^1) * 
(ligseparator * C((1 - ligseparator - varseparator)^1))^0)

and then further down:

 -local split = lpegmatch(ligsplitter,name)
 ...
 +local split = lpegmatch(namesplitter,name)

For convenience I repeat the link to the changeset:


what do you revert from ... the + things are already in the file


 
http://repo.or.cz/w/context.git/commitdiff/6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8


btw, this bit of code is evolving (was recently adapt to some border 
case fonts that use their own rules)


anyhow, on my win8 system the beta works with sumatra, okular and 
acrobat (indeed one might need to wipe the cache, but i can increment 
the version number)


Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-02, Friday···from: Hans Hagen···

 On 8/2/2013 12:12 AM, Philipp Gesang wrote:
 ···date: 2013-08-02, Friday···from: Marco Patzer···
 
 On 2013–08–01 Philipp Gesang wrote:
 
 ···date: 2013-08-01, Thursday···from: Otared Kavian···
 
 I tested your example: no problem here on Mac OS X 10.8.4, with
 either TeXShop, Adobe Redaer or Preview, with the latest beta
 (ConTeXt  ver: 2013.08.01 01:31 MKIV beta  fmt: 2013.8.1  int:
 english/english).
 
 x64 linux here, but it’s the same with the windows version in
 wine32. I get the bad output with okular (poppler), acroread, and
 mupdf, but strangely not with zathura (mupdf-based).
 
 Just to add to the list:
 
 x64 linux here, and it works with the following poppler based
 viewers (zathura-poppler, xpdf, evince)

I’m on a different machine now: the problem affects linux x86 and
pdftotext as well. Also, in xpdf I get smallcaps copied as
uppercase instead of lowercase.

 i'm a bit puzzled
 
 For those who want to test the git version, the commits are:
 
  last good: a61813ccdd4b7bcc81932317e1360fda6c79962d
  first bad: 6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8
 
 Don’t forget to delete the cache.
 
 I suspect I found the troublesome changes. The problem vanishes
 if I revert this modification to font-map.lua:
 
  -local separator   = S(_.)
  -local other   = C((1 - separator)^1)
  -local ligsplitter = Ct(other * (separator * other)^0)
  +local ligseparator = P(_)
  +local varseparator = P(.)
  +local namesplitter = Ct(C((1 - ligseparator - varseparator)^1) * 
  (ligseparator * C((1 - ligseparator - varseparator)^1))^0)
 
 and then further down:
 
  -local split = lpegmatch(ligsplitter,name)
  ...
  +local split = lpegmatch(namesplitter,name)
 
 For convenience I repeat the link to the changeset:
 
 what do you revert from ... the + things are already in the file

I’m quoting from the changeset, so the “-” lines indicate the
good version.

  
  http://repo.or.cz/w/context.git/commitdiff/6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8
 
 btw, this bit of code is evolving (was recently adapt to some border
 case fonts that use their own rules)
 
 anyhow, on my win8 system the beta works with sumatra, okular and
 acrobat (indeed one might need to wipe the cache, but i can
 increment the version number)

Weird. Here’s a PDF of the code I posted compiled with version
“2013.08.01 01:31” and how pdftotext renders it:

https://phi-gamma.net/pdf/copypasta.pdf
https://phi-gamma.net/files/copypasta.txt
  
I definitely get   from this
one. The characters are mapped from the private use area:


...
30 beginbfchar
0409 F761
0416 F762
0418 F763
0423 F764
042A F765
0435 F738
...

Can someone reproduce it at all?

Philipp



pgp6shzwsVCjZ.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Marco Patzer]

On 2013–08–02 Philipp Gesang wrote:

 https://phi-gamma.net/pdf/copypasta.pdf
 https://phi-gamma.net/files/copypasta.txt
   
 I definitely get   from this
 one.

Indeed. When I copy from your file I get those private Unicode
slots. When I run the example code from your OP, I get the correct
characters. I don't know what's the difference between those two
files. The LuaTeX version and ConTeXt version is the same.

Creator:ConTeXt - 2013.08.01 01:31
Producer:   LuaTeX-0.76.0

Marco


signature.asc
Description: Digital signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-02, Friday···from: Marco Patzer···

 On 2013–08–02 Philipp Gesang wrote:
 
  https://phi-gamma.net/pdf/copypasta.pdf
  https://phi-gamma.net/files/copypasta.txt

  I definitely get   from this
  one.
 
 Indeed. When I copy from your file I get those private Unicode
 slots. When I run the example code from your OP, I get the correct
 characters. I don't know what's the difference between those two
 files.

The PDF is what Context produces here with that code.

The LuaTeX version and ConTeXt version is the same.
 
 Creator:ConTeXt - 2013.08.01 01:31
 Producer:   LuaTeX-0.76.0

There appears to be a difference between node and base mode
depending on how the font is defined:

  \pdfcompresslevel0
  
  \setupbodyfont [iwona]
  
  \definefontfeature [proto][onum=yes,smcp=yes,script=dflt,lang=dflt]
  \definefontfeature [withbase] [proto] [mode=base]
  \definefontfeature [withnode] [proto] [mode=node]
  
  \definefont [iwonab] [file:Iwona-Regular.otf*withbase]
  \definefont [iwonan] [file:Iwona-Regular.otf*withnode]
  
  \starttext
\feature[]
base mode\par
{\feature[!][withbase]0123456789abcdefghijklmnopqrstuvwxyz\par}
{\iwonab 0123456789abcdefghijklmnopqrstuvwxyz}
  
node mode\par
{\feature[!][withnode]0123456789abcdefghijklmnopqrstuvwxyz\par}
{\iwonan 0123456789abcdefghijklmnopqrstuvwxyz}
  \stoptext \endinput

This gets me (through pdftotext):

  base mode
  
  0123456789abcdefghijklmnopqrstuvwxyz
  node mode
  
  

So base mode with \definefont works while node mode or the font
from the typescript doesn’t.

Philipp


pgpawqMokIqVP.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Hans Hagen]

On 8/2/2013 2:28 PM, Philipp Gesang wrote:

···date: 2013-08-02, Friday···from: Marco Patzer···


On 2013–08–02 Philipp Gesang wrote:


 https://phi-gamma.net/pdf/copypasta.pdf
 https://phi-gamma.net/files/copypasta.txt

I definitely get   from this
one.


Indeed. When I copy from your file I get those private Unicode
slots. When I run the example code from your OP, I get the correct
characters. I don't know what's the difference between those two
files.


The PDF is what Context produces here with that code.


The LuaTeX version and ConTeXt version is the same.

Creator:ConTeXt - 2013.08.01 01:31
Producer:   LuaTeX-0.76.0


There appears to be a difference between node and base mode
depending on how the font is defined:

   \pdfcompresslevel0

   \setupbodyfont [iwona]

   \definefontfeature [proto][onum=yes,smcp=yes,script=dflt,lang=dflt]
   \definefontfeature [withbase] [proto] [mode=base]
   \definefontfeature [withnode] [proto] [mode=node]

   \definefont [iwonab] [file:Iwona-Regular.otf*withbase]
   \definefont [iwonan] [file:Iwona-Regular.otf*withnode]

   \starttext
 \feature[]
 base mode\par
 {\feature[!][withbase]0123456789abcdefghijklmnopqrstuvwxyz\par}
 {\iwonab 0123456789abcdefghijklmnopqrstuvwxyz}

 node mode\par
 {\feature[!][withnode]0123456789abcdefghijklmnopqrstuvwxyz\par}
 {\iwonan 0123456789abcdefghijklmnopqrstuvwxyz}
   \stoptext \endinput

This gets me (through pdftotext):

   base mode
   
   0123456789abcdefghijklmnopqrstuvwxyz
   node mode
   
   

So base mode with \definefont works while node mode or the font
from the typescript doesn’t.


For such tests you need to compare all cases:

nopdfcompression

\setupbodyfont [iwona]

\definefontfeature [withbaseone] [proto] [mode=base]
\definefontfeature [withnodeone] [proto] [mode=node]
\definefontfeature [withbasetwo] [proto] 
[mode=base,onum=yes,smcp=yes,script=dflt,lang=dflt]
\definefontfeature [withnodetwo] [proto] 
[mode=node,onum=yes,smcp=yes,script=dflt,lang=dflt]


\definefont [iwonabone] [file:Iwona-Regular.otf*withbaseone]
\definefont [iwonanone] [file:Iwona-Regular.otf*withnodeone]

\definefont [iwonabtwo] [file:Iwona-Regular.otf*withbasetwo]
\definefont [iwonantwo] [file:Iwona-Regular.otf*withnodetwo]

\starttext

test 1, both modes:

{\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
{\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
{\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
{\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par

% test 2, base only:

% {\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
% {\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par

% test 3, node only:

% {\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
% {\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par

\stoptext

i.e. get rid of potential interferences

attached is what i get


--

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | www.pragma-pod.nl
-


oeps.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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-02, Friday···from: Hans Hagen···

 On 8/2/2013 2:28 PM, Philipp Gesang wrote:
 ···date: 2013-08-02, Friday···from: Marco Patzer···
 
 On 2013–08–02 Philipp Gesang wrote:
 
  https://phi-gamma.net/pdf/copypasta.pdf
  https://phi-gamma.net/files/copypasta.txt
 
 I definitely get   from this
 one.
 
 Indeed. When I copy from your file I get those private Unicode
 slots. When I run the example code from your OP, I get the correct
 characters. I don't know what's the difference between those two
 files.
 
 The PDF is what Context produces here with that code.
 
 The LuaTeX version and ConTeXt version is the same.
 
 Creator:ConTeXt - 2013.08.01 01:31
 Producer:   LuaTeX-0.76.0
 
 There appears to be a difference between node and base mode
 depending on how the font is defined:
 
\pdfcompresslevel0
 
\setupbodyfont [iwona]
 
\definefontfeature [proto][onum=yes,smcp=yes,script=dflt,lang=dflt]
\definefontfeature [withbase] [proto] [mode=base]
\definefontfeature [withnode] [proto] [mode=node]
 
\definefont [iwonab] [file:Iwona-Regular.otf*withbase]
\definefont [iwonan] [file:Iwona-Regular.otf*withnode]
 
\starttext
  \feature[]
  base mode\par
  {\feature[!][withbase]0123456789abcdefghijklmnopqrstuvwxyz\par}
  {\iwonab 0123456789abcdefghijklmnopqrstuvwxyz}
 
  node mode\par
  {\feature[!][withnode]0123456789abcdefghijklmnopqrstuvwxyz\par}
  {\iwonan 0123456789abcdefghijklmnopqrstuvwxyz}
\stoptext \endinput
 
 This gets me (through pdftotext):
 
base mode

0123456789abcdefghijklmnopqrstuvwxyz
node mode


 
 So base mode with \definefont works while node mode or the font
 from the typescript doesn’t.
 
 For such tests you need to compare all cases:
 
 nopdfcompression
 
 \setupbodyfont [iwona]
 
 \definefontfeature [withbaseone] [proto] [mode=base]
 \definefontfeature [withnodeone] [proto] [mode=node]
 \definefontfeature [withbasetwo] [proto]
 [mode=base,onum=yes,smcp=yes,script=dflt,lang=dflt]
 \definefontfeature [withnodetwo] [proto]
 [mode=node,onum=yes,smcp=yes,script=dflt,lang=dflt]
 
 \definefont [iwonabone] [file:Iwona-Regular.otf*withbaseone]
 \definefont [iwonanone] [file:Iwona-Regular.otf*withnodeone]
 
 \definefont [iwonabtwo] [file:Iwona-Regular.otf*withbasetwo]
 \definefont [iwonantwo] [file:Iwona-Regular.otf*withnodetwo]
 
 \starttext
 
 test 1, both modes:
 
 {\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 % test 2, base only:
 
 % {\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 % {\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 % test 3, node only:
 
 % {\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 % {\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 \stoptext
 
 i.e. get rid of potential interferences
 
 attached is what i get

Your PDF is flawless, but on my machine node mode produces the
wrong output. (Also I run the luatex beta-0.76.0-2013040516 that
comes with the minimals.) PDF:

  https://phi-gamma.net/pdf/copypasta-hh.pdf

Here’s a link to the diff between your PDF and my output:

  http://pastie.org/private/zwnesrug7wpy4ket6ppl1g

This bug is quite elusive; can you think of anything that this
behavior might be a side-effect of?

Philipp



pgpuyg2SsYwGc.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-02, Friday···from: Hans Hagen···

 On 8/2/2013 2:28 PM, Philipp Gesang wrote:
 ···date: 2013-08-02, Friday···from: Marco Patzer···
 
 On 2013–08–02 Philipp Gesang wrote:
 
  https://phi-gamma.net/pdf/copypasta.pdf
  https://phi-gamma.net/files/copypasta.txt
 
 I definitely get   from this
 one.
 
 Indeed. When I copy from your file I get those private Unicode
 slots. When I run the example code from your OP, I get the correct
 characters. I don't know what's the difference between those two
 files.
 
 The PDF is what Context produces here with that code.
 
 The LuaTeX version and ConTeXt version is the same.
 
 Creator:ConTeXt - 2013.08.01 01:31
 Producer:   LuaTeX-0.76.0
 
 There appears to be a difference between node and base mode
 depending on how the font is defined:
 
\pdfcompresslevel0
 
\setupbodyfont [iwona]
 
\definefontfeature [proto][onum=yes,smcp=yes,script=dflt,lang=dflt]
\definefontfeature [withbase] [proto] [mode=base]
\definefontfeature [withnode] [proto] [mode=node]
 
\definefont [iwonab] [file:Iwona-Regular.otf*withbase]
\definefont [iwonan] [file:Iwona-Regular.otf*withnode]
 
\starttext
  \feature[]
  base mode\par
  {\feature[!][withbase]0123456789abcdefghijklmnopqrstuvwxyz\par}
  {\iwonab 0123456789abcdefghijklmnopqrstuvwxyz}
 
  node mode\par
  {\feature[!][withnode]0123456789abcdefghijklmnopqrstuvwxyz\par}
  {\iwonan 0123456789abcdefghijklmnopqrstuvwxyz}
\stoptext \endinput
 
 This gets me (through pdftotext):
 
base mode

0123456789abcdefghijklmnopqrstuvwxyz
node mode


 
 So base mode with \definefont works while node mode or the font
 from the typescript doesn’t.
 
 For such tests you need to compare all cases:
 
 nopdfcompression
 
 \setupbodyfont [iwona]
 
 \definefontfeature [withbaseone] [proto] [mode=base]
 \definefontfeature [withnodeone] [proto] [mode=node]
 \definefontfeature [withbasetwo] [proto]
 [mode=base,onum=yes,smcp=yes,script=dflt,lang=dflt]
 \definefontfeature [withnodetwo] [proto]
 [mode=node,onum=yes,smcp=yes,script=dflt,lang=dflt]
 
 \definefont [iwonabone] [file:Iwona-Regular.otf*withbaseone]
 \definefont [iwonanone] [file:Iwona-Regular.otf*withnodeone]
 
 \definefont [iwonabtwo] [file:Iwona-Regular.otf*withbasetwo]
 \definefont [iwonantwo] [file:Iwona-Regular.otf*withnodetwo]
 
 \starttext
 
 test 1, both modes:
 
 {\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 {\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 % test 2, base only:
 
 % {\iwonabone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 % {\iwonabtwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 % test 3, node only:
 
 % {\iwonanone 0123456789abcdefghijklmnopqrstuvwxyz}\par
 % {\iwonantwo 0123456789abcdefghijklmnopqrstuvwxyz}\par
 
 \stoptext
 
 i.e. get rid of potential interferences
 
 attached is what i get

Hi all,

I removed the entire tree (Hans suggested this in a private
message) and started over with a clean install of the minimals.
Now it works as expected, both with Context and Luatex-Fonts.
Might have been caused by a leftover file that didn’t update.

Thanks for your assistance and sorry for the noise!

Best,
Philipp



pgp5GMHdJbGaK.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

Hi,

copypaste from PDF is broken:

  \setupbodyfont [iwona]
  \starttext
\feature[+][just-os,smallcaps] 0123456789 abcdefghijklmnopqrstuvwxyz
  \stoptext

Result:   
Expected: 0123456789abcdefghijklmnopqrstuvwxyz

(Tried in Okular, but reported for other readers as well [1])

Thanks to Marius’ git mirror I could bisect the changes since
TL 2012. It looks like the issue has been introduced with release
stable 2013.05.27 09:10 [2].

Best regards,
Philipp


[1] http://tex.stackexchange.com/q/126333/14066
[2] 
http://repo.or.cz/w/context.git/commitdiff/6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8


pgpDT0CUsud_F.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Otared Kavian]

Hi,

I tested your example: no problem here on Mac OS X 10.8.4, with either TeXShop, 
Adobe Redaer or Preview, with the latest beta (ConTeXt  ver: 2013.08.01 01:31 
MKIV beta  fmt: 2013.8.1  int: english/english).

Best regards: OK

On 1 août 2013, at 19:33, Philipp Gesang 
philipp.ges...@alumni.uni-heidelberg.de wrote:

 Hi,
 
 copypaste from PDF is broken:
 
  \setupbodyfont [iwona]
  \starttext
\feature[+][just-os,smallcaps] 0123456789 abcdefghijklmnopqrstuvwxyz
  \stoptext
 
 Result:   
 Expected: 0123456789abcdefghijklmnopqrstuvwxyz
 
 (Tried in Okular, but reported for other readers as well [1])
 
 Thanks to Marius’ git mirror I could bisect the changes since
 TL 2012. It looks like the issue has been introduced with release
 stable 2013.05.27 09:10 [2].
 
 Best regards,
 Philipp
 
 
 [1] http://tex.stackexchange.com/q/126333/14066
 [2] 
 http://repo.or.cz/w/context.git/commitdiff/6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8
 ___
 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://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Marco Patzer]

On 2013–08–01 Philipp Gesang wrote:

 copypaste from PDF is broken:
 
   \setupbodyfont [iwona]
   \starttext
 \feature[+][just-os,smallcaps] 0123456789 abcdefghijklmnopqrstuvwxyz
   \stoptext
 
 Result:   
 Expected: 0123456789abcdefghijklmnopqrstuvwxyz

Works here with 2013.08.01 01:31 (linux)

Marco


signature.asc
Description: Digital signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-01, Thursday···from: Otared Kavian···

 I tested your example: no problem here on Mac OS X 10.8.4, with
 either TeXShop, Adobe Redaer or Preview, with the latest beta
 (ConTeXt  ver: 2013.08.01 01:31 MKIV beta  fmt: 2013.8.1  int:
 english/english).

x64 linux here, but it’s the same with the windows version in
wine32. I get the bad output with okular (poppler), acroread, and
mupdf, but strangely not with zathura (mupdf-based). It is
present both in texlive and the most recent beta. Going back
exactly one release to 2013.05.22 19:28 fixes it consistently.

Philipp


pgpUT3KsjSagw.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Marco Patzer]

On 2013–08–01 Philipp Gesang wrote:

 ···date: 2013-08-01, Thursday···from: Otared Kavian···
 
  I tested your example: no problem here on Mac OS X 10.8.4, with
  either TeXShop, Adobe Redaer or Preview, with the latest beta
  (ConTeXt  ver: 2013.08.01 01:31 MKIV beta  fmt: 2013.8.1  int:
  english/english).
 
 x64 linux here, but it’s the same with the windows version in
 wine32. I get the bad output with okular (poppler), acroread, and
 mupdf, but strangely not with zathura (mupdf-based).

Just to add to the list:

x64 linux here, and it works with the following poppler based
viewers (zathura-poppler, xpdf, evince)

Marco


signature.asc
Description: Digital signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Jannik Voges]

Works with OS X Preview (10.8.4).



Am 01.08.2013 um 19:33 schrieb Philipp Gesang 
philipp.ges...@alumni.uni-heidelberg.de:


  \setupbodyfont [iwona]
  \starttext
\feature[+][just-os,smallcaps] 0123456789 abcdefghijklmnopqrstuvwxyz
  \stoptext

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] copypaste from pdf bug (smallcaps, text figures)

[Philipp Gesang]

···date: 2013-08-02, Friday···from: Marco Patzer···

 On 2013–08–01 Philipp Gesang wrote:
 
  ···date: 2013-08-01, Thursday···from: Otared Kavian···
  
   I tested your example: no problem here on Mac OS X 10.8.4, with
   either TeXShop, Adobe Redaer or Preview, with the latest beta
   (ConTeXt  ver: 2013.08.01 01:31 MKIV beta  fmt: 2013.8.1  int:
   english/english).
  
  x64 linux here, but it’s the same with the windows version in
  wine32. I get the bad output with okular (poppler), acroread, and
  mupdf, but strangely not with zathura (mupdf-based).
 
 Just to add to the list:
 
 x64 linux here, and it works with the following poppler based
 viewers (zathura-poppler, xpdf, evince)

For those who want to test the git version, the commits are:

last good: a61813ccdd4b7bcc81932317e1360fda6c79962d
first bad: 6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8

Don’t forget to delete the cache.

I suspect I found the troublesome changes. The problem vanishes
if I revert this modification to font-map.lua:

-local separator   = S(_.)
-local other   = C((1 - separator)^1)
-local ligsplitter = Ct(other * (separator * other)^0)
+local ligseparator = P(_)
+local varseparator = P(.)
+local namesplitter = Ct(C((1 - ligseparator - varseparator)^1) * 
(ligseparator * C((1 - ligseparator - varseparator)^1))^0)

and then further down:

-local split = lpegmatch(ligsplitter,name)
...
+local split = lpegmatch(namesplitter,name)

For convenience I repeat the link to the changeset:


http://repo.or.cz/w/context.git/commitdiff/6b2f7c5fd7a3e465f4e2662b1e5bd2c9d5cce8f8

Best,
Philipp



pgpufopMMiwjn.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] TeXexec / mptex / Ruby bug with Unicode letters

[Michal Kvasnička]

Hallo.

It seems that something was changed in Ruby that makes texexec --mptex
not working with some Unicode letters, e.g. rcaron.

This file compiles all right with texexec --mptex:

beginfig(1);
  label(textext(a),origin);
endfig;
end.

However, when I change a to ř (unicode for rcaron or \v{r}), it
failes with this complaint:

/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/switch.rb:21:
Use RbConfig instead of obsolete and deprecated Config.
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/tex.rb:1982:in
`doruntexmp': invalid byte sequence in US-ASCII (ArgumentError)
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/tex.rb:1525:in
`runtexmp'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/tex.rb:1087:in
`block in processmptex'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/tex.rb:1084:in
`each'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/tex.rb:1084:in
`processmptex'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/texexec.rb:76:in
`mptex'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/base/switch.rb:133:in
`execute'
from 
/home/qasar/programy/context.beta/tex/texmf-context/scripts/context/ruby/texexec.rb:791:in
`main'

It crashes both  with the latest beta (downloaded some minutes ago)
and with the latest stable (downloaded yesterday). It crashes also
with the stable instalation that was working previously. Since it
worked properly with Ubuntu 12.04 and is not working (with the same
ConTeXt installation) with Ubuntu 12.10, an  explanation might be a
change in Ruby that makes some ConTeXt code invalid.

I'm using
* Ubuntu 12.10 (Linux)
* Ruby ruby 1.9.3p194 (2012-04-20 revision 35410) [i686-linux]
* texexec
* ConTeXt standalone (minimal) distribution from the ConTeXt Garden,
latest beta, latest stable and some older version that was previously
working.

Since I'm using it to create my teaching slides, I would really
appreciate if you could make some patch (or help me go around
somehow).

Best wishes,
Michal

P.S. I apologize if the bug is known already; I haven't found it in
the mailing list.
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] TeXexec / mptex / Ruby bug with Unicode letters

[Hans Hagen]

On 12/11/2012 9:00 AM, Michal Kvasnička wrote:

Hallo.

It seems that something was changed in Ruby that makes texexec --mptex
not working with some Unicode letters, e.g. rcaron.


probably true


This file compiles all right with texexec --mptex:

beginfig(1);
   label(textext(a),origin);
endfig;
end.


can you run:

context thatfile.mp

and see if you get results?

Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] m-graph.mkiv format bug

[Alan BRASLAU]

There is a bug with format() as redefined in m-graph.mkiv
1e10 and 1e-10 truncate the tailing 0.
(I have not been able to fix the code...)

Alan

Minimal example:

\usemodule [graph]

\starttext
\startMPpage
label(format(@g,1e-10),(0,  0)) ;
label(format(@g,1e+10),(2cm,0)) ;
label(format(@g,1e-12),(0,  -.5cm)) ;
label(format(@g,1e+12),(2cm,-.5cm)) ;
\stopMPpage
\stoptext
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] m-graph.mkiv format bug

[Sietse Brouwer]

 There is a bug with format() as redefined in m-graph.mkiv
 1e10 and 1e-10 truncate the tailing 0.

The function strip() is removing 0 throughout the exponent, and I
don't know what purpose that might serve. If we never want to remove
zeroes, this works:

local function strip(s)
-return \\times10^{..(s:gsub(%+*0*,))..}
+return \\times10^{..(s:gsub(%+*,))..}
end

Note that if the exponent is zero the × 10^0 will be left out
completely, in both the old and the new strip() function. This seems
to be by design. Illustration of this behaviour:

\usemodule[graph]
\starttext
\startMPpage
label(format(@g,1e+0),(2cm,-1cm)) ;
\stopMPpage
\stoptext

Cheers,
Sietse


On Mon, Oct 15, 2012 at 11:19 AM, Alan BRASLAU alan.bras...@cea.fr wrote:
 There is a bug with format() as redefined in m-graph.mkiv
 1e10 and 1e-10 truncate the tailing 0.
 (I have not been able to fix the code...)

 Alan

 Minimal example:

 \usemodule [graph]

 \starttext
 \startMPpage
 label(format(@g,1e-10),(0,  0)) ;
 label(format(@g,1e+10),(2cm,0)) ;
 label(format(@g,1e-12),(0,  -.5cm)) ;
 label(format(@g,1e+12),(2cm,-.5cm)) ;
 \stopMPpage
 \stoptext
 ___
 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://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] m-graph.mkiv format bug

[Alan BRASLAU]

On Mon, 15 Oct 2012 12:08:30 +0200
Sietse Brouwer sbbrou...@gmail.com wrote:

  There is a bug with format() as redefined in m-graph.mkiv
  1e10 and 1e-10 truncate the tailing 0.
 
 The function strip() is removing 0 throughout the exponent, and I
 don't know what purpose that might serve. If we never want to remove
 zeroes, this works:
 
 local function strip(s)
 -return \\times10^{..(s:gsub(%+*0*,))..}
 +return \\times10^{..(s:gsub(%+*,))..}
 end
 
 Note that if the exponent is zero the × 10^0 will be left out
 completely, in both the old and the new strip() function. This seems
 to be by design. Illustration of this behaviour:
 
 \usemodule[graph]
 \starttext
 \startMPpage
 label(format(@g,1e+0),(2cm,-1cm)) ;
 \stopMPpage
 \stoptext


Thanks, this fixes it for now,
but I believe that the strip is intended to remove leading zeros, as in
  label(format(@g,1e+08),(2cm,-1cm)) ;

I suppose that the correct syntax must be something like the regex
  s/[+-]*0*\([1-9]\)/\1/
(not sure how to state this in lua gsub()...)

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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] m-graph.mkiv format bug

[Alan BRASLAU]

On Mon, 15 Oct 2012 12:27:27 +0200
Alan BRASLAU alan.bras...@cea.fr wrote:

 On Mon, 15 Oct 2012 12:08:30 +0200
 Sietse Brouwer sbbrou...@gmail.com wrote:
 
   There is a bug with format() as redefined in m-graph.mkiv
   1e10 and 1e-10 truncate the tailing 0.
  
  The function strip() is removing 0 throughout the exponent, and I
  don't know what purpose that might serve. If we never want to remove
  zeroes, this works:
  
  local function strip(s)
  -return \\times10^{..(s:gsub(%+*0*,))..}
  +return \\times10^{..(s:gsub(%+*,))..}
  end
  
  Note that if the exponent is zero the × 10^0 will be left out
  completely, in both the old and the new strip() function. This seems
  to be by design. Illustration of this behaviour:
  
  \usemodule[graph]
  \starttext
  \startMPpage
  label(format(@g,1e+0),(2cm,-1cm)) ;
  \stopMPpage
  \stoptext
 
 
 Thanks, this fixes it for now,
 but I believe that the strip is intended to remove leading zeros, as
 in label(format(@g,1e+08),(2cm,-1cm)) ;
 
 I suppose that the correct syntax must be something like the regex
   s/[+-]*0*\([1-9]\)/\1/
 (not sure how to state this in lua gsub()...)


Figured it out (and we don't want to strip a leading minus sign):

local function strip(s)
return \\times10^{..(s:gsub(%+*0*([1-9]),%1))..}
end


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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] m-graph.mkiv format bug

[Sietse Brouwer]

Alan wrote:
 Figured it out (and we don't want to strip a leading minus sign):

 local function strip(s)
 return \\times10^{..(s:gsub(%+*0*([1-9]),%1))..}
 end

Better to anchor the pattern to the start of the string with `^` (and
then the nonzerodigitmatching is no longer needed):
gsub(^%+*0*, )
Otherwise, you'll get 805 -- 85.

--Sietse

On Mon, Oct 15, 2012 at 12:45 PM, Alan BRASLAU alan.bras...@cea.fr wrote:
 On Mon, 15 Oct 2012 12:27:27 +0200
 Alan BRASLAU alan.bras...@cea.fr wrote:

 On Mon, 15 Oct 2012 12:08:30 +0200
 Sietse Brouwer sbbrou...@gmail.com wrote:

   There is a bug with format() as redefined in m-graph.mkiv
   1e10 and 1e-10 truncate the tailing 0.
 
  The function strip() is removing 0 throughout the exponent, and I
  don't know what purpose that might serve. If we never want to remove
  zeroes, this works:
 
  local function strip(s)
  -return \\times10^{..(s:gsub(%+*0*,))..}
  +return \\times10^{..(s:gsub(%+*,))..}
  end
 
  Note that if the exponent is zero the × 10^0 will be left out
  completely, in both the old and the new strip() function. This seems
  to be by design. Illustration of this behaviour:
 
  \usemodule[graph]
  \starttext
  \startMPpage
  label(format(@g,1e+0),(2cm,-1cm)) ;
  \stopMPpage
  \stoptext


 Thanks, this fixes it for now,
 but I believe that the strip is intended to remove leading zeros, as
 in label(format(@g,1e+08),(2cm,-1cm)) ;

 I suppose that the correct syntax must be something like the regex
   s/[+-]*0*\([1-9]\)/\1/
 (not sure how to state this in lua gsub()...)


 Figured it out (and we don't want to strip a leading minus sign):

 local function strip(s)
 return \\times10^{..(s:gsub(%+*0*([1-9]),%1))..}
 end


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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] m-graph.mkiv format bug

[Alan BRASLAU]

On Mon, 15 Oct 2012 13:03:40 +0200
Sietse Brouwer sbbrou...@gmail.com wrote:

 Alan wrote:
  Figured it out (and we don't want to strip a leading minus sign):
 
  local function strip(s)
  return \\times10^{..(s:gsub(%+*0*([1-9]),%1))..}
  end
 
 Better to anchor the pattern to the start of the string with `^` (and
 then the nonzerodigitmatching is no longer needed):
 gsub(^%+*0*, )
 Otherwise, you'll get 805 -- 85.

Thank you for the suggestion. Tried it, but this
doesn't work, so I must be missing something...

Of course, with MetaPost 2.0 we will certainly come across such a case
with numbers like 1e805. :)

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

maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage  : http://www.pragma-ade.nl / http://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] [mkvi] comment handling bug

[Hans Hagen]

On 14-5-2012 15:59, Philipp Gesang wrote:

+ leadingcomment


ok

--

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] [mkvi] comment handling bug

[Hans Hagen]

On 13-5-2012 13:12, Philipp Gesang wrote:

Hi all,

seems the mkvi-style macros have trouble with groups in comments:


% macros=mkvi
\def\dosomething#content{%%%= fine with “#1”
   % { %%% Open unbalanced brace breaks macros.
}

\starttext \dosomething {foo} \stoptext


Fails here with:

   to be read again
 c
   l.2 \def\dosomething#c
 ontent{%%%= fine with “#1”

Removing the comment, closing the group or reverting to TEX-style
argument numbering makes this behavior disappear.


Indeed there are some limitations to the parser. I'll note it down as 
low priority issue.


Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] [mkvi] comment handling bug

[Philipp Gesang]

On 2012-05-14 09:35, Hans Hagen wrote:
 On 13-5-2012 13:12, Philipp Gesang wrote:
 Hi all,
 
 seems the mkvi-style macros have trouble with groups in comments:
 
 
 % macros=mkvi
 \def\dosomething#content{%%%= fine with “#1”
% { %%% Open unbalanced brace breaks macros.
 }
 
 \starttext \dosomething {foo} \stoptext
 
 
 Fails here with:
 
to be read again
  c
l.2 \def\dosomething#c
  ontent{%%%= fine with “#1”
 
 Removing the comment, closing the group or reverting to TEX-style
 argument numbering makes this behavior disappear.
 
 Indeed there are some limitations to the parser. I'll note it down
 as low priority issue.

Would it be possible to modify the comment pattern so that it
accept initial spaces? At least it fixes my problem.

Philipp

--- /home/laokoon/base/luat-mac.lua 2012-05-14 14:52:40.674091445 +0200
+++ luat-mac.lua2012-05-14 15:18:35.968999022 +0200
@@ -110,8 +110,10 @@
 
 local commenttoken   = P(%)
 local crorlf = S(\n\r)
-local commentline= commenttoken * ((Carg(1) * 
C((1-crorlf)^0))/function(strip,s) return strip and  or s end)
-local commentline= commenttoken * ((1-crorlf)^0)
+--local commentline= commenttoken * ((Carg(1) * 
C((1-crorlf)^0))/function(strip,s) return strip and  or s end)
+--local commentline= commenttoken * ((1-crorlf)^0)
+local commentstart   = space^0 * commenttoken
+local commentline= commentstart * ((1-crorlf)^0)
 local leadingcomment = (commentline * crorlf^1)^1
 local furthercomment = (crorlf^1 * commentline)^1


pgpRRztvZEQT4.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] [mkvi] comment handling bug

[Philipp Gesang]

On 2012-05-14 15:22, Philipp Gesang wrote:
 On 2012-05-14 09:35, Hans Hagen wrote:
  On 13-5-2012 13:12, Philipp Gesang wrote:
  Hi all,
  
  seems the mkvi-style macros have trouble with groups in comments:
  
  
  % macros=mkvi
  \def\dosomething#content{%%%= fine with “#1”
 % { %%% Open unbalanced brace breaks macros.
  }
  
  \starttext \dosomething {foo} \stoptext
  
  
  Fails here with:
  
 to be read again
   c
 l.2 \def\dosomething#c
   ontent{%%%= fine with “#1”
  
  Removing the comment, closing the group or reverting to TEX-style
  argument numbering makes this behavior disappear.
  
  Indeed there are some limitations to the parser. I'll note it down
  as low priority issue.
 
 Would it be possible to modify the comment pattern so that it
 accept initial spaces? At least it fixes my problem.

I take that back, sorry for the noise. The better solution
appears to be adding the “leadingcomment” pattern to the rule
that handles balanced braces:



--- /home/laokoon/base/luat-mac.lua 2012-05-14 14:52:40.674091445 +0200
+++ luat-mac.lua2012-05-14 15:55:50.683559201 +0200
@@ -110,7 +110,7 @@
 
 local commenttoken   = P(%)
 local crorlf = S(\n\r)
-local commentline= commenttoken * ((Carg(1) * 
C((1-crorlf)^0))/function(strip,s) return strip and  or s end)
+--local commentline= commenttoken * ((Carg(1) * 
C((1-crorlf)^0))/function(strip,s) return strip and  or s end)
 local commentline= commenttoken * ((1-crorlf)^0)
 local leadingcomment = (commentline * crorlf^1)^1
 local furthercomment = (crorlf^1 * commentline)^1
@@ -160,6 +160,7 @@
 + V(texcode)
 + V(braced)
 + furthercomment
++ leadingcomment
 + nobrace
   )^0
  -- * rightbrace^-1, -- the -1 catches errors



Now definitions with commented-out unbalanced stuff like

  \def\dosomething#content{%%% {{
% { }{{ %%
\bgroup\italic#content\egroup
  }

will work too.

Philipp




pgpD2je4rZr8c.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] [mkvi] comment handling bug

[Philipp Gesang]

Hi all,

seems the mkvi-style macros have trouble with groups in comments:


% macros=mkvi
\def\dosomething#content{%%% = fine with “#1”
  % { %%% Open unbalanced brace breaks macros.
}

\starttext \dosomething {foo} \stoptext


Fails here with:

  to be read again 
c
  l.2 \def\dosomething#c
ontent{%%% = fine with “#1”

Removing the comment, closing the group or reverting to TEX-style
argument numbering makes this behavior disappear.

Philipp


-- 
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


pgpCwiy8mxOvG.pgp
Description: PGP signature
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \...structurelevel - probably a bug in the last version

[Procházka Lukáš Ing . - Pontex s . r . o .]

Hello,

I've just updated ConTeXt.

The following code used to work so far, now I'm getting error:


\definestructurelevels[A][section,]

\starttext
  \startstructurelevel[A][title=Title]
\input knuth
  \stopstructurelevel
\stoptext



This is LuaTeX, Version beta-0.70.1-2012032923 (TeX Live 2012)
...
ConTeXt  ver: 2012.04.07 14:42 MKIV  fmt: 2012.4.9  int: english/english
...
! LuaTeX error main ctx instance:1: attempt to call field 'startautolevel' (a 
nil value)
stack traceback:
main ctx instance:1: in main chunk.

system   tex  error on line 4 in file 
C:/Lukas/Jobs/D5-035.Zat/SO_201/Texts/Test/t2.mkiv:

1 \definestructurelevels[A][subsubsubsection,]
2
3 \starttext
4 \startstructurelevel[A][title=Title]
5 \input knuth
6   \stopstructurelevel
7 \stoptext
8


Best regards,

Lukas


--
Ing. Lukáš Procházka [mailto:l...@pontex.cz]
Pontex s. r. o.  [mailto:pon...@pontex.cz] [http://www.pontex.cz]
Bezová 1658
147 14 Praha 4

Tel: +420 244 062 238
Fax: +420 244 461 038

t2.log
Description: Binary data


t2.mkiv
Description: Binary data


t2.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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \...structurelevel - probably a bug in the last version

[Wolfgang Schuster]

Am 09.04.2012 um 08:40 schrieb Procházka Lukáš Ing. - Pontex s. r. o.:

 Hello,
 
 I've just updated ConTeXt.
 
 The following code used to work so far, now I'm getting error:
 
 
 \definestructurelevels[A][section,]
 
 \starttext
  \startstructurelevel[A][title=Title]
\input knuth
  \stopstructurelevel
 \stoptext
 

Change this in strc-lev.mkvi:

\unexpanded\def\strc_levels_start[#category]%
  {\doifassignmentelse{#category}
-{\ctxcommand{startautolevel(\v!default)}[#category]}
-{\ctxcommand{startautolevel(#category)}}}
+{\ctxcommand{startsectionlevel(\v!default)}[#category]}
+{\ctxcommand{startsectionlevel(#category)}}}

As you can see in the file the commands have new names and the old names are 
synonyms for backward compatibility.

Wolfgang
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \placeinitial or texbackground bug (interference)

[Alan Braslau]

It took me quite a while to hunt this down...

The use of a text background breaks \placeinitial.

I do not have a patch, but at least can provide a minimal example:

\definetextbackground [SetOff] [location=paragraph]
\starttext
\placeinitial
\input tufte
\startSetOff
\input ward
\stopSetOff
\stoptext
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \setuplist[alternative=g] bug with interactive document

[Wolfgang Schuster]

Am 19.02.2012 um 23:00 schrieb Pablo Rodríguez:

 Hi Wolfgang,
 
 I have a with \setuplist[alternative=g] in an interactive document.
 
 Here you have the minimal sample:
 
 \setupinteraction[state=start]
 \setupcombinedlist[content][interaction=all]
 \setuplist[part][alternative=g]
 \setuplist[chapter][alternative=d]
 \starttext
 \completecontent
 \part{part}
 \chapter{chapter}
 \part{part}
 \stoptext
 
 The second \part should start a new line. I now that you told me that I
 was misusing “alternative=g”, because it was meant for interactive
 documents (but this is exactly what I have).
 
 Sorry, but since I got no reply, I'm still wondering whether this is a
 bug or an illegitimate use of “alternative=g”.
 
 Would you be so kind to explain what is wrong here.

The alternative d put’s all entries in a single line and this works perfect when
you have a parent with alternative a–c. The alternatives e–g have also this
requirement but I guess they aren’t meant to be used in combination with
other alternatives.

Wolfgang
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \setuplist[alternative=g] bug with interactive document

[Hans Hagen]

On 20-2-2012 10:58, Wolfgang Schuster wrote:


The alternative d put’s all entries in a single line and this works perfect when
you have a parent with alternative a–c. The alternatives e–g have also this
requirement but I guess they aren’t meant to be used in combination with
other alternatives.


e-g are mostly meant for screen documents and for instance have framed 
content (for menus etc) and such lists are normally not nested


in a-c one can do things like pagenumber=no to simplify a list

Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] \setuplist[alternative=g] bug with interactive document

[Pablo Rodríguez]

On 02/20/2012 12:56 PM, Hans Hagen wrote:
 On 20-2-2012 10:58, Wolfgang Schuster wrote:
 
 The alternative d put’s all entries in a single line and this works perfect 
 when
 you have a parent with alternative a–c. The alternatives e–g have also this
 requirement but I guess they aren’t meant to be used in combination with
 other alternatives.
 
 e-g are mostly meant for screen documents and for instance have framed 
 content (for menus etc) and such lists are normally not nested
 
 in a-c one can do things like pagenumber=no to simplify a list.

Many thanks, Wolfgang and Hans, for your replies.


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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \setuplist[alternative=g] bug with interactive document

[Pablo Rodríguez]

Hi Wolfgang,

I have a with \setuplist[alternative=g] in an interactive document.

Here you have the minimal sample:

\setupinteraction[state=start]
\setupcombinedlist[content][interaction=all]
\setuplist[part][alternative=g]
\setuplist[chapter][alternative=d]
\starttext
\completecontent
\part{part}
\chapter{chapter}
\part{part}
\stoptext

The second \part should start a new line. I now that you told me that I
was misusing “alternative=g”, because it was meant for interactive
documents (but this is exactly what I have).

Sorry, but since I got no reply, I'm still wondering whether this is a
bug or an illegitimate use of “alternative=g”.

Would you be so kind to explain what is wrong 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] spaceskip in \framed bug

[Idris Samawi Hamid ادريس سماوي حامد]

On Thu, 29 Dec 2011 07:55:37 -0700, Hans Hagen pra...@wxs.nl wrote:


On Sun, 25 Dec 2011 13:07:44 -0700, Idris Samawi Hamid ادريس سماوي حامد



The following used to work in mkiv, but no longer (works in mkii):




Setups come before setting the alignment and alignments sets the  
spaceskip too.


Are you sure that it worked before? nothing changed in that order.


I just now tried it again in mkii, and it works fine there.

Also, I've used this paradigm in one of my samples for a long time now in  
mkiv, and it definitely used to work. Indeed, I only tried mkii on a whim,  
this sample was a mkiv sample to start with.


In any case, I'm not clear on your point:

Setups come before setting the alignment and alignments sets the  
spaceskip too.


I have not found a combination that works in mkiv: Please advise. Here is  
the code again for reference:


==
\startsetups stretchline
  \spaceskip=0pt plus 2 fill \relax
\stopsetups
\setupframed[frame=on,width=\textwidth,setups=stretchline,
 offset=none,location=depth,align=l2r]
\showframe
\starttext
\framed{This is a test.}
\stoptext
==

Best wishes
Idris
--
Professor Idris Samawi Hamid, Editor-in-Chief
International Journal of Shīʿī Studies
Department of Philosophy
Colorado State University
Fort Collins, CO 80523
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] spaceskip in \framed bug

[Idris Samawi Hamid ادريس سماوي حامد]

Dear gang,

Did not hear back on this, trying again ...

Best wishes
Idris

On Sun, 25 Dec 2011 13:07:44 -0700, Idris Samawi Hamid ادريس   سماوي حامد  
isha...@colostate.edu wrote:



Dear gang,

The following used to work in mkiv, but no longer (works in mkii):

===
% stretchline.tex
\startsetups stretchline
   \spaceskip=0pt plus 2 fill \relax
\stopsetups
\setupframed[frame=on,width=\textwidth,setups=stretchline,
 offset=none,location=depth,align=l2r]
\showframe
\starttext
\framed{This is a test.}
\stoptext
===

This is LuaTeX, Version beta-0.71.0-2011071409 (rev 4332)
  \write18 enabled.
(stretchline.tex

ConTeXt  ver: 2011.11.25 21:29 MKIV  fmt: 2011.11.25

===

Is it a bug? Any workarounds?


--
Professor Idris Samawi Hamid, Editor-in-Chief
International Journal of Shīʿī Studies
Department of Philosophy
Colorado State University
Fort Collins, CO 80523
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] spaceskip in \framed bug

[Hans Hagen]

On 29-12-2011 15:21, Idris Samawi Hamid ادريس   سماوي حامد wrote:

Dear gang,

Did not hear back on this, trying again ...

Best wishes
Idris

On Sun, 25 Dec 2011 13:07:44 -0700, Idris Samawi Hamid ادريس سماوي حامد
isha...@colostate.edu wrote:


Dear gang,

The following used to work in mkiv, but no longer (works in mkii):


Setups come before setting the alignment and alignments sets the 
spaceskip too.


Are you sure that it worked before? nothing changed in that order.

Hans

-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] spaceskip in \framed bug

[Idris Samawi Hamid ادريس سماوي حامد]

Dear gang,

The following used to work in mkiv, but no longer (works in mkii):

===
% stretchline.tex
\startsetups stretchline
  \spaceskip=0pt plus 2 fill \relax
\stopsetups
\setupframed[frame=on,width=\textwidth,setups=stretchline,
 offset=none,location=depth,align=l2r]
\showframe
\starttext
\framed{This is a test.}
\stoptext
===

This is LuaTeX, Version beta-0.71.0-2011071409 (rev 4332)
 \write18 enabled.
(stretchline.tex

ConTeXt  ver: 2011.11.25 21:29 MKIV  fmt: 2011.11.25

===

Is it a bug? Any workarounds?

Best wishes
Idris
--
Professor Idris Samawi Hamid, Editor-in-Chief
International Journal of Shīʿī Studies
Department of Philosophy
Colorado State University
Fort Collins, CO 80523
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Ulrike Fischer]

Am Sat, 04 Jun 2011 11:26:37 +0200 schrieb Taco Hoekwater:

 Thank you everybody for your answers.  Writing Tr{\a}ger as Thomas
 suggested works well, but unfortunately, I'm using Mendeley Desktop
 for the management of my bibtex file and I can't seem to be able to
 influence the way in which it encodes the special characters.

 Find a different program, then. Bibtex does *not* deal with UTF-8 
 correctly, period. (complaints to Oren Patashnik please ;))

Doesn't context support biber? Or could Julian save its bib in an
8bit-encoding and context read the bbl as 8bit?


-- 
Ulrike Fischer 

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Arthur Reutenauer]

 Well, there *is* more than one way to represent ä in UTF-8

  If you mean non-shortest forms such as 0xE0 0x83 0xA4 or 0xF0 0x80 0x83
0xA4, then no, they have been forbidden since Unicode 3 in 2000 (formally
Corrigendum #1, see http://www.unicode.org/versions/corrigendum1.html).

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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Pontus Lurcock]

On Mon 06 Jun 2011, Arthur Reutenauer wrote:

  Well, there *is* more than one way to represent ä in UTF-8
 
 If you mean non-shortest forms such as 0xE0 0x83 0xA4 or 0xF0 0x80
 0x83 0xA4, then no, they have been forbidden since Unicode 3 in 2000
 (formally Corrigendum #1, see
 http://www.unicode.org/versions/corrigendum1.html).

I was actually thinking of precomposed vs. combining diacritics. I was
blissfully unaware of the non-shortest-form problem up until now...

Pont
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Arthur Reutenauer]

 I was actually thinking of precomposed vs. combining diacritics. I was
 blissfully unaware of the non-shortest-form problem up until now...

  Ah, OK.  But that's exactly the issue for which canonical equivalence
was designed, and in a Unicode-aware version of BibTeX that shouldn't be
an issue.  However, for now...

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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Julian Becker]

Thank you everybody for your answers.  Writing Tr{\a}ger as Thomas
suggested works well, but unfortunately, I'm using Mendeley Desktop for the
management of my bibtex file and I can't seem to be able to influence the
way in which it encodes the special characters.

@Mojca: Indeed, it also fails if I just write Träger in UTF-8 encoding
(however, Schräger works just fine. All combinations where the ä is at
the third place of the word seem to fail.). The error message is similar but
slightly different now. The log file shows the following:
---
system  begin file test.tex at line 3
publications  loading database from test.bbl
(test.bbl
! String contains an invalid utf-8 sequence.
l.1 \setuppublicationlist[samplesize={Tr
Ã06},totalnumber=1]
A funny symbol that I can't read has just been (re)read.
Just continue, I'll change it to 0xFFFD.

! String contains an invalid utf-8 sequence.
l.5 n=1,s=Tr
Ã06]
A funny symbol that I can't read has just been (re)read.
Just continue, I'll change it to 0xFFFD.

! String contains an invalid utf-8 sequence.
\doifassignmentelse ...gnmentelse \detokenize {#1}
=@@\@end@ \expandafter \se...
\dostartpublication ... -\doifassignmentelse {#1}
{\getparameters [\??pb ][k...
l.9 \stoppublication

A funny symbol that I can't read has just been (re)read.
Just continue, I'll change it to 0xFFFD.

)
---

Julian


2011/6/4 Pontus Lurcock p...@talvi.net

 On Fri 03 Jun 2011, Thomas A. Schmitz wrote:

  But I admit it's not easy to know that, bibtex documentation is a
  real mess

 Patience please! ‘This document will be expanded when BibTEX version
 1.00 comes out’ -- BIBTEXing, February 8, 1988.

 :-)

 Pont

 ___
 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://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 wiki : http://contextgarden.net

 ___




-- 
Julian Becker
Institut für Angewandte Physik, R.123
Westfälische Wilhelms-Universität Münster
Corrensstr. 2/4
48149 Münster / Westfalen
Tel. 0251 83-3 61 53
Mob. 0151 599 848 29
e-mail: j_bec...@uni-muenster.de

Keep thy heart with all diligence; for it is the wellspring of life.
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Julian Becker]

I can also add that in the first case with the author name Träger, the
generated bbl-file looks messed up and (Notepad++ doesn't recognize the
encoding as UTF8. Changing the encoding to UTF8 manually shows the complete
names Träger correctly, but the abbreviations (what should have been
Trä06) seem to be messed up.

I'm not familiar with the intricacies and details of UTF8 encoding, but is
it possible that there is a byte missing from the ä which has been cut off
during the abbreviation process?

The abbreviated Trä06 seems to be incorrectly encoded (in hexadecimal) as:
54 C3 A4 30 36,
while it should be: 54 72 C3 A4 30 36.

So in the abbreviation process, the encoding of some characters over several
bytes seems to be neglected.

I attached the bbl-files for both cases to this e-mail, since I don't know,
what would happen to the encoding, if I just pasted them as plain text here.

Julian


2011/6/4 Julian Becker becker.jul...@gmail.com

 Thank you everybody for your answers.  Writing Tr{\a}ger as Thomas
 suggested works well, but unfortunately, I'm using Mendeley Desktop for the
 management of my bibtex file and I can't seem to be able to influence the
 way in which it encodes the special characters.

 @Mojca: Indeed, it also fails if I just write Träger in UTF-8 encoding
 (however, Schräger works just fine. All combinations where the ä is at
 the third place of the word seem to fail.). The error message is similar but
 slightly different now. The log file shows the following:
 ---
 system  begin file test.tex at line 3
 publications  loading database from test.bbl
 (test.bbl
 ! String contains an invalid utf-8 sequence.
 l.1 \setuppublicationlist[samplesize={Tr
 Ã06},totalnumber=1]
 A funny symbol that I can't read has just been (re)read.
 Just continue, I'll change it to 0xFFFD.

 ! String contains an invalid utf-8 sequence.
 l.5 n=1,s=Tr
 Ã06]
 A funny symbol that I can't read has just been (re)read.
 Just continue, I'll change it to 0xFFFD.

 ! String contains an invalid utf-8 sequence.
 \doifassignmentelse ...gnmentelse \detokenize {#1}
 =@@\@end@ \expandafter \se...
 \dostartpublication ... -\doifassignmentelse {#1}
 {\getparameters [\??pb ][k...
 l.9 \stoppublication

 A funny symbol that I can't read has just been (re)read.
 Just continue, I'll change it to 0xFFFD.

 )
 ---

 Julian


 2011/6/4 Pontus Lurcock p...@talvi.net

 On Fri 03 Jun 2011, Thomas A. Schmitz wrote:

  But I admit it's not easy to know that, bibtex documentation is a
  real mess

 Patience please! ‘This document will be expanded when BibTEX version
 1.00 comes out’ -- BIBTEXing, February 8, 1988.

 :-)

 Pont

 ___
 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://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 wiki : http://contextgarden.net

 ___




 --
 Julian Becker
 Institut für Angewandte Physik, R.123
 Westfälische Wilhelms-Universität Münster
 Corrensstr. 2/4
 48149 Münster / Westfalen
 Tel. 0251 83-3 61 53
 Mob. 0151 599 848 29
 e-mail: j_bec...@uni-muenster.de

 Keep thy heart with all diligence; for it is the wellspring of life.




-- 
Julian Becker
Institut für Angewandte Physik, R.123
Westfälische Wilhelms-Universität Münster
Corrensstr. 2/4
48149 Münster / Westfalen
Tel. 0251 83-3 61 53
Mob. 0151 599 848 29
e-mail: j_bec...@uni-muenster.de

Keep thy heart with all diligence; for it is the wellspring of life.


testA.bbl
Description: Binary data


testB.bbl
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Taco Hoekwater]

On 06/04/2011 11:23 AM, Julian Becker wrote:


Thank you everybody for your answers.  Writing Tr{\a}ger as Thomas
suggested works well, but unfortunately, I'm using Mendeley Desktop
for the management of my bibtex file and I can't seem to be able to
influence the way in which it encodes the special characters.


Find a different program, then. Bibtex does *not* deal with UTF-8 
correctly, period. (complaints to Oren Patashnik please ;))


Best wishes,
Taco
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Pontus Lurcock]

On Sat 04 Jun 2011, Julian Becker wrote:

 I'm not familiar with the intricacies and details of UTF8 encoding,
 but is it possible that there is a byte missing from the ä which
 has been cut off during the abbreviation process?

Well, there *is* more than one way to represent ä in UTF-8, but it's
my understanding that anything beyond ASCII is simply not supported by
BibTeX. You can get away with it in fields that just get pasted
verbatim into the output (usually), but the first three letters of the
first author's name are used to construct the key (which is why
‘Schräger’ worked) so there's no way around using the officially
sanctioned {\a} form.

  unfortunately, I'm using Mendeley Desktop for the management of my
  bibtex file and I can't seem to be able to influence the way in
  which it encodes the special characters.

This is one reason why I still use plain emacs as a bibliography
manager -- sooner or later you need a hack, and that's harder when the
raw BibTeX is hidden or generated. In this case you may need to
put the hack between Mendeley and BibTeX: pipe the file through 
‘sed -e 's/ä/{\\a}/g'’ or something similar. And/or ask in the Mendeley 
support forums, since this is a fairly well-known BibTeX ‘feature’
so perhaps someone else has had to deal with it there.

Hope this helps,

Pont
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Julian Becker]

I think I'll go for the piping option then, which seems to be the easiest
way out.

Thanks for the insights, I didn't actually know much about the interplay of
context and bibtex until this little problem occured to me...

Julian


2011/6/4 Pontus Lurcock p...@talvi.net

 On Sat 04 Jun 2011, Julian Becker wrote:

  I'm not familiar with the intricacies and details of UTF8 encoding,
  but is it possible that there is a byte missing from the ä which
  has been cut off during the abbreviation process?

 Well, there *is* more than one way to represent ä in UTF-8, but it's
 my understanding that anything beyond ASCII is simply not supported by
 BibTeX. You can get away with it in fields that just get pasted
 verbatim into the output (usually), but the first three letters of the
 first author's name are used to construct the key (which is why
 ‘Schräger’ worked) so there's no way around using the officially
 sanctioned {\a} form.

   unfortunately, I'm using Mendeley Desktop for the management of my
   bibtex file and I can't seem to be able to influence the way in
   which it encodes the special characters.

 This is one reason why I still use plain emacs as a bibliography
 manager -- sooner or later you need a hack, and that's harder when the
 raw BibTeX is hidden or generated. In this case you may need to
 put the hack between Mendeley and BibTeX: pipe the file through
 ‘sed -e 's/ä/{\\a}/g'’ or something similar. And/or ask in the Mendeley
 support forums, since this is a fairly well-known BibTeX ‘feature’
 so perhaps someone else has had to deal with it there.

 Hope this helps,

 Pont

 ___
 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://tex.aanhet.net
 archive  : http://foundry.supelec.fr/projects/contextrev/
 wiki : http://contextgarden.net

 ___




-- 
Julian Becker
Institut für Angewandte Physik, R.123
Westfälische Wilhelms-Universität Münster
Corrensstr. 2/4
48149 Münster / Westfalen
Tel. 0251 83-3 61 53
Mob. 0151 599 848 29
e-mail: j_bec...@uni-muenster.de

Keep thy heart with all diligence; for it is the wellspring of life.
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] undefined control sequence bug with German umlaut in bibliography

[Julian Becker]

I came across an issue in context (context ver. 2011.05.18 22:26, LuaTeX
ver: beta-0.65.0-2010121421 (rev 4034) ) when trying to cite a bibliography
item having an author with a German umlaut ä

Compiling the short example below, produces the following output and then
-
...
system  begin file test.tex at line 3
publications  loading database from test.bbl
(test.bbl
! Undefined control sequence.
\@@pbs -Tr\0
6
\dostartpublication ...@@pby \noexpand \or \@@pbs
\noexpand \or \@@pbn \noex...
l.9 \stoppublication

)
backend  xmp  using file
'M:/Programs/context/tex/texmf-local/tex/context/base/lpdf-pdx.xml'
pages  flushing realpage 1, userpage 1, subpage 1
system  end file test.tex at line 5
...
mtx-context | fatal error: return code: 1
--

The strange thing is that when I change the Tr\{a}ger to Schr\{a}ger,
everything works just fine.
Does anybody know what's going on here?!

Julian


---test.tex-
\setuppublications[alternative=apa,sorttype=bbl]
\setupbibtex[database=test.bib]
\starttext
I'd like to cite \cite[Entry1].
\stoptext


-test.bib:---this one produces an error-
@misc{Entry1,
author = {Tr\{a}ger, D},
title = {{Some Document}},
year = {2006}
}
--

test.bib--this works---
@misc{Entry1,
author = {Schr\{a}ger, D},
title = {{Some Document}},
year = {2006}
}
--

-- 
Julian Becker
Institut für Angewandte Physik, R.123
Westfälische Wilhelms-Universität Münster
Corrensstr. 2/4
48149 Münster / Westfalen
Tel. 0251 83-3 61 53
Mob. 0151 599 848 29
e-mail: j_bec...@uni-muenster.de

Keep thy heart with all diligence; for it is the wellspring of life.
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Thomas A. Schmitz]

On Jun 3, 2011, at 8:38 PM, Julian Becker wrote:

 I came across an issue in context (context ver. 2011.05.18 22:26, LuaTeX ver: 
 beta-0.65.0-2010121421 (rev 4034) ) when trying to cite a bibliography item 
 having an author with a German umlaut ä
 

From btxdoc, which is part of texlive:

you must place the entire accented character in braces; in this case either 
{\a} or {\{a}} will do. Furthermore these braces must not themselves be 
enclosed in braces (other than the ones that might delimit the entire field or 
the entire entry); and there must be a backslash as the very first character 
inside the braces...

Thusly: Tr{\a}ger

But I admit it's not easy to know that, bibtex documentation is a real mess, 
and Oren Patashnik appears to suffer from a real disease which prevents him 
from writing clear sentences and easily parsable documents.

Thomas
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] undefined control sequence bug with German umlaut in bibliography

[Pontus Lurcock]

On Fri 03 Jun 2011, Thomas A. Schmitz wrote:

 But I admit it's not easy to know that, bibtex documentation is a
 real mess

Patience please! ‘This document will be expanded when BibTEX version
1.00 comes out’ -- BIBTEXing, February 8, 1988.

:-)

Pont
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] \em around \placefigure (bug?)

[Procházka Lukáš Ing . - Pontex s . r . o .]

Hello,

the \em statement being placed as the first command of a paragraph to flow 
around a \placefigure seems to SCRATCH the figure instead of to flow around 
(bug?). See the minimal example:

---

\starttext
  \placefigure
[left,none]
{}
{ \startMPcode
draw (0,0)--(6cm,6cm);
  \stopMPcode
}

  01234656789 01234656789 01234656789 01234656789 01234656789 01234656789 
01234656789

  {\em 01234656789} 01234656789 01234656789 01234656789 01234656789 01234656789 
01234656789

  01234656789 {\em 01234656789} 01234656789 01234656789 01234656789 01234656789 
01234656789

  \input tufte
\stoptext

---

Best regards

Lukas


--
Ing. Lukáš Procházka [mailto:l...@pontex.cz]
Pontex s. r. o.  [mailto:pon...@pontex.cz] [http://www.pontex.cz]
Bezová 1658
147 14 Praha 4

Tel: +420 244 062 238
Fax: +420 244 461 038

t-Hang3.mkiv
Description: Binary data


t-Hang3.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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] list of figures (bug?)

[Rogutės Sparnuotos]

Hello,

What is the correct way to set 'alternative=c' for the
\completelistoffigures?

This works:

  \starttext
\completelistoffigures[alternative=c]
\placefigure[here]{x}{}
\placefigure[here]{y}{}
  \stoptext

But this doesn't:

  \setupcombinedlist[listoffigures][alternative=c]
  \starttext
\completelistoffigures
\placefigure[here]{x}{}
\placefigure[here]{y}{}
  \stoptext

Why? If I add \definecombinedlist[listoffigures][figure], it starts
working, but the list is printed without the title... This seems
inconsistent, so either I have something wrong or there is a bug, no?

-- 
--  Rogutės Sparnuotos
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] line-break index bug

[Steffen Wolfrum]

Hi,


I am sorry, but in  ConTeXt  ver: 2010.04.10 MKIV there still is this 
index/line-break bug!


See example below please:


\setuplayout[width=113mm,location=middle]
\usetypescript[postscript]
\definetypeface[postscript][rm][serif][times][default]
\mainlanguage[de]
\setupbodyfont[postscript,10pt] \setupinterlinespace[line=12pt]
\setupalign[line,block]

\starttext

dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen\index{Ingenieurleistungen}. Warum?

\stoptext






index_bug.pdf
Description: Adobe PDF document


Steffen___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] line-break index bug

[Thomas A. Schmitz]

On Apr 12, 2010, at 10:52 AM, Steffen Wolfrum wrote:


Hi,


I am sorry, but in  ConTeXt  ver: 2010.04.10 MKIV there still is  
this index/line-break bug!




It's not a bug, it's explained somewhere in the manual. Put the \index  
entry before the indexed word, and all is well.


Thomas
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] line-break index bug

[Steffen Wolfrum]

Am 12.04.2010 um 11:09 schrieb Thomas A. Schmitz:

 
 On Apr 12, 2010, at 10:52 AM, Steffen Wolfrum wrote:
 
 Hi,
 
 
 I am sorry, but in  ConTeXt  ver: 2010.04.10 MKIV there still is this 
 index/line-break bug!
 
 
 It's not a bug, it's explained somewhere in the manual. Put the \index entry 
 before the indexed word, and all is well.


I am setting text that authors indexed in MSWord ... and they don't care where 
to put the \index (often it is placed IN the word ;o)
And I don't dare to touch thousands of index marks!

BTW: it always worked with MkII. 
Please let it work again in MkIV, too. 


For I can't change the behavior of people setting their index marks, MkIV 
should be as tolerant in that respect as MkII is.


Steffen

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] line-break index bug

[Wolfgang Schuster]

Am 12.04.10 10:52, schrieb Steffen Wolfrum:

Hi,

I am sorry, but in  ConTeXt  ver: 2010.04.10 MKIV there still is this 
index/line-break bug!

See example below please:

\setuplayout[width=113mm,location=middle]
\usetypescript[postscript]
\definetypeface[postscript][rm][serif][times][default]
\mainlanguage[de]
\setupbodyfont[postscript,10pt] \setupinterlinespace[line=12pt]
\setupalign[line,block]

\starttext

dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen\index{Ingenieurleistungen}. Warum?

\stoptext
   

Can you test

\unexpanded\def\forcecolorhack{\penalty\leaders\hrule\normalhskip\zeropoint}

in your document.

Wolfgang

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] line-break index bug

[Steffen Wolfrum]

Am 12.04.2010 um 15:41 schrieb Wolfgang Schuster:

 Am 12.04.10 10:52, schrieb Steffen Wolfrum:
 Hi,
 
 I am sorry, but in  ConTeXt  ver: 2010.04.10 MKIV there still is this 
 index/line-break bug!
 
 See example below please:
 
 \setuplayout [width=113mm,location=middle]
 \usetypescript[postscript]
 \definetypeface[postscript][rm][serif][times][default]
 \mainlanguage[de]
 \setupbodyfont[postscript,10pt] \setupinterlinespace[line=12pt]
 \setupalign[line,block]
 
 \starttext
 
 dieses ist dabei typisch für den Bereich der Architekten- oder 
 Ingenieurleistungen\index{Ingenieurleistungen}. Warum?
 
 \stoptext
   
 Can you test
 
 \unexpanded\def\forcecolorhack{\penalty\leaders\hrule\normalhskip\zeropoint}
 
 in your document.




It works! Marvellous ;o)


Steffen

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] index / line-break bug

[Steffen Wolfrum]

Hi,


in yesterday's beta (ConTeXt  ver: 2010.03.20 22:59 MKIV) there still is this 
index/line-break bug, see example below please:




\setuplayout[width=113mm,location=middle]
\usetypescript[postscript]
\definetypeface[postscript][rm][serif][times][default]
\mainlanguage[de]
\setupbodyfont[postscript,10pt] \setupinterlinespace[line=12pt]
\setupalign[line,block]

\starttext

dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen\index{Ingenieurleistungen}. Warum?

\stoptext






index_bug.pdf
Description: Adobe PDF document


Steffen___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] index / line-break bug

[Wolfgang Schuster]

Am 21.03.10 15:50, schrieb Steffen Wolfrum:

Hi,


in yesterday's beta (ConTeXt  ver: 2010.03.20 22:59 MKIV) there still is this 
index/line-break bug, see example below please:
   
\forcecolorhack insert a breakpoint in the text, what you can do is to 
move the index entry after the period.


\setuplayout[width=113mm]

\usetypescript[postscript]
\setupbodyfont[postscript,10pt]

\setupregisters[textcolor=red,pagecolor=blue]

\starttext

dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen\index{Ingenieurleistungen}. Warum?


dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen.\index{Leistung} Warum?


\let\forcecolorhack\relax

dieses ist dabei typisch für den Bereich der Architekten- oder 
Ingenieurleistungen\index{Ingenieur}. Warum?


\placeindex

\stoptext

Wolfgang

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] index / line-break bug

[Steffen Wolfrum]

Am 21.03.2010 um 17:17 schrieb Wolfgang Schuster:

 Am 21.03.10 15:50, schrieb Steffen Wolfrum:
 Hi,
 
 
 in yesterday's beta (ConTeXt  ver: 2010.03.20 22:59 MKIV) there still is 
 this index/line-break bug, see example below please:
   
 \forcecolorhack insert a breakpoint in the text, what you can do is to move 
 the index entry after the period.
 
 \setuplayout[width=113mm]
 
 \usetypescript[postscript]
 \setupbodyfont[postscript,10pt]
 
 \setupregisters[textcolor=red,pagecolor=blue]
 
 \starttext
 
 dieses ist dabei typisch für den Bereich der Architekten- oder 
 Ingenieurleistungen\index{Ingenieurleistungen}. Warum?
 
 dieses ist dabei typisch für den Bereich der Architekten- oder 
 Ingenieurleistungen.\index{Leistung} Warum?
 
 \let\forcecolorhack\relax
 
 dieses ist dabei typisch für den Bereich der Architekten- oder 
 Ingenieurleistungen\index{Ingenieur}. Warum?
 
 \placeindex
 
 \stoptext



Thank you Wolfgang. 
But we also need an automated long-term solution again, for avoiding this 
line-break in documents longer than this.


Steffen
___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] footnotes and naturalTABLES - Bug?

[Bernhard Rosensteiner]

Am 17.01.2010 um 22:46 schrieb Hans Hagen:

 On 17-1-2010 19:21, Bernhard Rosensteiner wrote:
 Hello all,
 
 when i place a footnote in a naturalTABLE the output at the bottom is always 
 multiplied by four per footnotemarker.
 In normal tables it works normal (see minimal example in attachment). Is 
 this a bug or make i something wrong?
 
 sort of a bug ... has to do with trialtypesetting runs (a mechanism that i 
 need to overhaul for mkiv)
 
 fixed in beta
 
 Hans
 
 
 -
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
 | www.pragma-pod.nl
 

Thanks for the quick fix!

best regards

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] footnotes and naturalTABLES - Bug?

[Bernhard Rosensteiner]

Hello all,

when i place a footnote in a naturalTABLE the output at the bottom is always 
multiplied by four per footnotemarker.
In normal tables it works normal (see minimal example in attachment). Is this a 
bug or make i something wrong?





footnotetest.tex
Description: Binary data


footnotetest.log
Description: Binary data



best regards
Bernhard



___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] footnotes and naturalTABLES - Bug?

[Hans Hagen]

On 17-1-2010 19:21, Bernhard Rosensteiner wrote:

Hello all,

when i place a footnote in a naturalTABLE the output at the bottom is always 
multiplied by four per footnotemarker.
In normal tables it works normal (see minimal example in attachment). Is this a 
bug or make i something wrong?


sort of a bug ... has to do with trialtypesetting runs (a mechanism that 
i need to overhaul for mkiv)


fixed in beta

Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

[NTG-context] mkII tabulate midline bug

[Thomas Floeren]

 
there seems to be a typo in the recent versions of tabl-tbl.mkii:

line 1225: \vskip1\topskip\allowbreak1\vskip-\topskip

(should probably read: \vskip1\topskip\allowbreak\vskip-\topskip)


example:

\starttabulate [|l|]
\NC text \NC\NR\FL
\NC midline ok \NC\NR\ML
\NC midline messed up \NC\NR\ML
\NC text \NC\NR\LL
\stoptabulate



ConTeXt  ver: 2010.01.05 16:47 MKII  fmt: 2010.1.7  int: english/english

best wishes
Thomas

___
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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] mkII tabulate midline bug

[Hans Hagen]

On 7-1-2010 9:45, Thomas Floeren wrote:



there seems to be a typo in the recent versions of tabl-tbl.mkii:

line 1225: \vskip1\topskip\allowbreak1\vskip-\topskip

(should probably read: \vskip1\topskip\allowbreak\vskip-\topskip)


  \vskip1\topskip\allowbreak\vskip-1\topskip


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : http://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] Small caps problem/bug with some fonts

[Hans Hagen]

Barry Schwartz wrote:


Are there fonts that have a or b in the numr and dnom features but
where they do not work in frac?


that is unrelated, the replacement rules refer to glyphs an doften they 
stick to digits so you get a/b with a large a and b and the fractional 
slash which then gives an ugly overlap


Hans


-
  Hans Hagen | PRAGMA ADE
  Ridderstraat 27 | 8061 GH Hasselt | The Netherlands
 tel: 038 477 53 69 | fax: 038 477 53 74 | www.pragma-ade.com
 | 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://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___

Re: [NTG-context] Small caps problem/bug with some fonts

[Barry Schwartz]

Hans Hagen pra...@wxs.nl skribis:
 so, its not that frac itself is the problem dealing with in the engine, 
 because if so, many features would be a problem, it's just that font 
 makers stick to a couple of simple rules like:
 
 (1) replace all
digits slash digits
  by
sup digits overlapping frac slash sub digits
 
 (1) replace all
digits slash digits
  by
sup digits overlapping frac slash sub digits
 
 and if they have rule 2, it will mess up things like a/b

Is rule (2) missing? I see (1) twice.

Are there fonts that have a or b in the numr and dnom features but
where they do not work in frac?

___
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://tex.aanhet.net
archive  : https://foundry.supelec.fr/projects/contextrev/
wiki : http://contextgarden.net
___