View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1025 [luatex] documentation tweak sometimes 2023-06-15 08:16 2023-06-15 08:16
Reporter: hilmar.preusse Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Some formatting fixes for the manual
Description: I'm just forwarding https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1037553 . The reated patch is here: https://github.com/debian-tex/texlive-bin/blob/master/debian/patches/syntax_error_luatex_man

Here are some remarks and a fix for some formatting issues in the man page of luatex(1).

Input file is luatex.1

#####

Output from "mandoc -T lint luatex.1"
mandoc: luatex.1:11:129: STYLE: input text line longer than 80 bytes: luatex, dviluatex, l...
mandoc: luatex.1:192:2: WARNING: line scope broken: TP breaks TP

#####

Change -- in x--y to \(em (em-dash), or, if an option, to \-\-

85:in comparison to the standard web2c programs. The presence of \fB--lua\fR

#####

Use the correct macro for the font change of a single argument or split the argument into two.

104:.BI \-\-luaconly

#####

Wrong distance between sentences.

Separate the sentences and subordinate clauses;
each begins on a new line.
See man-pages(7) and "info groff".

The best procedure is to always start a new sentence on a new line, at least, if you are typing on a computer.

Remember coding: Only one command ("sentence") on each (logical) line.

E-mail: Easier to quote exactly the relevant lines.

Generally: Easier to edit the sentence.

Patches: Less unaffected text.

The amount of space between sentences in the output can then be controlled with the ".ss" request.

47:next word is taken as the \fIFMT\fR to read, overriding all else. Any
83:similar fashion as in traditional pdf\*(TX and Aleph. But if the option
85:in comparison to the standard web2c programs. The presence of \fB--lua\fR
98:Start Lua\*(TX as a Lua interpreter. In this mode, it will set Lua's
101:just like the Lua interpreter. Lua\*(TX will exit immediately after
105:Start Lua\*(TX as a Lua byte compiler. In this mode, Lua\*(TX is exactly

#####

Split lines longer than 100 characters into two or more lines with '\'. Appropriate break points are the end of a sentence and a subordinate clause; after punctuation marks.

luatex.1: line 11 length 129
luatex, dviluatex, luahbtex, luajittex, texlua, texluac \- An extended version of TeX using Lua as an embedded scripting language

#####

Do not use "\s0" but an absolute number, as the size of the string could be changed.

8:.if t .ds WB W\s-2EB\s0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1024 [context] bug report minor always 2022-10-03 17:39 2022-10-03 17:39
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: missing space with French quotation
Description: Hi,

With the latest ConTeXt version, there is a missing space:

\mainlanguage[fr]
\setcharacterspacing[frenchpunctuation]
\starttext
bla \quotation{OK} bla\\
bla «OK» bla
\startquotation
  Here is a missing space
\stopquotation
\stoptext

How could I get back the space before "»" please?

TIA for any help,
--
           Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1022 [context] bug report minor always 2020-12-12 23:43 2020-12-12 23:43
Reporter: jemmybutton Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: textext within reusableMPgraphic causes an error if placed on the first page of a document
Description: With ConTeXt ver: 2020.03.10 14:44 MKIV beta fmt: 2020.7.20 the following happens:
Whenever I use \reuseMPgraphic with textext on the first page of the document, ConTeXt returns an error:

...

lua error > lua error on line 5 in file ***.tex:

/usr/share/texmf-dist/tex/context/base/mkiv/node-syn.lua:435: attempt to index a nil value (upvalue 'filehandle')

1 \starttext
2 \startreusableMPgraphic{abc}
3 draw textext("ABC");
4 \stopreusableMPgraphic
5 >> \reuseMPgraphic{abc}
6 \stoptext

mtx-context | fatal error: return code: 256

However, if it's not the first page, everything's fine
Tags:
Steps To Reproduce: \starttext
\startreusableMPgraphic{abc}
draw textext("ABC");
\stopreusableMPgraphic
\reuseMPgraphic{abc}
\stoptext

while

\starttext
\startreusableMPgraphic{abc}
draw textext("ABC");
\stopreusableMPgraphic
~\pagebreak
\reuseMPgraphic{abc}
\stoptext

works just fine
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1020 [context] bug report minor always 2020-06-08 14:16 2020-06-08 14:16
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: \setbreakpoints[compound] and numbers
Description: Hi,

How could I get breaking lines with numbers please?

Example:

\setbreakpoints[compound]
\setuplayout[width=1mm]
\starttext
xxx/xxx % line break is ok here
xx1/xxx % I would like a linebreak here too
\stoptext

TIA for any help,
--
           Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
426 [context] minor always 2010-07-16 14:42 2020-03-05 12:29
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: problem with \ref[t][...]
Description: Hello,

"\ref[t][...]" does not work as expected, or I expect the wrong thing:

\starttext
\startsection[title=Problem here, reference=sec1]
Section text: \ref[t][sec1]
\stopsection
\startsection[title=Workaround]
\reference[sec2]{Workaround}
Section text: \ref[t][sec2]
\stopsection
\stoptext

Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ewc.gz (29,209 bytes) 2020-03-05 11:38
https://tracker.luatex.org/file_download.php?file_id=295&type=bug
ml.gz (45,779 bytes) 2020-03-05 12:29
https://tracker.luatex.org/file_download.php?file_id=296&type=bug
Notes
(0001728)
marthasimons   
2020-03-05 11:38   
stoptext
(0001729)
marthasimons   
2020-03-05 12:29   
stopsection

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1019 [luatex] luatex bug minor always 2020-03-02 19:05 2020-03-02 19:05
Reporter: nagmat84 Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Wrong kerning in math mode between certain base symbols and subscript
Description: The kerning in math mode seems to be wrong for the libertinus package. The assumed bug has already been reported their, but the package author claim this to be a bug in LuaLaTex.

Also, see here: https://github.com/alif-type/libertinus/issues/301
Tags:
Steps To Reproduce: Compile this MWE with LuaLaTeX

    \documentclass{article}
    \usepackage{libertinus}
    \begin{document}
    \begin{equation}
    w_j q^j
    \end{equation}
    \end{document}

The space between the base symbol "w" and the subscript "j" is too much while there is too little space between the "j" and the following base symbol "q".
Additional Information:
Attached Files: hvsI2.png (1,098 bytes) 2020-03-02 19:05
https://tracker.luatex.org/file_download.php?file_id=294&type=bug
png
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1014 [context] bug report minor always 2019-11-12 12:12 2020-01-29 10:07
Reporter: flying sheep Platform:  
Assigned To: Hans Hagen OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: No way so silence “mkiv lua stats”
Description: context --silent=all or --silent='mkiv lua stats' have no effect on that log category

Apart from fixing this bug, the category should also be disabled by default: The default user won’t care

Also the --help docs aren’t very useful: “all” isn’t mentioned, and it isn’t explained what “list” means: Just comma-separated plain strings?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1006 [context] bug report minor always 2018-08-20 22:32 2020-01-29 10:07
Reporter: salzer Platform: mac  
Assigned To: Hans Hagen OS: macOS  
Priority: normal OS Version: 10.13.6  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: ffi ligature broken in DejaVu Serif
Description: The default behaviour of the dejavu fonts does not appear to ligature ffi as a single glyph, but as ff and i.

Have tried countless options of \feature to no avail.

I don't think this is just me, because in the document
<http://www.pragma-ade.nl/general/manuals/fonts-mkiv.pdf> on page 7, the text following figure 1.1 claims that ffi has no dot, when it does.
Tags:
Steps To Reproduce: Easy
------
\setupbodyfont[dejavu,1cm]
\starttext
office
\stoptext
------
The above produces office with an ff and i, and not an ffi
Additional Information: salzermbpr15:mkiv salzer$ context --version
mtx-context | ConTeXt Process Management 1.02
mtx-context |
mtx-context | main context file: /usr/local/texlive/2018/texmf-dist/tex/context/base/mkiv/context.mkiv
mtx-context | current version: 2018.04.04 00:51
salzermbpr15:mkiv salzer$ luatex --version
This is LuaTeX, Version 1.07.0 (TeX Live 2018)
Attached Files:
Notes
(0001704)
salzer   
2018-08-21 22:56   
I found this bug in the DejaVu font bug tracker (85574) but can't get an account to update there.
Nevertheless, I have a working solution that I will log here in the hope that somehow it gets communicated.

On my mac I open DejaVuSerif.sft with FontForge
From menu select Element > Font info
From side bar select Lookups
Select 'liga' Standard Ligatures - Without dotless i
click [UP] button to move it above 'liga' Standard Ligatures
Click [OK]
And compile the font.

copied the font to
/usr/local/texlive/2018/texmf-dist/fonts/truetype/public/dejavu
and now ffi ligatures work.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1017 [context] bug report major always 2020-01-29 01:00 2020-01-29 10:03
Reporter: Yehowshua Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Context used to be able to handle SVGs by invoking Inkscape
Description: The commands for svgs to PDFs in Inkscape have change.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001726)
Hans Hagen   
2020-01-29 10:03   
i need more into then:

- example
- what has changed

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1016 [context] bug report major always 2019-11-12 12:28 2019-11-12 17:15
Reporter: flying sheep Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Viewer layers are not being closed
Description: When I compile the following document, the “view” layer seems to gobble up the rest of the document: Hiding it makes “More text” vanish.

Apart from this bug, a question: Will [state=stop,printable=yes] add /Usage/Print and [state=start,printable=no] add /Usage/View to the OCG?
If not, what options to specify to make only one of the viewer layers display depending on media?

Bug exists in TeXlive 2019.52575. MRE:

\nopdfcompression
\defineviewerlayer[print][state=stop,printable=yes]
\defineviewerlayer[view][state=start,printable=no]

\def\viewcolor#1#2{%
    \startviewerlayer[view]\color[0000001]{0000002}\stopviewerlayer%
    \startviewerlayer[print]\llap{0000002}\stopviewerlayer%
}

\starttext
Hi!

\viewcolor{red}{This is only red on screen}.

More text.
\stoptext
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: viewer-layer-bug.pdf (10,478 bytes) 2019-11-12 17:15
https://tracker.luatex.org/file_download.php?file_id=292&type=bug
viewer-layer-bug.ctx (361 bytes) 2019-11-12 17:15
https://tracker.luatex.org/file_download.php?file_id=293&type=bug
Notes
(0001723)
flying sheep   
2019-11-12 12:31   
OK lol of course I didn’t intend to link bugs 1 and 2 above, but to refer to arguments 1 and 2 of \viewcolor.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1012 [context] bug report minor always 2019-09-07 05:44 2019-09-09 13:42
Reporter: emojifreak Platform:  
Assigned To: Hans Hagen OS:  
Priority: none OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect color of some emoji glyphs
Description: Some glyphs in TwemojiMozilla.ttf version 0.40 from https://github.com/mozilla/twemoji-colr/releases
are rendered in incorrect color. For example, the following file generates the attached PDF. The broken heart should appear in all red.

\definefontfeature
  [overlay]
  [default]
  [ccmp=yes,
   colr=yes,
   dist=yes]

\definefontsynonym
  [emoji]
  [file:TwemojiMozilla.ttf*overlay]

\starttext

\emoji{broken heart}

\stoptext

The context version is

mtx-context | ConTeXt Process Management 1.02
mtx-context |
mtx-context | main context file: /usr/local/texlive/2019/texmf-dist/tex/context/base/mkiv/context.mkiv
mtx-context | current version: 2019.03.21 21:39
Tags: emoji
Steps To Reproduce: Use context to the above file to generate a PDF file.
Additional Information:
Attached Files: twemoji-mozilla2.pdf (8,417 bytes) 2019-09-07 05:44
https://tracker.luatex.org/file_download.php?file_id=276&type=bug
Notes
(0001716)
Hans Hagen   
2019-09-09 13:42   
fixed in next beta but the font seems bad anyway (no proper boundingboxes so no height and depth known)

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1011 [MetaPost] limitation major always 2019-08-28 03:50 2019-08-28 09:26
Reporter: igor Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: resolved Product Version:  
Product Build: Resolution: no change required  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: MetaPost uses psfonts.map, which fails when embedding fonts when dvipsPreferOutline is false
Description: When "dvipsPreferOutline false" is used in updmap.cfg
and MetaPost is embedding the fonts (prologues:=3;), it looks
into psfonts.map, which makes it fail with this error:

    Warning: font cmr10 cannot be found in any fontmapfile!

$ cat /usr/local/share/texmf/web2c/updmap.cfg
dvipsPreferOutline false

$ ls -l /var/lib/texmf/fonts/map/dvips/updmap/psfonts.map
lrwxrwxrwx 1 root root 14 Aug 27 14:09 /var/lib/texmf/fonts/map/dvips/updmap/psfonts.map -> psfonts_pk.map

$ grep cm.map /usr/share/texlive/texmf-dist/web2c/updmap.cfg
MixedMap cm.map
Tags:
Steps To Reproduce: $ mpost -rec test
$ cat test.fls
INPUT /var/lib/texmf/fonts/map/dvips/updmap/psfonts.map
Additional Information: MetaPost normally uses pdftex.map. But sometimes it uses psfonts.map.
Attached Files: test.mp (97 bytes) 2019-08-28 03:50
https://tracker.luatex.org/file_download.php?file_id=275&type=bug
Notes
(0001715)
Taco   
2019-08-28 09:26   
Use the fontmapfile and fontmapline commands in metapost if your psfonts.map
  cannot be trusted to contain the lines you need.

See section 8.2 in the metapost manual.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1010 [context] bug report minor always 2019-07-22 17:10 2019-07-22 17:10
Reporter: itoijala Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: xtables stretch width
Description: Using the options stretch and width can result in a table that does not take up the full \textwidth.
This means that the content is shrunk further than necessary.

I think this is due to a bug in xtables.reflow_width.
I think the "width" in line 674 of tabl-xtb.lua should be widetotal instead, giving:

local factor = (widetotal + delta) / widetotal

This makes sense as the equation we want to solve is

widetotal + delta = factor * widetotal
Tags:
Steps To Reproduce: See the attached file.
This includes a copy of the patched function that can be activated by removing some comment markers.

It should be run as

context xtables-demo.tex --trackers=xtable.construct --debug
Additional Information:
Attached Files: xtables-demo.tex (6,818 bytes) 2019-07-22 17:10
https://tracker.luatex.org/file_download.php?file_id=273&type=bug
xtables-demo.pdf (9,042 bytes) 2019-07-22 17:10
https://tracker.luatex.org/file_download.php?file_id=274&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
835 [MetaPost] bug minor have not tried 2013-06-13 14:25 2017-05-19 08:38
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: bug in envelope of
Description: From Stephan Hennig:

Hi,

in this example

beginfig(2);
  path p, e;
  pen sqpen;
  sqpen := pensquare scaled 10;
  p := (-100,100){right}..origin..{right}(100,100);
  e := envelope sqpen of p;
  draw p withpen sqpen;
  draw e withcolor red;
endfig;
end

I'd expect the resulting picture to be symmetric. But it isn't.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001674)
luigi scarso   
2017-05-19 08:38   
Look ok in Metapost 2.000

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
948 [MetaPost] bug minor always 2015-10-13 22:47 2017-05-18 13:54
Reporter: linus Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: mfplain.mp defines a wrong round function
Description: The last mfplain.mp version that I could find (% $Id: mfplain.mp,v 1.9 2005/04/28 06:45:21 taco Exp $) defines:

vardef round primary u = u enddef;
vardef hround primary x = x enddef;
vardef vround primary y = y enddef;

But this should probably be (according to the METAFONTbook):

vardef round primary u =
 if numeric u: floor(u+.5)
 elseif pair u: (hround xpart u, vround ypart u)
 else: u fi enddef;
vardef hround primary x = floor(x+.5) enddef;
vardef vround primary y = floor(y.o_+.5)_o_ enddef;



Tags:
Steps To Reproduce: mpost '&mfplain \mode:=localfont; input font'

where font.mf contains the following line:

message decimal(round(4.2));

This will output 4.2 instead of 4
Additional Information: Taco Hoekwater had probably his reasons to do so. Probably one should ask him before changing mfplain.mp.
Attached Files:
Notes
(0001422)
luigi scarso   
2015-10-15 08:59   
Thank you very much. I will see asap.
(0001673)
luigi scarso   
2017-05-18 13:54   
Taco says
"""
there is no rounding in mp because it is not needed
mf rounds because of the bitmap grid
at least that was JDH's take on it
"""
I will leave unmodified these functions, perhaps I cann add MFround etc.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
854 [MetaPost] bug minor have not tried 2013-09-20 16:39 2017-03-17 14:58
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Strange behavior of turningnumber
Description: From Pichaureau:


Hi (again),

I've to say that I'm very impressed by the progress on metapost. The new numbersystem feature is a big improvement !

Anyway, in mpost 1.802, I've find this strange behavior of turningnumber:

  z1 = (50,50);
  z2 = (100,50);
  z3= (100,100);
  z4 = (50,100);

  path p,q;
  p = (z1---z2..z3---z4--cycle); % p counterclockwise

  q = (reverse p);

  show (turningnumber p);
  show (turningnumber q);

 end.

The turningnumber of p is 1, but the turningnumber of q is 0
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001671)
luigi scarso   
2017-03-17 14:58   
We can use a modified version of straighten_path, from plain_ex.mp
(mt1 package):


if unknown mpversion:
 def beginfig(expr n) = enddef;
 def endfig = enddef;
 def draw text t = enddef;
 def fill text t = enddef;
else: autorounding:=0; % good to remember
fi


vardef straighten_path(expr r) =
 save L,l,M;
 M:=4092/(length r);
 L:=M*length r;
 l:=(length r)/L;
 for k=0 upto L - 1: point (k*l) of r -- endfor
if cycle r: cycle else: point infinity of r fi enddef;



z1 = (50,50);
  z2 = (100,50);
  z3= (100,100);
  z4 = (50,100);

  path p,q;
  p = (z1---z2..z3---z4--cycle); % p counterclockwise

  q = (reverse p);

  show (turningnumber p);
  show (turningnumber q);

  show (turningnumber straighten_path(p));
  show (turningnumber straighten_path(q));

 end.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
976 [MetaPost] bug major always 2016-05-30 10:21 2016-11-22 14:35
Reporter: luigi scarso Platform:  
Assigned To: luigi scarso OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.999  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Weird MetaPost output when using PNG
Description: PNG output looks wrong, EPS output is correct, SVG is correct.

Tags:
Steps To Reproduce: outputformat := "png";
outputtemplate := "%j-%c.%o";

beginfig(1);
    h=100;
    w=100;
    y1=y2=y3=0;
    y4=y5=y6=h;
    x1=x4=0;
    x2=x5=w;
    x3=x6=2*w;
    pickup pencircle xscaled 0.2w yscaled 0.04w rotated 45;
    draw z1..z3..z6{z2-z6}..z5..{z4-z2}z4..cycle;
endfig;
end.
Additional Information: See
"Weird MetaPost output when using PNG"
http://tex.stackexchange.com/questions/312133/weird-metapost-output-when-using-png
Attached Files:
Notes
(0001655)
luigi scarso   
2016-11-22 14:35   
Fixed in r2101.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
990 [context] bug report major always 2016-10-19 10:32 2016-10-19 10:32
Reporter: FloMiLe Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Bug in m-educat.mkiv
Description: One cannot compile the example code inside the module context/tex/texmf-context/tex/context/modules/mkiv/m-educat.mkiv.

The error is "Missing number, treated as zero" when "\startanswerlines [n=3]" is called.
Tags:
Steps To Reproduce:
Additional Information: Is it possible that the source code of the module on line 112 should read "\c!m=0000001" instead of "\c!m=,0000001", e.g. the comma should not be there?

I have tried to fix it locally by deleting the comma, saving the file, and running "context --generate". But this did not help.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
960 [MetaPost] bug minor have not tried 2015-12-14 12:53 2015-12-15 11:18
Reporter: luigi scarso Platform:  
Assigned To: luigi scarso OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.999  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.999  
Summary: metapost tfm bug with mfplain
Description: In MetaPost mailing list, Mon, Aug 17, 2015 at 1:27
from Karel Horak <horakk@math.cas.cz>

"""
Recently I have found some bug when using metapost with old mf files: in one case I have get incorrect tfm metrics when compiling with mpost -mem=mfplain option.
To make things easier, I changed all the graphics into trivial rectangles, the incorrect dimensions are still there in case of chars 44 and 45 (octal 36 and 37). The height of these two characters is much smaller than their width but should be higher!
I am adding the source file uceb.mf, the resulting uceb.tfm and the corresponding u.pl
(resulting from tftopl uceb u).
I used the latest binaries for win64 (metapost 1.999).
Thanks for investigation!
Karel Horak
"""
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: metapostmetaposttfmbugwithmfplain.zip (1,726 bytes) 2015-12-14 12:53
https://tracker.luatex.org/file_download.php?file_id=249&type=bug
Notes
(0001564)
luigi scarso   
2015-12-15 11:18   
It should be already fixed in rev. 2073.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
918 [MetaPost] General tweak always 2014-11-05 00:31 2015-10-22 11:04
Reporter: Graham Douglas Platform: Windows  
Assigned To: luigi scarso OS: Windows 7  
Priority: normal OS Version: 64-bit Ultimate  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: [MPlib 1.801 and others?] mp_gr_copy_object(MP mp, mp_graphic_object*p) not copying all object properties?
Description: When using mp_gr_copy_object(MP mp, mp_graphic_object*p) to create a way to cache graphics produced by MPlib I noticed that the "deep copy" process does not appear to copy a number of object properties. mp_gr_copy_object(MP mp, mp_graphic_object*p) is located in psout.w/psout.c.

I made the adjustments noted in "Additional Information" in order to force copying object properties such as the line join, miterlimit, linecap and colour properties into the new object being copied.
Tags:
Steps To Reproduce:
Additional Information: Apologies I don't use diff so I hope the simple commenting in the code below
(copied from mp_gr_copy_object(MP mp, mp_graphic_object*p)) will be enough to describe the issue and the fix that worked for me.

mp_graphic_object* mp_gr_copy_object(MP mp,mp_graphic_object*p)
{

.....

switch(gr_type(p)){
case mp_fill_code:
tf= (mp_fill_object*)mp_new_graphic_object(mp,mp_fill_code);
gr_pre_script(tf)= mp_xstrdup(mp,gr_pre_script((mp_fill_object*)p));
gr_post_script(tf)= mp_xstrdup(mp,gr_post_script((mp_fill_object*)p));
gr_path_p(tf)= mp_gr_copy_path(mp,gr_path_p((mp_fill_object*)p));
gr_htap_p(tf)= mp_gr_copy_path(mp,gr_htap_p(p));
gr_pen_p(tf)= mp_gr_copy_path(mp,gr_pen_p((mp_fill_object*)p));


//=============================================
//GMD Graham fixes --------------------------------->
tf->ljoin = ((mp_fill_object*)p)->ljoin;
tf->miterlim = ((mp_fill_object*)p)->miterlim;
tf->color_model = ((mp_fill_object*)p)->color_model;
tf->color.a_val = ((mp_fill_object*)p)->color.a_val;
tf->color.b_val = ((mp_fill_object*)p)->color.b_val;
tf->color.c_val = ((mp_fill_object*)p)->color.c_val;
tf->color.d_val = ((mp_fill_object*)p)->color.d_val;
//<-----------------------------------------------------------------
//=============================================


q= (mp_graphic_object*)tf;
break;
case mp_stroked_code:
ts= (mp_stroked_object*)mp_new_graphic_object(mp,mp_stroked_code);
gr_pre_script(ts)= mp_xstrdup(mp,gr_pre_script((mp_stroked_object*)p));
gr_post_script(ts)= mp_xstrdup(mp,gr_post_script((mp_stroked_object*)p));
gr_path_p(ts)= mp_gr_copy_path(mp,gr_path_p((mp_stroked_object*)p));
gr_pen_p(ts)= mp_gr_copy_path(mp,gr_pen_p((mp_stroked_object*)p));
gr_dash_p(ts)= mp_gr_copy_dashes(mp,gr_dash_p(p));

//=============================================
//GMD Graham fixes --------------------------------->
ts->ljoin = ((mp_stroked_object*)p)->ljoin;
ts->color_model = ((mp_stroked_object*)p)->color_model;
ts->miterlim = ((mp_stroked_object*)p)->miterlim;
ts->lcap = ((mp_stroked_object*)p)->lcap;
ts->color_model = ((mp_stroked_object*)p)->color_model;
ts->color.a_val = ((mp_stroked_object*)p)->color.a_val;
ts->color.b_val = ((mp_stroked_object*)p)->color.b_val;
ts->color.c_val = ((mp_stroked_object*)p)->color.c_val;
ts->color.d_val = ((mp_stroked_object*)p)->color.d_val;
//<-----------------------------------------------------------------
//=============================================


q= (mp_graphic_object*)ts;
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
945 [MetaPost] bug minor always 2015-08-16 17:30 2015-10-06 12:39
Reporter: toby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: New number systems: "uniformdeviate 4096" produces integers instead of reals
Description: Using mpost recently compiled from trunk, I get odd results from "uniformdeviate"

- "uniformdeviate 1" produces numbers that are all multiples of 1/4096.
- "uniformdeviate 1024" produces multiples of 1/4
- "uniformdeviate 4096" produces integers
- "uniformdeviate 8092" produces even integers

and so on

I guess that this is another artefact from the conversion from the scaled routines. Maybe we need a new uniform random number generator for each of the new number systems?
Tags:
Steps To Reproduce: show numbersystem;
warningcheck := 0;
for i=1 upto 4:
  x := uniformdeviate 4096;
  show x;
endfor
Additional Information: Here's some sample output from the above, with each of the number systems

This is MetaPost, version 1.999 (TeX Live 2015) (kpathsea version 6.2.1)
(/usr/local/texlive/2014/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2014/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./numbers.mp
>> "scaled"
>> 3197.13828
>> 2188.96832
>> 3010.09789
>> 3947.62305 )
Transcript written on numbers.log.
This is MetaPost, version 1.999 (TeX Live 2015) (kpathsea version 6.2.1)
(/usr/local/texlive/2014/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2014/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./numbers.mp
>> "double"
>> 917
>> 67
>> 1353
>> 814 )
Transcript written on numbers.log.
This is MetaPost, version 1.999 (TeX Live 2015) (kpathsea version 6.2.1)
(/usr/local/texlive/2014/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2014/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./numbers.mp
>> "binary"
>> 2678
>> 3060
>> 367
>> 2208 )
Transcript written on numbers.log.
This is MetaPost, version 1.999 (TeX Live 2015) (kpathsea version 6.2.1)
(/usr/local/texlive/2014/texmf-dist/metapost/base/mpost.mp
(/usr/local/texlive/2014/texmf-dist/metapost/base/plain.mp
Preloading the plain mem file, version 1.005) ) (./numbers.mp
>> "decimal"
>> 2270
>> 3804
>> 735
>> 1264 )
Transcript written on numbers.log.
Attached Files:
Notes
(0001397)
toby   
2015-08-17 16:57   
Looking at the source, code I see that we are still using the base random number generator which does indeed generate "fractions", which is why they come out as 1/4096s I guess.

Is it too much work to override the whole mechanism? TAOCP 3.6 gives a suitable high-level language routine (albeit in Fortran).
(0001403)
luigi scarso   
2015-09-14 18:20   
Thank you for the report. I will look at it asap.
(0001405)
luigi scarso   
2015-09-14 21:43   
take_fraction is specialized for each numbersystem, so it should be ok.
(0001406)
toby   
2015-09-14 23:59   
yes but you are using 1/4096 as the resolution in the random number generator instead of 2^-28 as in the original because of the way you have implemented take_fraction for decimal. So the random numbers are not very random. Perhaps it would be better to re-write the random number generator *without* fractions? (But I can see that this would make a bunch more work elsewhere).
(0001407)
luigi scarso   
2015-09-16 00:40   
I think that I have to make a mp_unif_rand specific for each numbersystem.
(0001408)
luigi scarso   
2015-09-18 10:29   
http://www-cs-faculty.stanford.edu/~uno/programs/rng.c could be a good choice.
(0001410)
luigi scarso   
2015-09-22 11:50   
I have adapted rng.c for binary, decimal and double (trivial modifications).
Now the uniform random generator has a modulo of 2^30 and a period of (2^30)^2-1=2^60-1. I will commit soon.
(0001411)
luigi scarso   
2015-09-23 12:40   
Revision 2069 still has the old generator.
(0001413)
luigi scarso   
2015-10-06 12:39   
Rev. 2070 has new generator.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
943 [MetaPost] feature request tweak always 2015-07-27 20:24 2015-08-04 18:02
Reporter: toby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: in plain.mp, eps and infinity constants could be better defined for new number systems
Description: Currently plain.mp has these three definitions...

eps := .00049; % this is a pretty small positive number
epsilon := 1/256/256; % but this is the smallest
infinity := 4095.99998; % and this is the largest

it would be nice if the decimal constants could be replaced by expressions that could be evaluated at full precision by the new number systems. Like this:

eps := 1/2048; % this is a pretty small positive number
epsilon := 1/256/256; % but this is the smallest
infinity := 64*64-epsilon; % and this is the largest

This would make no difference when using the default scaled numbers, but would make the constants more consistent when using higher precision number systems.

In particular it would make "infinity+epsilon=4096" true which ever number system is used.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001393)
toby   
2015-08-04 17:16   
While we are about it, it would also be nice to replace the units of measure definitions with equivalent relations that are more accurate with the higher precision numeric engines. For example replace the existing lines in "plain.mp"

mm=2.83464; pt=0.99626; dd=1.06601; bp:=1;
cm=28.34645; pc=11.95517; cc=12.79213; in:=72;

with these equivalent lines, which give full precision regardless of engine

72 = 1 in; 800 = 803 pt; 360 = 127 mm; 3600 = 127 cm;
1 pc = 12 pt; 1 cc = 12 dd; 1157 dd = 1238 pt; bp = 1;
(0001394)
luigi scarso   
2015-08-04 18:02   
Hm, I tend to consider plain.mp kind of frozen --- I think it could be still in use for TAOCP, for example. Better to think to a newplain.mp instead, or something similar.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
942 [MetaPost] bug minor always 2015-07-27 01:03 2015-08-03 09:28
Reporter: toby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Simple numeric comparison fails with "binary" and "decimal" numersystems
Description: Consider this program:

    show 0.0001 < 0.001, numbersystem, mpversion; end.

With the default number system this gives

>> true
>> "scaled"
>> "1.999" )

on my log. But with the other number systems I get:

>> true
>> "double"
>> "1.999" )

>> false
>> "binary"
>> "1.999" )

>> false
>> "decimal"
>> "1.999" )

which is a bit unexpected...

I'm using a version I compiled myself from source after you fixed the normaldeviate bug a couple of months ago.
Tags:
Steps To Reproduce: Run

 show 0.0001 < 0.001, numbersystem, mpversion; end.

with the 4 different number systems.
Additional Information:
Attached Files:
Notes
(0001389)
toby   
2015-07-27 19:57   
Testing with V1.902 (the only other version I have on hand, I only get the error with "decimal". But it does not appear to matter what numbers I use (ie same bug with 1<2, or 1/4<1/2, etc

This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
>> true
>> "scaled" )
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
>> true
>> "double" )
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
>> true
>> "binary" )
This is MetaPost, version 1.902 (TeX Live 2014) (kpathsea version 6.2.0)
>> false
>> "decimal" )
(0001390)
luigi scarso   
2015-07-30 10:53   
It should be fixed in trunk.
(0001391)
toby   
2015-08-02 22:51   
Thanks - looks good from here. Can you share any details about where the bug was?
(0001392)
luigi scarso   
2015-08-03 09:28   
IIRC, it should be a patch from Akira. See
"better patch for to_boolean for decimal and binary number system (A. Kakuto)"
in the svn repo.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
935 [MetaPost] bug minor always 2015-05-06 00:34 2015-05-14 09:05
Reporter: toby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: pathpart of glyph adds jaggies to path
Description: If I fetch a glyph from certain fonts - cmti12 for example - I can draw the resulting picture, and the output is as expected.

But if I extract the path from the picture returned by "glyph", there is an odd jaggie added in certain places. In particular this is noticeable on the dished-serifs found in many of the CM fonts.

The attached program shows the issue at the top and base of the "I" character. The path extracted with "pathpart" is overlaid on top of the drawn picture.

Apparently "pathpart" copies some form of font hinting or special construction for the dishing as if it was just part of the outline.
Tags:
Steps To Reproduce: prologues := 3;
outputtemplate := "glyph%c.eps";
beginfig(1);
  picture a;
  a = glyph "I" of "cmti12";
  draw a withcolor .9 white;
  draw pathpart a withcolor red;
endfig;
end.
Additional Information: Speaking personally, I don't think this is very important - perhaps the only fix needed is a suitable warning in the documentation about "glyph"?

The issue was discussed a while ago on TeX.SE
http://tex.stackexchange.com/questions/151801/is-this-a-bug-in-the-pfb-file-or-a-bug-in-metaposts-glyph
Attached Files:
Notes
(0001362)
luigi scarso   
2015-05-06 19:02   
Thank you for the report. I will investigate.
(0001363)
luigi scarso   
2015-05-08 20:43   
Could be that Flex are not ignored as they should. In
/q {
        108 450 hsbw
        -194 29 hstem
        -10 20 hstem
        421 20 hstem
        0 62 vstem
        376 417 rmoveto
        1 4 1 6 0 4 rrcurveto
        5 -4 4 -5 vhcurveto
        -8 0 -37 -34 -16 -31 rrcurveto
        -11 29 -24 37 -49 0 rrcurveto
        -109 -115 -153 -146 hvcurveto
        -89 47 -63 68 vhcurveto
        36 0 36 20 34 35 rrcurveto
        1 -1 rlineto
        -13 -49 -10 -42 -15 -61 rrcurveto
        -14 -54 0 -2 -64 -1 rrcurveto
        -13 -9 0 -19 hvcurveto
        -10 10 0 4 vhcurveto
        1 callsubr
        95 0 rmoveto
        2 callsubr
        -65 0 rmoveto
        2 callsubr
        34 2 rmoveto
        2 callsubr
        31 0 rmoveto
        2 callsubr
        32 0 rmoveto
        2 callsubr
        34 -2 rmoveto
        2 callsubr
        31 0 rmoveto
        2 callsubr
        50 398 -194 0 callsubr
        6 12 0 18 hvcurveto
        11 -6 0 -18 vhcurveto
        -22 -26 0 15 hvcurveto
        0 6 0 2 2 9 rrcurveto
        closepath
        4 256 rmoveto
        15 callsubr
        endchar
        } ND
1 callsubr until 50 398 -194 0 callsubr is an horizontal hint, and it's effect should be ignored.
(0001374)
luigi scarso   
2015-05-14 09:05   
It should be fixed on trunk.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
927 [MetaPost] bug minor always 2015-03-05 20:46 2015-03-20 02:19
Reporter: toby Platform: Intel  
Assigned To: OS: OSX  
Priority: normal OS Version: 10.9.2  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: normaldeviate is not ~ N(0,1) with new number systems
Description: Using the new number systems "decimal" or "double", I get unexpected results from `normaldeviate`.
The expected behaviour is described on p.183 of the Metafont book. The random numbers returned are supposed to be distributed ~ N(0,1), ie "the so-called normal distributon with mean zero and variance one."

The sample programme in the next box calculates the mean and variance for a sample of 1000 `normaldeviate` numbers. With the "old" number system you get the expected behaviour (mean about 0 and variance about 1). With either of the new number systems you get wildly extravagant variance.

I'm using MP version 1.902
Tags:
Steps To Reproduce: sum := 0;
sumsq := 0;
n := 1000;
for i=1 upto n:
  r := normaldeviate;
  sum := sum + r;
  sumsq := sumsq + r**2;
  endfor
mu = sum/n;
var = sumsq/n - mu**2;
show mu, var;
show mpversion;
end.
Additional Information: With "mpost":
>> 0.06042
>> 1.00555
>> "1.902" )

with "mpost -numbersystem=double"
>> -0.65570211372579323
>> 765.47814649151951
>> "1.902" )

with "mpost -numbersystem=decimal"
>> 0.5380032282704515183638352250419854
>> 213.6313527928249793656705740805164
>> "1.902" )
Attached Files:
Notes
(0001320)
toby   
2015-03-05 21:36   
Looking at mp.w I see that the algorithm to generate normal deviates uses two constants.

These are defined in mpmath.w:mp_initialize_scaled_math as

  mp_new_number (mp, &math->sqrt_8_e_k, mp_scaled_type);
  math->sqrt_8_e_k.data.val = 112429; /* $2^{16}\sqrt{8/e}\approx 112428.82793$ */
  mp_new_number (mp, &math->twelve_ln_2_k, mp_fraction_type);
  math->twelve_ln_2_k.data.val = 139548960; /* $2^{24}\cdot12\ln2\approx139548959.6165$ */

but in mpmathdouble.w:mp_initialize_double_math we have

  mp_new_number (mp, &math->sqrt_8_e_k, mp_scaled_type);
  math->sqrt_8_e_k.data.dval = 112429 / 65536.0; /* $2^{16}\sqrt{8/e}\approx 112428.82793$ */
  mp_new_number (mp, &math->twelve_ln_2_k, mp_fraction_type);
  math->twelve_ln_2_k.data.dval = 139548960 / 65536.0; /* $2^{24}\cdot12\ln2\approx13954895...

but the second one is a *fraction* not a *scaled* number, so simply dividing by 2^16 gives the wrong value and hence the `normaldeviate` algorithm is all messed up.

Scanning down the rest of this initialization function it appears that you have assumed *all* the fractions were |scaled| numbers - I guess that this is likely to be the source of many bugs with the new number systems.
(0001323)
luigi scarso   
2015-03-09 11:01   
Thank you for the report. I cannot guarantee that I will able to fix for the next TL.
(0001324)
toby   
2015-03-10 17:47   
If I've understood the code correctly the particular constant "twelve_ln_2_k" is required because we've passed a |fraction| to m_log but it expects a |scaled|. Therefore it computes mlog(4096u) = mlog(4096)+mlog(u) = 12 mlog(2) + mlog(u). We have then to subtract this from "twelve_ln_2" to get -mlog(u).

Since -mlog(u) is -256 log(u) then the ab_vs_cd line is using 1024*-256 log(u) = -2^{18} log u which is (I think!) -4 log u as a scaled number (which is what we want).

So (I think) the "twelve_ln_2_k" constant needs to be whatever 12 mlog(2) is with the new number systems.

However it might be a better idea to simply rewrite the "norm_rand" routine for doubles and decimals so that they avoid all these complicated scaled vs fraction manoeuvres. Does the structure of the code allow you to do that?

The Ratio Method Knuth is using is pretty simple without the complexities of scaled arithmetic. [Although I note that there was a mis-print in the old edition of Seminumerical Algorithms that I have - it has -4/log(u) instead of -4*log(u). This was corrected in the third edition]
(0001325)
luigi scarso   
2015-03-10 17:57   
R4[Final test.] at 3.4.1 has -4ln(U) in my third Edition --- do you mean this one ?
(0001326)
toby   
2015-03-10 22:19   
Yes, the third edition is correct - it should indeed be -4 ln(U) - some simple algebra shows this.
Equation (24) has v <= 2u \sqrt{ ln (1/u) }

so v^2 <= 4u^2 ln (1/u)

and v^2/u^2 <= 4 ln (1/u) (since u^2 must be > 0)

hence X^2 <= -4 ln(U)
(0001327)
toby   
2015-03-11 00:18   
Here's a user land version (which is reasonably quick...)

% Ratio method normal deviates, following TAOCP 3.4.1 Algorithm R, except that
% the inner loop ensures u is not too small, so that xa does not overflow.
vardef rm_normaldeviate =
    save u, v, xa;
    forever:
        forever:
            u := uniformdeviate 1;
            exitif (u>1/64);
        endfor
        v := sqrt(8/mexp(256)) * ( -1/2 + uniformdeviate 1 );
        xa := v/u;
        exitif ( xa**2 <= -mlog(u)/64 );
    endfor
    xa
enddef;
(0001341)
luigi scarso   
2015-03-18 14:20   
The problem is the function ab_vs_cd. In the double number system it uses a cast down to int, and this introduces mistakes. The best solution is to split as in the case of the function exp.
(0001342)
luigi scarso   
2015-03-20 02:19   
Fixed in beta-0.80.0

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
922 [MetaPost] limitation minor always 2015-01-07 16:53 2015-01-07 21:55
Reporter: Hans Hagen Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: internals and loops
Description: in non-scaled mode the internals are still limited in size (hardcoded) ... this is probably not a simple change (values are stored differently)

the same is true for loops

there is no urge in fixing this but it would fit into 'being big'
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0001306)
Hans Hagen   
2015-01-07 21:55   
after checking this is only an issue when internals are passed on the commandline

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
915 [MetaPost] bug minor always 2014-09-01 18:03 2014-11-07 15:12
Reporter: toby Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.890  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: odd primitive fails with negative numbers
Description: "odd" appears to return false for all negative numbers
Tags:
Steps To Reproduce: Run this program

for i=3 step -2 until -10:
  show(i); show(odd i); show((i mod 2)=1);
endfor
end.
Additional Information: Note the above program also shows a work around, and if you run the above through *Metafont* there's no bug.
Attached Files:
Notes
(0001302)
luigi scarso   
2014-11-07 15:12   
It's fixed in rev. 1.999 .

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
784 [MetaPost] limitation minor have not tried 2012-11-29 15:10 2014-03-11 13:26
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: embedded library does not like empty lines
Description: Something as simple as this:

beginfig(1);\r\n\r\n; endfig;

generates a "Please type a command or say end" message
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000995)
Taco   
2012-12-07 16:52   
fixed, by having mp_execute() change \n's to spaces before processing continues. Should be cleaned up at a later time.
(0000996)
Taco   
2012-12-07 16:58   
Silly, that wont work of course (embedded comments).

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
214 [MetaPost] feature request minor have not tried 2009-04-17 14:04 2014-03-11 13:25
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 2.000  
Summary: Allow access to path envelopes
Description: Allow access to the envelopes of a path after it has been traced
with a pen (I need Giuseppe's help for the elliptical pens).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
884 [context] bug report minor always 2014-02-07 23:15 2014-02-07 23:15
Reporter: Jan Tosovsky Platform: Windows  
Assigned To: OS: Windows 7  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Hanging alignment is ignored when enabled indentation in narrower text
Description: When the following example is used in current beta (2014.02.07), those quotes which are part of narrower block are aligned as expected. When indenting is uncommented, 'hanging' alignment (visible at the left edge) is ignored.

\definefontfamily[palatino][rm][Palatino Linotype][features={default, quality}]
\setupbodyfont[palatino]
\setupalign[hz, hanging]
%\setupindenting[medium, yes]

\starttext
\input{tufte}
\setupnarrower[left=1cm]
\startnarrower[left]
\it
»this is,\par
just sample.«\par
\stopnarrower
\input{tufte}
\stoptext

Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
881 [MetaPost] bug tweak always 2014-01-24 13:05 2014-01-24 13:05
Reporter: piotrst Platform: PC  
Assigned To: OS: Linux and Windows  
Priority: normal OS Version:  
Status: new Product Version: 1.780  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Incorrect MPOST output in degenerated closed path case
Description: Closed degenerated MPOST path:

beginfig(1)
 draw (0,0)--(0,0) & cycle withpen pencircle scaled 1;
endfig;
bye.

yields a strange and `too simple' result:

%!PS
%%BoundingBox: -1 -1 1 1
%% ...
0 0 0 setrgbcolor 0 1 dtransform truncate idtransform setlinewidth
pop [] 0 setdash 1 setlinejoin 10 setmiterlimit
newpath 0 0 moveto
closepath stroke
showpage

which is incorrectly displayed in both Ghostscript and Adobe Reader.
Tags:
Steps To Reproduce: Second, let's consider another degenerated case, not covered
by Hans's amendment:

  beginfig(1)
   draw (0,0)--(0,0) withpen pencircle scaled 1;
  endfig;
  bye.

The output PostScript code reads (most of comments skipped):

  %!PS
  %%BoundingBox: -1 -1 1 1
  %% ...
  0 0 0 setrgbcolor 0 1 dtransform truncate idtransform setlinewidth
  pop [] 0 setdash 1 setlinecap 1 setlinejoin 10 setmiterlimit
  newpath 0 0 moveto
  0 0 lineto stroke
  showpage

Ghostscript happily displays the correct, i.e., expected result (Adobe Reader also, after the distillation, of course).

A slight modification of the degenerated case:

  beginfig(1)
   draw (0,0)--(0,0) & cycle withpen pencircle scaled 1;
  endfig;
  bye.

yields a slightly modified result:

  %!PS
  %%BoundingBox: -1 -1 1 1
  %% ...
  0 0 0 setrgbcolor 0 1 dtransform truncate idtransform setlinewidth
  pop [] 0 setdash 1 setlinejoin 10 setmiterlimit
  newpath 0 0 moveto
  closepath stroke
  showpage

Now, Gostscript displays nothing, and the respective PDF file
does not contain a visible object according to Adobe Reader.

The culprit is, somewhat surprisingly, the phrase "1 setlinecap",
missing from the PostScript code in the latter case. (Observe
that "1 setlinejoin" does not help.)
 
Additional Information:
So, we would advise that the phrase "1 setlinecap" should be
issued in degenerated cases (at least), to avoid admittedly
rare but surprising results.

Perhaps advisable would be replacing the phrase "0 0 moveto" by "0 0 moveto 0 0 rlineto", but we're not sure.
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
781 [MetaPost] limitation minor have not tried 2012-11-16 13:14 2012-11-16 13:14
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: begingroup -- endgroup nesting in library
Description: The current versions of mplib all require the argument to mp_execute() to have proper begingroup ... endgroup nesting. It would be nice if that restriction could be removed in some future version.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
712 [minimals] Configuration, tree structure, texmf.cnf trivial always 2011-08-28 15:28 2011-08-28 15:28
Reporter: mojca Platform:  
Assigned To: mojca OS:  
Priority: high OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: TeXworks configuration
Description: texworks-setup.ini

should probably be

defaultbinpaths=./
inipath=./../../texmf-context/context/data/texworks
libpath=./../../texmf-context/context/data/texworks

or something similar and path to binaries is missing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
708 [minimals] Fonts minor have not tried 2011-08-17 09:46 2011-08-17 09:46
Reporter: mojca Platform:  
Assigned To: mojca OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: add punknova
Description: https://github.com/khaledhosny/punk-otf
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
700 [minimals] Installation/update script minor always 2011-07-06 21:13 2011-07-06 21:13
Reporter: mojca Platform:  
Assigned To: Hans Hagen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Support --modules=all --fonts=all
Description: mtx-update.lua doesn't favour --modules=all and --fonts=all request
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
657 [MetaPost] feature request minor have not tried 2011-05-16 09:54 2011-05-16 09:54
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Area calculation primitive
Description: Also requested by Boguslaw Jackowski. See attached PDF
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: AREA1.pdf (50,885 bytes) 2011-05-16 09:54
https://tracker.luatex.org/file_download.php?file_id=132&type=bug
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
618 [MetaPost] feature request minor have not tried 2011-04-30 17:06 2011-05-16 09:53
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: windingangle/windingnumber <path> primitive
Description: Requested by Boguslaw Jackowski
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: WIND0.pdf (66,606 bytes) 2011-05-16 09:53
https://tracker.luatex.org/file_download.php?file_id=131&type=bug
Notes
(0000855)
Taco   
2011-05-16 09:53   
Attached PDF from Boguslaw

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
499 [context] feature request feature N/A 2010-10-14 16:11 2010-10-14 16:11
Reporter: steffen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: structuresectionstarterset
Description: As definestructureconversionset is such a convenient command, could we also have the accompanying structuresectionstarterset and structuresectionstopperset?


\definestructureconversionset [default] [ ,Characters,Romannumerals,Numbers,characters,charcharacters] [numbers]
\definestructuresectionstarterset [default] [ , , , , ,{(}] [{.}]
\definestructuresectionstopperset [default] [ ,{.},{.},{)},{)},{)}] [{.}]
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
430 [context] feature always 2010-07-16 14:54 2010-10-03 07:58
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: feature request: minwidth in description
Description: Hello,

It would be nice, to have a minimum width for the description label.

I hope, the following example shows well enough, what I'm looking for:

\definedescription[Descr][headstyle=bold, location=hanging, width=broad,
  minwidth=7em, distance=1em]
\starttext
\startDescr{\hbox to 7em{bla}} % workaround to get minwidth=7em
  \input tufte
\stopDescr
\startDescr{\hbox to 7em{bla bla bla\hss}} % workaround to get minwidth=7em
  \input tufte
\stopDescr
\startDescr{bla bla bla bla bla bla}
  \input tufte
\stopDescr
\stoptext

Cheers, Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
490 [context] bug report minor always 2010-10-02 12:00 2010-10-02 12:00
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: width of column-span not adjusted in TABLE
Description: Hello,
The width of a column-span is not adjusted:

\starttext
\bTABLE
\bTR \bTD A \eTD \bTD A \eTD \eTR
\bTR \bTD[nc=2] \framed[width=3cm]{not ok} \eTD \eTR
\bTR \bTD[nr=2] \framed[height=3cm]{ok} \eTD \bTD A \eTD \eTR
\bTR \bTD A \eTD \eTR
\eTABLE
\stoptext

No problem with the height of a row-span.

(reported by Patrick on the list)

Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
427 [context] minor always 2010-07-16 14:49 2010-08-02 23:32
Reporter: Peter Platform:  
Assigned To: Hans Hagen OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: rulethickness disturbs alignment in TABLE
Description: Hello,

Here is an alignment problem due to the rulethickness.
Is there a cleaner and more elegant solution?

\starttext
\section{First line shifted to the right by a bit less
  than 2pt}
\setupTABLE[offset=0pt, frame=off]
\setupTABLE[r][1][bottomframe=on, rulethickness=2pt]
\bTABLE
\bTR\bTD bla \eTD \eTR
\bTR\bTD bla \eTD \eTR
\eTABLE

\section{Workaround}
\setupTABLE[offset=0pt, frame=off, rulethickness=0pt]
\setupTABLE[r][1][bottomframe=on, rulethickness=2pt, loffset=-2pt]
\bTABLE
\bTR\bTD bla \eTD \eTR
\bTR\bTD bla \eTD \eTR
\eTABLE
\stoptext

TIA for any help!
Cheers, Peter
Tags:
Steps To Reproduce:
Additional Information: Idea:
An option (for \framed[]{}), that makes offset measuring
from the outer border of the frame.
Attached Files:
Notes
(0000579)
Hans Hagen   
2010-08-02 15:48   
Indeed frames are always there onless offset=overlay is chosen; changing this wil break a lot of other code. The workaround is okay and should be documented.
(0000588)
Peter   
2010-08-02 23:32   
The question is, can we have a new option:
offsetreference=inner (default) or offsetreference=outer
Or something similar.
Peter

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
441 [context] minor always 2010-07-28 21:18 2010-07-28 21:18
Reporter: Peter Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: problem with vertical alignment (indenting and localfootnotes)
Description: Hello,

Here an example with strange vertical alignment:

\setupnotedefinition[footnote][location=left, text=Note~, distance=1em]
\setupnote[footnote][numbercommand=, textcommand=,
  style=, textstyle=, bodyfont=]
\starttext
\startlocalfootnotes
  blub\footnote{blub}
  \placelocalfootnotes % no problem here
\stoplocalfootnotes
\blank[3*big]
\startlocalfootnotes
  \setupindenting[yes, big]
  blub\footnote{blub}
  \placelocalfootnotes % problem with vertical alignment
\stoplocalfootnotes
\stoptext

TIA for any help!
Peter
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
399 [MetaPost] feature request minor have not tried 2010-05-19 16:43 2010-05-19 16:43
Reporter: Taco Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: btex ... etex processing in lua bindings
Description: it should be relatively simple to add a lua function setup for btex ... etex processing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
384 [context] minor always 2010-04-22 13:55 2010-04-22 13:55
Reporter: Taco Platform:  
Assigned To: Hans Hagen OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: \setuphead[chapter][grid=none] in mkiv produces text running into the page header
Description: Example below
Tags:
Steps To Reproduce: \starttext
\setuplayout[grid=yes]% [grid=no]
\setuphead[chapter][grid=none]
\chapter{one\\line\\line}
\stoptext
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
380 [context] minor always 2010-04-12 09:58 2010-04-12 09:58
Reporter: odradek Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: columns and marginal notes conflict
Description: \starttext
\startcolumns

\input{knuth}
\input{tufte}
\column
\input{tufte}
\inmargin{This is in wrong margin}
\input{knuth}
\stopcolumns
\stoptext
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
359 [context] feature always 2010-03-25 16:56 2010-04-01 17:57
Reporter: TomBenjey Platform: Tex-Live  
Assigned To: OS: Windows  
Priority: normal OS Version: Vista  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Need ability to turn off page headers/footers on selected pages
Description: The Chicago Manual of Style, 14th edition, states that page numbers are normally omitted on pages containing only illustrations or tables, except in long sequences of figures or tables. Is it practical within ConTeXt to omit page numbers from a single page within a chapter?

Context needs an option to allow headers/footers to be suppressed for such pages.
Tags:
Steps To Reproduce: \starttext

\dorecurse{10}{\input knuth\par}

\placefigure[page,none]{}{\externalfigure[dummy][factor=max]}

\dorecurse{10}{\input knuth\par}

\placefigure[page,none,header]{}{\externalfigure[dummy][factor=max]} %
no header on float page

\dorecurse{10}{\input knuth\par}

\placefigure[page,none,footer]{}{\externalfigure[dummy][factor=max]} %
no footer on float page

\dorecurse{10}{\input knuth\par}

\placefigure[page,none,empty]{}{\externalfigure[dummy][factor=max]} % no
header and footer on float page

\dorecurse{10}{\input knuth\par}

\stoptext
Additional Information: Wolfgang supports the addition of such an option.
Attached Files:
Notes
(0000520)
Hans Hagen   
2010-04-01 17:57   
this will be implemented when we have a more extensive float model where info is carried around .. the reason is that we need to deal with mixed cases and i'm not going to implement temp mkii hacks while there are better ways

View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
116 [context] feature always 2008-11-24 17:12 2010-02-26 11:37
Reporter: Peter Platform:  
Assigned To: Hans Hagen OS:  
Priority: normal OS Version:  
Status: feedback Product Version:  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Summary: Table tail for Natural Tables
Description: Something like \starttabletail for Natural Tables.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0000442)
Hans Hagen   
2010-02-24 17:53   
it's called foot in natural tables (cf html) but we can consider tail as synonym some day
(0000452)
Peter   
2010-02-26 11:37   
Better description:

Repeated footer for Natural Tables, like in this example:

\setuptables[split=repeat]
\starttext
\starttabletail
\NC footer \NC\AR
\stoptabletail
\starttables[|l|]
\NC test \NC\FR
\dorecurse{100}{\NC test \NC\MR}
\NC test \NC\LR
\stoptables
\stoptext