Re: [NTG-context] lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

Now, I don't have any widows in my document, and I only count 2 broken 
hyphens.


However, I think this is at the expense of the shenanigans the module 
has "perpetrated" elsewhere, because, apart from the crazy horizontal 
spacing of some paragraph in the bibliography, the module lies to me in 
the log.


Yes, the log output fools me. There is no "Widow/Orphan NOT removed". 
But this is not true:


To the 2 broken hyphens must be added 4 orphan lines that the log claims 
to have resolved. But what worries me the most is that it counts as 
successful one occasion with an empty line, another occasion with two 
empty lines in a row, and 4 occasions with no less than 7 empty lines in 
a row at the beginning of a chapter.


I don't know if this information can provide any more clues to adjust 
the module for the grid mode, but I hope it helps.


Greetings,

Edu.

El 29/4/22 a las 2:38, Max Chernoff escribió:

On 2022-04-28 3:30 a.m., Henning Hraban Ramm wrote:
I’m afraid the above release introduced a bug; while the offical 
release ran through, I now get:


module  > lua-widow-control > Widow/orphan detected. 
Attempting to remove.

lua error   > lua error on line 112 in file de/c_intro.tex:

callback error: 
...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: 
attempt to perform arithmetic on a nil value (field 'height')

stack traceback:
 ...local/tex/luatex/lua-widow-control/lua-widow-control.lua:510: 
in function 
<...local/tex/luatex/lua-widow-control/lua-widow-control.lua:360>


On 2022-04-28 4:54 a.m., Eduardo Bohoyo wrote:

Here testing that beta version.

As you know, my book is in grid mode, but I get the same error 
message as Hraban when the compilation crashes.


However, when I comment grid again in my document, it does compile 
the pdf.


Well that's why it was a beta :) Looks like I made some questionable 
assumptions
about the order of the hlist/baselineskip nodes, so the module 
completely broke

with things as simple as section headings.

Hopefully this new beta should fix things:

https://github.com/gucci-on-fleek/lua-widow-control/releases/tag/release-5e240b2ebb76f33c32ecbc673af09a1c64773033

Grid snapping is a little peculiar, so let me know if you find any 
more bugs.


And thanks for the bug reports.
-- 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

[Eduardo Bohoyo via ntg-context]

Hi Max:

Here testing that beta version.

As you know, my book is in grid mode, but I get the same error message 
as Hraban when the compilation crashes.


However, when I comment grid again in my document, it does compile the pdf.

Thanks,

Edu

El 28/4/22 a las 9:25, Max Chernoff escribió:

On 2022-04-27 3:59 p.m., Eduardo Bohoyo wrote:
When I uncomment grid=yes in my \setuplayout, lwc makes its real 
appearance on the scene.

So it looks like lwc was broken with grid snapping. This surprised me --
I originally wrote lwc *specifically* to use with grid snapping -- but it
looks like I quickly forgot about that goal and never actually tested it
with grids.

I suppose that in other documents than mine, i.e. less complex, this 
performance would be a success. But in my file it is, considering my 
current aesthetic requirements, a failure. This is because for me 
grid=yes is a non-negotiable part of my code.


I _think_ that I've fixed it now. Can you try the beta version at

https://github.com/gucci-on-fleek/lua-widow-control/releases/tag/release-47ff19d9804f6ecea64dda59426664680d9756e0

please? Hopefully this solves the issue.

Do you want the new pdf with lwc actually acting on my file? Then you 
can get a better idea of what I mean by the end of some pages when I 
comment grid=yes (apart from the mischief that happens with the 
horizontal spaces in some paragraphs of the bibliographic section).


Or, if you prefer, and you need more feedback, I can send you my 
current code to use it as a test bench for " daring " texts.


I was able to reproduce the issue just by adding

    \setuplayout[grid=yes]

to my "standard" test files, so I shouldn't need anything else, provided
that the above beta actually fixes anything. If there are still lingering
issues, then having the TeX source would likely simplify things on my 
end.


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

[NTG-context] Fwd: lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

Hello, Max:

As I promised you this morning, I had time this evening to read more 
carefully all your remarks in the last mail. And now I can answer you 
with more basis.


In my particular case, it is not necessary to consider any of the seven 
possible problems you describe from highest to lowest probability. The 
question you asked me in the first paragraph about "interesting" 
features in my ConTeXt code is the key.


When I uncomment grid=yes in my \setuplayout, lwc makes its real 
appearance on the scene. I suppose that in other documents than mine, 
i.e. less complex, this performance would be a success. But in my file 
it is, considering my current aesthetic requirements, a failure. This is 
because for me grid=yes is a non-negotiable part of my code.


As I told you this morning when I sent you my pdf without the module 
activated, but with the layout my way, I understand that lwc can have 
problems with a text whose chapters have capital letters and small caps 
on the first page with less text than on the following pages; with long 
quotations that involve paragraphs of different layout and separated 
from the main text; with more than one footnote in a row, with a 
bibliography at the end with French indentation; with vertical spaces 
separating two lines within the same chapter when in the dummy text 
there is a supposed change of scene within the narrative; with etc. 
etc., etc., etc...


Anyway, after uncommenting grid=yes again, I will send you the log file, 
as you asked me. By the way, I do get some "Widow/Orphan NOT removed on 
page..." in spite of the rest of "successes" that move the final lines 
of my pages away from the result I would like, and that you have seen in 
the pdf I sent you this morning.


Do you want the new pdf with lwc actually acting on my file? Then you 
can get a better idea of what I mean by the end of some pages when I 
comment grid=yes (apart from the mischief that happens with the 
horizontal spaces in some paragraphs of the bibliographic section).


Or, if you prefer, and you need more feedback, I can send you my current 
code to use it as a test bench for " daring " texts.


Greetings,

edu


El 27/4/22 a las 9:14, Max Chernoff escribió:

Quick question before I begin: are you using any especially "interesting"
ConTeXt features? By "interesting" I mean things like grid typesetting,
pagecolumns, bidirectional text, etc. I haven't tested lwc with every
possible ConTeXt feature, so there may be some adverse interaction. If
you are using something like this, try disabling it and see if that solves
anything (then let me know so that I can fix it!)

On 2022-04-26 3:45 a.m., Eduardo Bohoyo wrote:


I can see "modules > 'lua-widow-control' is loaded".

But, luckily, I can also see this:

open source > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl' 

resolvers   > lua > loading file 
'/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua' 
succeeded
close source    > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl' 


module  > lua-widow-control > Already enabled


Ok, so this is good; lwc is for sure being loaded successfully.


No line such as "Widow/orphan detected. Attempting to delete".

I see interleaved new groups with the same line always repeating a 
warning message throughout the whole file. In short, there are 613 
new lines with the message "luatex warning > tex: left parfill skip 
is gone".
But I didn't give it any importance, because I interpreted that they 
could be inherent to the module.


Well this at least narrows the issue down quite a bit. Lwc runs in pretty
much two stages: when a paragraph has finished being broken by TeX, lwc
saves the paragraph. The second stage is ran just before each time the
output routine is triggered so that lwc can remove the widows and orphans.

Due to an lwc bug, the first stage results in the "left parfill skip"
warning being printed twice for each paragraph. Normally this is quite
annoying, but here it is good -- we know for sure that the first stage
is running just fine.

It is the second stage where you should get the "Widow/orphan detected"
message, but this isn't happening. The code here is at lwc.lua:362-388.

Here is a list of all possible reasons, in order of likelihood, why
"Widow/orphan detected" wouldn't be printed when there is actually
a widow or orphan:

(Just listing all of these to make sure that *I* don't forget 
anything. I'd

 say that 1 and 2 are the only ones that are actually likely -- you can
 probably ignore all of the others)

 1. "\clubpenalty" and/or "\widowpenalty" are either zero or infinite

    In these cases, lwc can't distinguish a widow o

Re: [NTG-context] lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

Erratum: When I wrote script, I meant hyphen.

El 26/4/22 a las 11:45, Eduardo Bohoyo escribió:

Hi:

No line such as "Widow/orphan detected. Attempting to delete".

I see interleaved new groups with the same line always repeating a 
warning message throughout the whole file. In short, there are 613 new 
lines with the message "luatex warning > tex: left parfill skip is gone".
But I didn't give it any importance, because I interpreted that they 
could be inherent to the module.


I can see "modules > 'lua-widow-control' is loaded".

But, luckily, I can also see this:

open source > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'
resolvers   > lua > loading file 
'/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua' 
succeeded
close source    > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'

module  > lua-widow-control > Already enabled


On the other hand, the distribution and size of my paragraphs take 
great care that their "design" optimises the module's goodness, 
except, of course, for the first pages of each of the nine dummy text 
chapters (they start at a third of a page).
But it is very curious that, even so, only the two orphan lines I 
mentioned, and only two of the five widows relate to two or three of 
those "supposedly problematic" first chapter pages (as I said, nine in 
total). And the case of the broken scripts is even stranger: only two 
of the six breakages concern a couple of those early chapter pages.


I will go over the lua-widow-control.pdf document once more in case 
there is a tiny detail I am missing, but I think, if I keep going at 
this pace, I will end up learning it by heart.


Well, joking aside, thanks again for your advice, Max.

Edu.

El 26/4/22 a las 4:42, Max Chernoff escribió:

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 lo

Re: [NTG-context] lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

Hi:

No line such as "Widow/orphan detected. Attempting to delete".

I see interleaved new groups with the same line always repeating a 
warning message throughout the whole file. In short, there are 613 new 
lines with the message "luatex warning > tex: left parfill skip is gone".
But I didn't give it any importance, because I interpreted that they 
could be inherent to the module.


I can see "modules > 'lua-widow-control' is loaded".

But, luckily, I can also see this:

open source > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'
resolvers   > lua > loading file 
'/opt/luametatex/texmf-modules/tex/luatex/lua-widow-control/lua-widow-control.lua' 
succeeded
close source    > level 2, order 4, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'

module  > lua-widow-control > Already enabled


On the other hand, the distribution and size of my paragraphs take great 
care that their "design" optimises the module's goodness, except, of 
course, for the first pages of each of the nine dummy text chapters 
(they start at a third of a page).
But it is very curious that, even so, only the two orphan lines I 
mentioned, and only two of the five widows relate to two or three of 
those "supposedly problematic" first chapter pages (as I said, nine in 
total). And the case of the broken scripts is even stranger: only two of 
the six breakages concern a couple of those early chapter pages.


I will go over the lua-widow-control.pdf document once more in case 
there is a tiny detail I am missing, but I think, if I keep going at 
this pace, I will end up learning it by heart.


Well, joking aside, thanks again for your advice, Max.

Edu.

El 26/4/22 a las 4:42, Max Chernoff escribió:

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 lo

Re: [NTG-context] lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

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 

[NTG-context] lua-widow-control module error in LMTX

[Eduardo Bohoyo via ntg-context]

Hi,
I would like to know if anyone has experienced the same error with the 
lua-widow-control module when compiling the pdf:


modules > 'lua-widow-control' is loaded
open source > level 2, order 3, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'.

resolvers > lua > unknown file 'lua-widow-control.lua'
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.
On the other hand, I confess that I don't know what "resolvers" means 
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.


Could it be that this module is not yet mature for lmtx, or am I missing 
something? 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.


Kind regards,

Edu

___
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

[Eduardo Bohoyo via ntg-context]

El 21/4/22 a las 22:08, Eduardo Bohoyo escribió:

Hi,
I would like to know if anyone has experienced the same error with the 
lua-widow-control module when compiling the pdf:


modules > 'lua-widow-control' is loaded
open source > level 2, order 3, name 
'/opt/luametatex/texmf-modules/tex/context/third/lua-widow-control/t-lua-widow-control.mkxl'.

resolvers > lua > unknown file 'lua-widow-control.lua'
lua error > lua error on line 75 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.
On the other hand, I confess that I don't know what "resolvers" means 
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.


Could it be that this module is not yet mature for lmtx, or am I 
missing something? 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.


Kind regards,

Edu


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

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

[NTG-context] Advisable setupitaliccorrection in LuaMetaTeXT?

[Eduardo Bohoyo]

Hi.

Is it still necessary to use setupitaliccorrection if we have switched 
to LMTX?


___
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] lmtx and defined placeinitial color

[Eduardo Bohoyo]

You are welcome. Obviously, it's a dirty trick. For example, it falls 
down if we have a non-white background on our page.


Hopefully LMTX won't take long to update.

Eduardo Bohoyo

El 26/5/21 a las 0:01, jbf escribió:
Thanks Eduardo. Hans had seen the problem and the latest upgrade 
solves it. But I'll keep your little trick in mind!


Julian

On 25/5/21 9:35 pm, Eduardo Bohoyo wrote:
I have just seen that I also experience the same problem. I didn't 
realise it. I have provisionally "solved" it with an unfancy 
workaround. For instance, in your case it could be something like this:


\definecolor[dropcapitals][t=0.40,a=1]

This is not ideal. I know. But for the moment I can't think of 
anything better than to include the transparency trick.


Eduardo Bohoyo


___ 

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] lmtx and defined placeinitial color

[Eduardo Bohoyo]

I have just seen that I also experience the same problem. I didn't 
realise it. I have provisionally "solved" it with an unfancy workaround. 
For instance, in your case it could be something like this:


\definecolor[dropcapitals][t=0.40,a=1]

This is not ideal. I know. But for the moment I can't think of anything 
better than to include the transparency trick.


Eduardo Bohoyo


___
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] Special layouts don't recognise placeinitial

[Eduardo Bohoyo]

Ah, I got it. Thanks for the clarification, Hans.

It's clear that this makes sense.

Eduardo Bohoyo

El 24/5/21 a las 14:22, Hans Hagen escribió:

On 5/24/2021 12:41 PM, Eduardo Bohoyo wrote:

Thank you, Hans. This tweak works perfectly on a provisional basis.

However, from my relative ignorance of ConTeXt and LMTX, I have a 
question: Why is it better at the moment to include this code in 
cont-new.mkxl instead on the preamble of my document?


I insist, I do not question this detail. I speak from the lack of 
knowledge of a user who wants to learn a little more.
cont-new will be replaced at he next uipload so then you use the built 
in .. no need to add to a preamble


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

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

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

Re: [NTG-context] Special layouts don't recognise placeinitial

[Eduardo Bohoyo]

Thank you, Hans. This tweak works perfectly on a provisional basis.

However, from my relative ignorance of ConTeXt and LMTX, I have a 
question: Why is it better at the moment to include this code in 
cont-new.mkxl instead on the preamble of my document?


I insist, I do not question this detail. I speak from the lack of 
knowledge of a user who wants to learn a little more.


Eduardo Bohoyo

El 23/5/21 a las 13:07, Hans Hagen escribió:

On 5/23/2021 2:41 AM, Eduardo Bohoyo wrote:
My question will be very simple: Is there a trick to make 
\placeinitial command work within makeup pages?


One of my pages inside the /frontmater/ is a quote page within an 
special layout. Before using LMTX, when I could use the Lettrine 
module, that quote started with a capital letter. But now that I use 
\placeinitial, the first letter no longer changes: it remains a 
simple initial capital letter.
On the other hand, when I use \placeinitial for each first paragraph 
in the chapters of my book, the result is as expected. That is, the 
command works fine as long as it stays within the general layout.

This is the code I'm referring to:

\startmakeup[standard][doublesided=yes]

\setuplayout[backspace=176pt,width=194pt]
\setupinterlinespace[line=22pt]
\style[tfa]

\startalignment[hanging,flushleft,nothyphenated]
\placeinitial Ahora, vosotros que amáis, dejadme que os formule una 
pregunta: ¿quién sufre más por  ello,  Arcite  o  Palamón? ¿El  que  
ve  a  su  dama  diariamente,  pero  está  encerrado para  siempre,  
o  el  que  es  libre  de  ir  donde  le plazca, pero  no  verá  
nunca  más  a  su  dama?  Aquellos  de vosotros que  podáis,  elegid  
entre  las  dos  situaciones  a voluntad; yo,  por  mi  parte, 
continuaré como he empezado.

\stopalignment

\startalignment[hanging,flushright,nothyphenated]
\blank[0.8cm,force]{\tfa\sc  Geofrey Chaucer,\hspace[big]}
\blank[0.1cm,force]{\tfa\em The Canterbury Tales \hspace[big]}
\stopalignment

\stopmakeup

You can add this to cont-new.mkxl (assuming lmtx)

\unprotect

\permanent\tolerant\protected\def\flushinitial
  {\typo_initial_handle}

\protect

and then

    \placeinitial  \flushinitial Ahora, ...

will work. More clever automated solutions are likely to interfere and 
have side effects for embedded cases so this is the best I can come up 
with now.


Hans



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

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

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

[NTG-context] Special layouts don't recognise placeinitial

[Eduardo Bohoyo]

My question will be very simple: Is there a trick to make \placeinitial 
command work within makeup pages?


One of my pages inside the /frontmater/ is a quote page within an 
special layout. Before using LMTX, when I could use the Lettrine module, 
that quote started with a capital letter. But now that I use 
\placeinitial, the first letter no longer changes: it remains a simple 
initial capital letter.
On the other hand, when I use \placeinitial for each first paragraph in 
the chapters of my book, the result is as expected. That is, the command 
works fine as long as it stays within the general layout.

This is the code I'm referring to:

\startmakeup[standard][doublesided=yes]

\setuplayout[backspace=176pt,width=194pt]
\setupinterlinespace[line=22pt]
\style[tfa]

\startalignment[hanging,flushleft,nothyphenated]
\placeinitial Ahora, vosotros que amáis, dejadme que os formule una 
pregunta: ¿quién sufre más por  ello,  Arcite  o  Palamón? ¿El  que  ve  
a  su  dama  diariamente,  pero  está  encerrado para  siempre,  o  el  
que  es  libre  de  ir  donde  le  plazca, pero  no  verá  nunca  más  
a  su  dama?  Aquellos  de  vosotros que  podáis,  elegid  entre  las  
dos  situaciones  a  voluntad; yo,  por  mi  parte, continuaré como he 
empezado.

\stopalignment

\startalignment[hanging,flushright,nothyphenated]
\blank[0.8cm,force]{\tfa\sc  Geofrey Chaucer,\hspace[big]}
\blank[0.1cm,force]{\tfa\em The Canterbury Tales \hspace[big]}
\stopalignment

\stopmakeup


Eduardo Bohoyo

___
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] lmtx update

[Eduardo Bohoyo]

El 17/9/20 a las 12:50, Eduardo Bohoyo escribió:


El 17/9/20 a las 12:35, Wolfgang Schuster escribió:

Eduardo Bohoyo schrieb am 17.09.2020 um 10:14:

Thank you for this illustrative example, Wolfgang.

So, what \forgetparagraphfreezing does is to reverse the order that 
lmtx currently imposes by default, right? In other words, 
\forgetparagraphfreezing, recovers the default behaviour of MkIV.


So, I suspect that this will not change; if we want to apply 
Lettrine to a paragraph, from now on we must wrap it up with 
\forgetparagraphfreezing and \setparagraphfreezing.


Please correct me if I'm wrong.


LMTX removes some restrictions for settings which are applies to 
paragraphs, e.g. the following example works now without problems 
with LMTX while LuaTeX needs the \dontleavehmode at the begin of the 
paragraph


\starttext

\placefigure[left]{none}{\framed[width=2cm,height=2cm]{}}
%\dontleavehmode
{\bf Tufte: }\input tufte

\stoptext

To avoid side effects from these changes LMTX freezes a few settings 
at the begin of the paragraph. In some cases commands or settings 
have to be adapted to these changes and the lettrine module is one of 
them.


The changes itself to the commands have to be made in the modules 
etc. itself and not in the documents, below is a minimal example how 
the lettrine module has to be changed to get indentation for the 
initial back.


\starttext

\hsize 10cm

\noindent
\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\input weisman

\blank

\begingroup
\noindent
\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\updateparagraphshapes
\endgroup
\input weisman

\stoptext

BTW: ConTeXt already provides a command to place initials as part of 
the core but it lacks a few features of the lettrine module.


Wolfgang



OK, I get it.

Oh, and yes, I knew about the \setupinitial command. Thanks for 
pointing that out.



Sorry, Wolfgag,

I forgot to sign my reply.

Eduardo

___
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] lmtx update

[Eduardo Bohoyo]

El 17/9/20 a las 12:35, Wolfgang Schuster escribió:

Eduardo Bohoyo schrieb am 17.09.2020 um 10:14:

Thank you for this illustrative example, Wolfgang.

So, what \forgetparagraphfreezing does is to reverse the order that 
lmtx currently imposes by default, right? In other words, 
\forgetparagraphfreezing, recovers the default behaviour of MkIV.


So, I suspect that this will not change; if we want to apply Lettrine 
to a paragraph, from now on we must wrap it up with 
\forgetparagraphfreezing and \setparagraphfreezing.


Please correct me if I'm wrong.


LMTX removes some restrictions for settings which are applies to 
paragraphs, e.g. the following example works now without problems with 
LMTX while LuaTeX needs the \dontleavehmode at the begin of the paragraph


\starttext

\placefigure[left]{none}{\framed[width=2cm,height=2cm]{}}
%\dontleavehmode
{\bf Tufte: }\input tufte

\stoptext

To avoid side effects from these changes LMTX freezes a few settings 
at the begin of the paragraph. In some cases commands or settings have 
to be adapted to these changes and the lettrine module is one of them.


The changes itself to the commands have to be made in the modules etc. 
itself and not in the documents, below is a minimal example how the 
lettrine module has to be changed to get indentation for the initial 
back.


\starttext

\hsize 10cm

\noindent
\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\input weisman

\blank

\begingroup
\noindent
\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\updateparagraphshapes
\endgroup
\input weisman

\stoptext

BTW: ConTeXt already provides a command to place initials as part of 
the core but it lacks a few features of the lettrine module.


Wolfgang



OK, I get it.

Oh, and yes, I knew about the \setupinitial command. Thanks for pointing 
that out.


___
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] lmtx update

[Eduardo Bohoyo]

El 17/9/20 a las 1:07, ebohoyod escribió:


El 16/9/20 a las 18:23, Wolfgang Schuster escribió:

ebohoyod schrieb am 16.09.2020 um 17:52:

Hi,

It seems that the Lettrine module is one of those affected:

https://tex.stackexchange.com/questions/562534/does-context-fail-in-the-lmtx-environment-with-the-lettrine-module?noredirect=1#comment1418902_562534 



But, honestly, first, I don't know what means "/Of course it might 
have other side effects once in lmtx we everywhere expect freezing 
to be enabled./"
I suppose that, in order not to be a nuisance (and not to digress 
into this real subject of interest), a short answer would be enough 
to put me on track to investigate it.


On the other hand, I suppose the best practice, from what I have 
just read, would be not to use \forgetparagraphfreezing globaly, but 
\forgetparagraphfreezing  and \setparagraphfreezing at the beginning 
and end of the first paragraph respectively of each chapter.  Would 
this be the least harmful way? That is, wrapping it up to avoid this 
provisional failure of the Lettrine with LMTX module, but at the 
same time to avoid affecting that default freezing proposal in the 
rest of the document, right?


By the way, and just out of curiosity, how does the recommended 
provisional command work? Would it be something like this in the 
preamble?:


\definingparagraphs
 firstparagraph][n=1]
 \setupparagraphs [firstparagraph][1][align={hanging}]

And then this arrangement in the \input files?:

\startfirstparagraph
\lettrine{B}{lah} blah, blah, blah...
\stopfirstparagraph
\blank [overlay] \strut

I know it's a dirty, inelegant solution, but I can't think of a 
better one at the moment.


Below is a minimal example which doesn't rely on the module,
the problem is caused by the order of the \noindent and \parshape
command.

When a paragraph starts before the \parshape values are set
the arguments are ignored because the values are already frozen
at this moment, when you set the values before the paragraphs
starts ConTeXt applies them.

\starttext

\hsize 10cm

% lettrine module, \noindent before \parshape

\noindent
\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\input weisman

\blank

% working order, \parshape before \noindent

\parshape 3 1cm 9cm 1.5cm 8.5cm 0cm 10cm
\noindent
\input weisman

\stoptext

Wolfgang



Thank you for this illustrative example, Wolfgang.

So, what \forgetparagraphfreezing does is to reverse the order that lmtx 
currently imposes by default, right? In other words, 
\forgetparagraphfreezing, recovers the default behaviour of MkIV.


So, I suspect that this will not change; if we want to apply Lettrine to 
a paragraph, from now on we must wrap it up with 
\forgetparagraphfreezing and \setparagraphfreezing.


Please correct me if I'm wrong.

Eduardo.
___
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
___