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