- ntg-context - NTG Mailing Lists

Fwd: Corrupt PDF files with LMTX?
by Jairo A. del Rio 26 Apr '21

26 Apr '21

---------- Forwarded message --------- De: Jairo A. del Rio <jairoadelrio6(a)gmail.com> Date: sáb, 24 de abr. de 2021 a la(s) 08:05 Subject: Re: [NTG-context] Corrupt PDF files with LMTX? To: Hans Hagen <j.hagen(a)xs4all.nl> The following: \starttext \startMPpage fill fullcircle scaled 1cm withcolor red \stopMPpage \stoptext gives **** Error: stream Length incorrect. Output may be incorrect. **** Error: stream Length incorrect. Output may be incorrect. However, an image is generated. However, when it includes text, the message above appears. As Thomas says, it happens even with simple documents. Jairo El sáb, 24 de abr. de 2021 a la(s) 01:36, Hans Hagen (j.hagen(a)xs4all.nl) escribió: > On 4/24/2021 8:03 AM, Jairo A. del Rio wrote: > > Hi, list! > > When I try to convert a PDF generated by ConTeXt LMTX to PNG using > > ImageMagick's convert the following happens: > hard to handle when there is no mwe ... > > Hans > > ----------------------------------------------------------------- > Hans Hagen | PRAGMA ADE > Ridderstraat 27 | 8061 GH Hasselt | The Netherlands > tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl > ----------------------------------------------------------------- >

2 2

Corrupt PDF files with LMTX?
by Jairo A. del Rio 24 Apr '21

24 Apr '21

Hi, list! When I try to convert a PDF generated by ConTeXt LMTX to PNG using ImageMagick's convert the following happens: **** Error: stream Length incorrect. Output may be incorrect. **** Error: An error occurred while reading an XREF table. **** The file has been damaged. This may have been caused **** by a problem while converting or transfering the file. **** Ghostscript will attempt to recover the data. **** However, the output may be incorrect. Error: /ioerror in --runpdf-- Operand stack: post_eof_count 4096 --nostringval-- 4571 Execution stack: %interp_exit .runexec2 --nostringval-- runpdf --nostringval-- 2 %stopped_push --nostringval-- runpdf runpdf false 1 %stopped_push 1990 1 3 %oparray_pop 1989 1 3 %oparray_pop 1977 1 3 %oparray_pop 1978 1 3 %oparray_pop runpdf runpdf runpdf runpdf runpdf runpdf runpdf Dictionary stack: --dict:735/1123(ro)(G)-- --dict:1/20(G)-- --dict:80/200(L)-- --dict:80/200(L)-- --dict:135/256(ro)(G)-- --dict:315/325(ro)(G)-- --dict:28/32(L)-- Current allocation mode is local GPL Ghostscript 9.50: Unrecoverable error, exit code 1 convert-im6.q16: FailedToExecuteCommand `'gs' -sstdout=%stderr -dQUIET -dSAFER -dBATCH -dNOPAUSE -dNOPROMPT -dMaxBitmap=500000000 -dAlignToPixels=0 -dGridFitTT=2 '-sDEVICE=pngalpha' -dTextAlphaBits=4 -dGraphicsAlphaBits=4 '-r300x300' '-sOutputFile=/tmp/magick-55690XUwDR8veJQEc%d' '-f/tmp/magick-55690zbxNvSPCVCYe' '-f/tmp/magick-55690aVvG11u3p8wd'' (1) @ error/pdf.c/InvokePDFDelegate/291. convert-im6.q16: no images defined `151.png' @ error/convert.c/ConvertImageCommand/3258. I'd blame ImageMagick, except for the fact that 1) other converters fail too and 2) it doesn't happen with ConTeXt MkIV (PDF is successfully converted). Cordially, Jairo

3 2

Bug: missing Lua API in binaries
by Sylvain Hubert 24 Apr '21

24 Apr '21

Dear Devs, Sorry if this is not the best place for reporting bugs. I'm trying to use the lpeglabel library written in C and delivered as lpeglabel.so. $ ls testlabel.lua lpeglabel.so $ cat testlabel.lua require("lpeglabel") The ConTeXt binary cannot load the library because it lacks certain Lua API: $ context --forcecld --permitloadlib testlabel.lua ... fatal lua error: registered function call [1542]: ...tx/tex/texmf-context/tex/context/base/mkiv/l-package.lua:348: error loading module 'lpeglabel' from file './lpeglabel.so': ./lpeglabel.so: undefined symbol: lua_gettop ... nor does LuaTeX: $ luatex -luaonly testlabel.lua error loading module 'lpeglabel' from file './lpeglabel.so': ./lpeglabel.so: undefined symbol: lua_getiuservalue It seems that lua_gettop and others are optimized out from the `context` binary, while lua_getiuservalue and others are missing from `luatex`. I'm not sure if it works but I would suggest adding `__attribute__ ((used))` to the `LUA_API` macro if the binaries are compiled with gcc. Best, Sylvain

2 3

nbsp in XML (S01E01)
by Jano Kula 23 Apr '21

23 Apr '21

Dear list, first episode of series on nbsp of XML in lmtx. Unfortunately, not that catchy as Netflix. Used XML input has two types of non-breakable space: - unicode character - html entitity (in fact an ugly output of HTML editor) HTML is preprocessed with ctx preprocessor (great feature!) and substituted for unicode char nbsp or tilde. MWE shows unichar spaces are non-breakable (see end of the first lines), however they are not stretchable (see second line of the paragraphs). Does unicode nbsp have fixed with in ctx? When tilde is the replacement in preprocessor (uncomment first replacement in preprocessor), xmlfush will display tilde (which is, as character, non-breakable and unstretchable, no surprise). Why tilde is displayed? Replacing or adding nbsp (tilde) with finalizers have different results, see next episode after this one is understood. Thank you, Jano MWE (rather use attached file not to loose invisible characters): \startbuffer[doc] <?xml version "1.0"?> <document> Temperature 20 °C 20 °C 20 °C 20 °C average. Altitude 6000&nbsp;m 6000&nbsp;m 6000&nbsp;m 6000&nbsp;m average. </document> \stopbuffer \startluacode function lxml.preprocessor(data) -- data = string.gsub(data, "&nbsp;", "~") -- replacement nbsp invisible in luacode data = string.gsub(data, "&nbsp;", " ") return data end \stopluacode \startxmlsetups xml:name \xmlsetsetup{\xmldocument}{*}{-} \xmlsetsetup{\xmldocument}{document|p}{xml:name:*} \stopxmlsetups \xmlregistersetup{xml:name} \startxmlsetups xml:name:document \xmlflush{#1}\par \stopxmlsetups \startxmlsetups xml:name:p \parfillskip0pt\xmlflush{#1}\par \stopxmlsetups \startTEXpage[offset=5mm,width=60mm] \xmlprocessbuffer{xml:name}{doc}{} \stopTEXpage

6 7

ToC filler dots/leaders not aligned in LMTX
by Schister, Roman 23 Apr '21

23 Apr '21

Hello everyone I’m trying to typeset a table of contents with filler dots (list alternative C) in LMTX. Unfortunately, the dots are not vertically aligned and do not end flush on the right-hand side. If I try to use leaders in a paragraph, I get the same behaviour: the leading dots are not aligned. Compiling the same document with MkIV leads to correct alignment of the filler dots in both instances. Here is an MWE: \setuplistalternative[c][width=2em] \starttext \completecontent[alternative=c] \chapter{Short title} Lorem ipsum \hskip.5em\gleaders\hbox to .5\emwidth{\hss.\hss}\hfill\hskip.5em\relax dolor sit amet. \par Lorem \hskip.5em\gleaders\hbox to .5\emwidth{\hss.\hss}\hfill\hskip.5em\relax ipsum dolor sit amet. \chapter{Slighlty longer title} \chapter{Not so long title} \stoptext Are there any changes in LMTX that I need to take into account when typesetting a ToC/leaders? Any help is much appreciated. Thank you! Roman

2 1

setupalign[height] vs setupalign[line] in MKIV
by denis.maier＠ub.unibe.ch 23 Apr '21

23 Apr '21

Hi, I've noticed a somewhat unexpected behaviour. MWE below. \setupalign[line] adds an enormous amount of whitespace to fill a last page, but \setupalign[height] doesn't. Is that intended ? Currently this only happens with mkiv. As stated in another mail, these options seem to have no effect at all under LMTX. Best, Denis \setuppapersize[A5][A5] \showframe \setupdelimitedtext[blockquote] [before={\switchtobodyfont[small]}, spacebefore={medium,flexible},] \starttext \setupalign[line] % this here causes the last page to be filled \section{A section heading} \input knuth\par \page \setupalign[height] %this here doesn't \section{A section heading} \input knuth\par \stoptext

1 0

Page building and vertical stretching
by denis.maier＠ub.unibe.ch 22 Apr '21

22 Apr '21

Hi, in addition to my previous mails about \setupalign[height], a further question related to page building : I'm trying to understand how ConTeXt builds pages, and how this can be influenced. Regarding the example below, the aim is to have pages that always end at the same place. Now, how will ConTeXt use stretching? Blanks are set to flexible, and the interlinespacing is set to stretch. (But different values for blockquotes.) In which order will ConTeXt proceed? Interlinespacing first, then blanks? Or the other way round? Or both at the same time? And, can this be influenced somehow? Best, Denis \setuppapersize[A5][A5] \showframe \setupblank[big,flexible] \setupinterlinespace[stretch=0.03] \setuptolerance[vertical,stretch] \setupalign[height] \setuphead [section,subject] [ before={\blank[2*big,flexible]}, after={\blank[big,flexible]}, ] \setupdelimitedtext[blockquote] [ before={\tfx\setupinterlinespace[stretch=0.05]}, spacebefore={medium,flexible}, left= ] \starttext \input knuth \section{A section heading} \input knuth\par \blank \input knuth\par \startblockquote \input knuth\par \stopblockquote \input knuth\par \startblockquote \input knuth\par \stopblockquote \input knuth\par \stoptext

1 0

Change to wordright behavior?
by Rik Kabel 21 Apr '21

21 Apr '21

Dear all, At some time in the last couple of years the behavior of \wordright seems to have changed, at least in the following situation. With the following example: \starttext \hsize3cm Aaa\wordright{Aaa}\par \sc{Bbb\wordright{Bbb}}\par {\sc Ccc\wordright{Ccc}}\par \sc{Ddd}\wordright{\sc{Ddd}}\par \stoptext Produces: The second and third lines with \wordright (Bbb and Ccc) each generate two lines. They previously produced one line each. Placing each part of the line in its own \sc addresses it here (Ddd), but it does seem that it should not be necessary to do that. Was this an intentional change? -- Rik

1 1

next upload
by Hans Hagen 21 Apr '21

21 Apr '21

Hi, The *next* upload will have the following change. For a long time in mkiv and also lmtx, the tex habit of turning -- and --- into endash and emdash has been handled at the font level by a injecting a font feature. This works okay. This tlig feature is currently part of the defaults but that will change. If you want to retain that, you can add this to a cont-loc.mkxl file \definefontfeature [default] [default] [tlig=yes, trep=yes] but it should not be needed (and only introduces overhead). When it's a font feature it kicks in after hyphenation but because we're in the process of enhancing that, this traditional -- and --- replacement now kicks in before hyphenation. It can be disabled by \nohyphencollapsing, which actually happens in for instance verbatim and it can be applied locally if needed. There might be places where you expect this to happen so let me know if I missed these. The (intended) effect is that somefirst- and secondpart\blank firstpart\char"002D secondpart\blank firstpart---secondpart\blank firstpart\char"002D\char"002D secondpart\blank firstpart\char"002D\char"002D\char"002D secondpart\blank firstpart\char"2010 secondpart\blank firstpart\char"2013 secondpart\blank firstpart\char"2014 secondpart \type{firstpart---secondpart} all work as I expect (both words get hyphenated). The trep feature was already stripped to only ' replacment but in these unicode times that artifact has no place. We anyway expect users to use \quote and \quotation as it's a language dependent feature. You can of course enable it any time, but it will no longer be default, just like " already gives an upright double quote, and `` was never enabled in mkiv, from now on ' will give a single upright quote. So, when this is uploaded, keep an eye on it and let me know where things misbehave, you're warned, Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

1 0

xml processing in latest
by Thomas A. Schmitz 21 Apr '21

21 Apr '21

Hi all, the latest has some strange problems with xml processing. The example below shows an issue with itemize. In my real file, I also get pages that are filled only two thirds and rugged right instead of justified, but I haven't been able to reproduce this in a MWE. Maybe this one can give a start; I assume it's some fundamental typo somewhere. All best Thomas \startbuffer[test] <document> test <numbered> <item> one </item> <item> two </item> </numbered> </document> \stopbuffer \startxmlsetups xml:testsetups \xmlsetsetup{#1}{*}{-} \xmlsetsetup{#1}{document|p|numbered|item}{xml:*} \stopxmlsetups \xmlregistersetup{xml:testsetups} \startxmlsetups xml:document \xmlflush{#1} \stopxmlsetups \startxmlsetups xml:p \xmlflush{#1} \par \stopxmlsetups \startxmlsetups xml:numbered \startitemize [n] \xmlflush{#1} \stopitemize \stopxmlsetups \startxmlsetups xml:item \startitem \xmlflush{#1} \stopitem \stopxmlsetups \starttext \xmlprocessbuffer{main}{test}{} \stoptext

2 3