Re: [NTG-context] lua-widow-control module error in LMTX
On 2022-04-25 6:51 p.m., Eduardo Bohoyo wrote: First things first. I want to acknowledge and thank you for the tough mission that surely involves maintaining this module for the benefit of the TeX community and, most especially, for LMTX in particular, due to the very reasons you have just explained. Well thanks :) These days I write most of my documents in LMTX, so the LMTX support is pretty self-serving -- I'm admittedly surprised that there's another lwc + LMTX user. Regarding your remarks, you are right in your assumptions: I didn't have the required lua file installed in its corresponding folder. That's what I was missing, and, logically, what made my compilation crash. Yeah, it's a pretty easy mistake to make. For Knuth TeX, shared files go in texmf/tex/generic and Plain-specific files go in texmf/tex/plain, but with LuaTeX there's just texmf/tex/luatex so it gets a little confusing. Now I finally get the pdf. But unfortunately, this "new" pdf is the same with the module uncommented as when I had it commented. There is no difference at all. And you're right: even context --make doesn't solve the problem. To give you an idea, although my dummy document has 78 pages, only 55 can really be said to be dummy text that can benefit from the module. Well, only in those 55 pages I have 2 orphans, 5 widows and 6 broken hyphens. So the first step here is to check the log file. If you see lines like module > lua-widow-control > Widow/orphan detected. Attempting to remove. module > lua-widow-control > Widow/Orphan NOT removed on page X. then that means that lwc found a widow/orphan, but gave up. This usually only happens if the page has only really short paragraphs, but it can also happen if there aren't any paragraphs that both start and finish on the page. I've got some neat graphs for this (see the upcoming TUGboat issue), but with default settings this should happen for much less than 10% of potential widows/orphans, so it seems unlikely that this is happening for every page. If this actually is the issue, then you can try raising the "emergencystretch" value in "\setuplwc", but that's probably going to give terrible results. The real solution is to rewrite something, but that should usually be pretty rare. --- If you see lines like module > lua-widow-control > Widow/orphan detected. Attempting to remove. module > lua-widow-control > Widow/orphan successfully removed at paragraph X on page Y. but the widows/orphans weren't actually removed, then something really weird is going on and definitely means that there's a bug in lwc. Rerun the document with \setuplwc[debug=true] immediately after "\usemodule[lua-widow-control]" and either reply with the log or post a new issue on the lwc GitHub. --- If you only see modules > 'lua-widow-control' is loaded but not any other lines mentioning lwc, then something weird is going on, and lwc is loaded but not enabled. If this is the case, same as last time: enable debug mode and reply with the log. --- If you don't see modules > 'lua-widow-control' is loaded at all, then you're not actually loading lwc. This probably means that ConTeXt can't find the file, there should hopefully be clues somewhere in the log file. Thanks again for your work and yours observations. No problem; glad to help. -- Max ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] lua-widow-control module error in LMTX
Hi, Max:
First things first. I want to acknowledge and thank you for the tough
mission that surely involves maintaining this module for the benefit of
the TeX community and, most especially, for LMTX in particular, due to
the very reasons you have just explained.
Regarding your remarks, you are right in your assumptions: I didn't have
the required lua file installed in its corresponding folder. That's what
I was missing, and, logically, what made my compilation crash.
To make my confusion even worse, I had done a strict search inside the
mkxl code. It wouldn't take me to line 63 because I had added the
extension (lua-widow-control.lua, not just lua-widow-control).
Anyway, a mess only due to my ignorance.
Now I finally get the pdf. But unfortunately, this "new" pdf is the same
with the module uncommented as when I had it commented. There is no
difference at all. And you're right: even context --make doesn't solve
the problem. To give you an idea, although my dummy document has 78
pages, only 55 can really be said to be dummy text that can benefit from
the module. Well, only in those 55 pages I have 2 orphans, 5 widows and
6 broken hyphens.
I have read several times all the options of the module in the
/lua-widow-control.pdf/ document, but I don't even dare to mess with
those options because it seems to me very radical that my output pdf is
the same with the module uncommented in my code.
Of course, mtxrun --find-file lua-widow-control.lua yields what you
would expect:
/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua
Thanks again for your work and yours observations.
Edu.
El 25/4/22 a las 22:00, Max Chernoff escribió:
(Please keep me CC'd as I'm not subscribed to the list)
Hi, I'm the lua-widow-control author.
> lua error > lua error on line 74 in file
>
/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl
>
> The odd thing is that line 75 of the t-lua-widow-control file is empty.
The \setuplwc command ends on line 74, which then triggers
\everysetuplwc which then calls \ctxlua{lwc.enable_callbacks()}. This
fails since lwc is undefined because the Lua file isn't loaded because
ConTeXt can't seem to find the file.
In Plain LuaTeX and LuaLaTeX, a missing Lua file is a fatal error:
$ luatex "\nonstopmode\directlua{require 'not-a-real-file'}\bye"
This is LuaTeX, Version 1.13.2 (TeX Live 2021/W32TeX)
restricted system commands enabled.
[\directlua]:1: module 'not-a-real-file' not found:
no field package.preload['not-a-real-file']
[kpse lua searcher] file not found: 'not-a-real-file'
stack traceback:
[C]: in function 'require'
[\directlua]:1: in main chunk.
<*> \nonstopmode\directlua{require 'not-a-real-file'}
\bye
(see the transcript file for additional information)
warning (pdf backend): no pages of output.
Transcript written on texput.log.
so I'm a little surprised that ConTeXt just issues a warning here when
it can't find the file:
resolvers > lua > unknown file 'lua-widow-control.lua'
> when it says it doesn't know the lua-widow-control.lua file. I don't
see
> any mention of this file within the t-lua-widow-control module.
lua-widow-control.lua is loaded at line 63 of the .mkxl:
\ctxloadluafile{lua-widow-control}
> Could it be that this module is not yet mature for lmtx
Lua-widow-control is certainly more stable with Plain/LaTeX, but it
usually runs fine with LMTX. The entire lwc manual is written in
ConTeXt/LMTX so I (usually) notice pretty quickly when things break.
The only real "issue" with LMTX is that the engine changes pretty
quickly, so lwc may sometimes be broken for a few days between an
engine update and whenever I push out a fix. This doesn't happen with
Plain/LaTeX since the LuaTeX engine is mostly frozen.
Interestingly, the MkXL version of lwc actually predates the MkIV
version, although only by a few months.
> I have \usemodule[lua-widow-control] in my tex document, and
> I haven't forgotten to do the prescribed mtxrun --generate after
> including the module in my third-party folder of my luametatex
> installation on Arch.
Hmm, that's odd then. I'm not entirely sure why this is happening, so
I'm going to take a random guess:
Maybe you installed lwc using a zipfile from either GitHub or the
ConTeXt Garden modules site, then you copied the files into your
texmf-modules/ folder, *but* you only copied the "tex/context/" folder
and not all of the folders in the "tex" folder. The
"lua-widow-control.lua" file is in the "tex/luatex/" folder, so if you
didn't also copy that across you're going to have problems.
Again, just a random guess. If that doesn't work, you could maybe try
running
context --make
but I doubt that that would fix anything here. You could also try
deleting the filename cache files
Re: [NTG-context] How do I define a smallcaps font?
Replacing \smallcaps with \sc fixed it. I had assumed they were synonyms---the
same as \bf vs \boldface, \it vs \italicface, but it seems they are different
entirely?
Thanks!
--Joel
On Sunday, April 24, 2022, 11:19:10 AM MDT, Henning Hraban Ramm via
ntg-context wrote:
Am 24.04.22 um 16:21 schrieb Joel via ntg-context:
> I have a font that already comes with a smallcaps variant.
>
> How do I define it?
>
> I've tried the following, which I think should work from the
> documentation I've seen, but doesn't:
>
>
> \starttypescript[serif] [garamond]
> \definefontsynonym[Serif]
> [file:/home/joel/.fonts/12/EBGaramond-Regular.otf]
> \definefontsynonym[SerifBold]
> [file:/home/joel/.fonts/12/EBGaramond-Bold.otf]
> \definefontsynonym[SerifItalic]
> [file:/home/joel/.fonts/12/EBGaramond-Italic.otf]
> \definefontsynonym[SerifBoldItalic]
> [file:/home/joel/.fonts/12/EBGaramond-BoldItalic.otf]
> \definefontsynonym[SerifCaps]
> [file:/home/joel/.fonts/13/EBGaramond12-AllSC.otf]
> \stoptypescript
>
> \starttypescript[sans] [garamond]
> \definefontsynonym[Sans]
> [file:/home/joel/.fonts/12/EBGaramond-Regular.otf]
> \definefontsynonym[SansBold]
> [file:/home/joel/.fonts/12/EBGaramond-Bold.otf]
> \definefontsynonym[SansItalic]
> [file:/home/joel/.fonts/12/EBGaramond-Italic.otf]
> \definefontsynonym[SansBoldItalic]
> [file:/home/joel/.fonts/12/EBGaramond-BoldItalic.otf]
> \definefontsynonym[SansCaps]
> [file:/home/joel/.fonts/13/EBGaramond12-AllSC.otf]
> \stoptypescript
>
> \starttypescript[garamond]
> \definetypeface[garamond]
> [rm][serif][garamond][default]
> \definetypeface[garamond]
> [ss][sans][garamond][default]
> \definetypeface[garamond]
> [mm][math][modern][default]
> \stoptypescript
>
> \starttext
>
> This is regular text.
>
> {\smallcaps This should be in smallcaps.}
>
> {\WORD This should be regular text, but capitalized, not really
> smallcaps.}
>
> \stoptext
SerifCaps etc. works with the traditional \sc, don’t know about \smallcaps.
Are you sure your fonts are found?
mtxrun --script fonts --list --all --pattern=EBGaramond
If your regular OpenType font contains smallcaps, try:
\definefontfeature[mysmallcaps][default][
smcp=yes, % smallcaps
script=latn,
]
\starttypescript [serif] [garamond] [name]
...
\definefontsynonym [SerifCaps][EBGaramond-Regular][features=mysmallcaps]
...
Hraban
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] lua-widow-control module error in LMTX
(Please keep me CC'd as I'm not subscribed to the list)
Hi, I'm the lua-widow-control author.
> lua error > lua error on line 74 in file
>
/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl
>
> The odd thing is that line 75 of the t-lua-widow-control file is empty.
The \setuplwc command ends on line 74, which then triggers
\everysetuplwc which then calls \ctxlua{lwc.enable_callbacks()}. This
fails since lwc is undefined because the Lua file isn't loaded because
ConTeXt can't seem to find the file.
In Plain LuaTeX and LuaLaTeX, a missing Lua file is a fatal error:
$ luatex "\nonstopmode\directlua{require 'not-a-real-file'}\bye"
This is LuaTeX, Version 1.13.2 (TeX Live 2021/W32TeX)
restricted system commands enabled.
[\directlua]:1: module 'not-a-real-file' not found:
no field package.preload['not-a-real-file']
[kpse lua searcher] file not found: 'not-a-real-file'
stack traceback:
[C]: in function 'require'
[\directlua]:1: in main chunk.
<*> \nonstopmode\directlua{require 'not-a-real-file'}
\bye
(see the transcript file for additional information)
warning (pdf backend): no pages of output.
Transcript written on texput.log.
so I'm a little surprised that ConTeXt just issues a warning here when
it can't find the file:
resolvers > lua > unknown file 'lua-widow-control.lua'
> when it says it doesn't know the lua-widow-control.lua file. I don't see
> any mention of this file within the t-lua-widow-control module.
lua-widow-control.lua is loaded at line 63 of the .mkxl:
\ctxloadluafile{lua-widow-control}
> Could it be that this module is not yet mature for lmtx
Lua-widow-control is certainly more stable with Plain/LaTeX, but it
usually runs fine with LMTX. The entire lwc manual is written in
ConTeXt/LMTX so I (usually) notice pretty quickly when things break.
The only real "issue" with LMTX is that the engine changes pretty
quickly, so lwc may sometimes be broken for a few days between an engine
update and whenever I push out a fix. This doesn't happen with
Plain/LaTeX since the LuaTeX engine is mostly frozen.
Interestingly, the MkXL version of lwc actually predates the MkIV
version, although only by a few months.
> I have \usemodule[lua-widow-control] in my tex document, and
> I haven't forgotten to do the prescribed mtxrun --generate after
> including the module in my third-party folder of my luametatex
> installation on Arch.
Hmm, that's odd then. I'm not entirely sure why this is happening, so
I'm going to take a random guess:
Maybe you installed lwc using a zipfile from either GitHub or the
ConTeXt Garden modules site, then you copied the files into your
texmf-modules/ folder, *but* you only copied the "tex/context/" folder
and not all of the folders in the "tex" folder. The
"lua-widow-control.lua" file is in the "tex/luatex/" folder, so if you
didn't also copy that across you're going to have problems.
Again, just a random guess. If that doesn't work, you could maybe try
running
context --make
but I doubt that that would fix anything here. You could also try
deleting the filename cache files at:
{CONTEXT}/texmf-cache/luametatex-cache/context/*/trees/*.lu?
then rerunning
mtxrun --generate
I've never deleted those files before, but it's in a folder called
"cache" so it's _probably_ safe to delete (make a backup just in case
though).
If none of that works, then the issue could be something else on your
end, or I could have screwed something up in lwc. In that case, try running
find /opt/luametatex/texmf-modules/ -path '*widow*' -print
and
mtxrun --find-file lua-widow-control.lua
and reply with the output.
Oh, and one more note. ConTeXt version "2022-04-11 19:20" renamed some
of the engine Lua functions, so make sure to update to lwc v2.0.6 (if
you're using a recent ConTeXt version). Otherwise after you fix the
"unknown file" error, you would get an "attempt to call a nil value"
error which isn't any better.
Let me know if you have any other issues.
-- Max
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
Re: [NTG-context] issue with framed texts
Pablo Rodriguez via ntg-context schrieb am 25.04.2022 um 18:17: On 4/24/22 21:13, Wolfgang Schuster via ntg-context wrote: Pablo Rodriguez via ntg-context schrieb am 24.04.2022 um 20:56: [...] Using current LMTX (2022.04.20 19:18), I’m afraid no format from \setupframedtext is applied to the backcover framed text. [...] While you can pass a instance to \starframed (e.g. \startframed[backcover]) the same isn't possible with \startframedtext. Many thanks for your reply, Wolfgang. I thought I could do that, because http://www.pragma-ade.com/general/qrcs/setup-en.pdf seems to allow it. \startframedtext allow the following four keywords for the first optional argument - left - middle - right - none These four keywords can be used to control the horizontal alignment of the frame but they aren't framedtext instances. Wolfgang ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] issue with framed texts
On 4/24/22 21:13, Wolfgang Schuster via ntg-context wrote: > Pablo Rodriguez via ntg-context schrieb am 24.04.2022 um 20:56: >> [...] >> Using current LMTX (2022.04.20 19:18), I’m afraid no format from >> \setupframedtext is applied to the backcover framed text. >> [...] > While you can pass a instance to \starframed (e.g. > \startframed[backcover]) the same isn't possible with \startframedtext. Many thanks for your reply, Wolfgang. I thought I could do that, because http://www.pragma-ade.com/general/qrcs/setup-en.pdf seems to allow it. Many thanks for your help, Pablo ___ If your question is of interest to others as well, please add an entry to the Wiki! maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context webpage : http://www.pragma-ade.nl / http://context.aanhet.net archive : https://bitbucket.org/phg/context-mirror/commits/ wiki : http://contextgarden.net ___
Re: [NTG-context] cropoffset reduces paper size
Hi, I’d like to know if the changed behavior is intentional and will
stay this way – in that case I’d need to change my environments and
update the documentation.
Hraban
Am 15.04.22 um 21:31 schrieb Henning Hraban Ramm via ntg-context:
Hi, at least in the current and previous LMTX beta, the paper size gets
reduced if I use cropoffset as well as \setupinteractionscreen.
(It is known that the PDF box settings only work with the latter.)
In the MWE below, paper size gets reduced by cropoffset:
\setuppapersize[A4]
\setuplayout[
cropoffset=10mm,
]
\setupinteractionscreen[
width=max,height=max,
]
\starttext
\showframe
\samplefile{knuth}
\stoptext
If I set:
\setuppapersize[A4][A4,oversized]
\setuplayout[
marking=on,
location=middle,
cropoffset=7.5mm,
]
Then the resulting paper size is A4, because the "oversized" factor is
nulled by the crop offset.
While I can work around this "feature", the behaviour is different from
earlier versions. Can’t check with MkIV, since that doesn’t work any
more, as reported by Pablo et al.
Hraban
___
If your question is of interest to others as well, please add an entry to the
Wiki!
maillist : ntg-context@ntg.nl / http://www.ntg.nl/mailman/listinfo/ntg-context
webpage : http://www.pragma-ade.nl / http://context.aanhet.net
archive : https://bitbucket.org/phg/context-mirror/commits/
wiki : http://contextgarden.net
___
