Re: [NTG-context] lua-widow-control module error in LMTX
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
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
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
Re: [NTG-context] lua-widow-control module error in LMTX
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
Re: [NTG-context] lua-widow-control module error in LMTX
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 >
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
[NTG-context] lua-widow-control module error in LMTX
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
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?
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
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
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
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
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
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
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
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
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
___
