@CarLaTeX hmmm... I'm not sure if that is enough but as I don't use windows perl and don't use latexmk I may not be the right person to help, in a full perl there is a cpan utility which is like tlmgr for tex but connects to cpan which is perl's copy of ctan so if you are missing a MD5 library or whatever it is you just go something like cpan md5 install and it does, but I don't think the texlive perl is hooked up in that way it is just a minimal installation to run the texlive scripts, I think
@CarLaTeX (@PauloCereda knows more about this sort of stuff, or @egreg is of course our windows expert)
@DavidCarlisle Thank you anyway, David! I was whatsupping with Paulo about this problem last night, maybe he or egreg can help me. Otherwise I can do without latexmk. I wanted to use it only for the MWE I do to answer here, the folder where I put them is becoming large, since there are some I want to keep and to clean the auxiliary files manually every now and then is a bit boring.
@CarLaTeX This sounds as if you actually have an external perl (but without the necessary modules) and texlive is using it. What do you get with kpsewhich --expand-var=$TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL ?
@CarLaTeX I will be away in the evening. If you get "1" as answer, try what happens if you change it to zero by adding TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL = 0 to your local texmf.cnf, or by finding the texmf.cnf which sets it to one and changing it there (in my case it is the one in texlive/2017.
@GustavoMezzetti concerning \newpage change: chat.stackexchange.com/transcript/41?m=38110781#38110781 the question is "efficient in what sense?" The visual outcome of the two mods is the same, yours needs more token space and has two extra assignments to execute, while mine makes (sometimes) 2 skips in the output insistead of a single one. So clearly, a dvi would be slightly large but whether or not one runs faster than the other, I couldn't say
@FrankMittelbach Oh you are here ;-). There was an interesting question on the context list about optimization of the page output for a dictionary: If it is possible (with luatex) to avoid widows and orphans by changing columnwidth slightly or changing looseness slightly (vertical spaces should not be changed (gridsetting required). I wondered if alice could do it ...
@UlrikeFischer No sure about the spec you describe. Alice to work needs some flexibility on the page to work and it gets extra flexibility by running paragraphs longer or shorter (via some looseness attempts) and by running spreads long or short by one line. It doesn't try anything with columnwidth as that doesn't translate really into the TeX model
@UlrikeFischer and the variation in looseness may not really give you much with short paragraphs in a dictionary, but that depends on the dictionary I guess. If they are often long enough then it should work nicely
@FrankMittelbach Well if it can change looseness dynamically it would imho at least in part fullfill the specs of the question. It should only avoid stretching vertical spaces to stay on the grid. Also it is set raggedright (that's why small changes in columnwidth are possible) so probably looseness can do a lot.
@FrankMittelbach and Hans asked for a minimal example, so will perhaps try to implement something.
@UlrikeFischer If you allow the column width to change on a paragraph level (somewhat invisible because of the ragged right) then yes, that + looseness would give you a lot of the needed flexibility. If however you want the whole column change its coumn width then you are in trouble doing that as you can't do the galley before the optimization
@UlrikeFischer with looseness you have to be careful not to use the TeX method directly as that tends to move just a single word to the next line which looks quite ugly. so you have to manipulate the token sequence to make breaks near the end of the para fairly bad
@UlrikeFischer good luck to him ... I'm now working on tis for more than a year and still it is WIP prototype level
@UlrikeFischer in that case an approach like I use could work (as it is locally generating variations if they exist and record their outcome). Then of course in addition to looseness you could also vary the column width slightly and simply end up with more variations if they exist
@UlrikeFischer well he needs to do the dynproc programming eventually it doesn't help to get the variations if there isn't something determining which of them to use unless you ty to optimize locally page by page but I doubt that this gives you enough flexibility to work (most of the time).
@FrankMittelbach In this case the one to use seems to be defined as "no widows and orphans" + "on grid" + "flushbottom". Imho this is something that is not seldom wanted, so it wouldn't be bad to have some strategies to get it.
@UlrikeFischer not sure I'm with you. "no widows and orphans" + "on grid" + "flushbottom" is pretty hard if all you can do is to change one or two f the paragraphs on a given page. More often than not there will be no paragraphs to enlarge or shorten, so you can only hope for a solution if you are optimizing across the board and not just locally
@FrankMittelbach I didn't say that it is easy or always possible only that is is wanted ;-). "No widows and orphans" is something quite often requested by publishers. I try to tell people that they pay the price somewhere else with such hard requirements but they often don't want to listen ;-(.
@yo' don't quite agree, but there has to be some checks and balances. On the whole both orphans and widows look bad, but sometimes the alternative is worse
@yo' http://texdoc.net/pkg/interface3 (I chose the syntax since it's similar to CTAN such as http://ctan.org/pkg/xparse) - the pkg is actually a search with aliases, not limited to package names
@StefanKottwitz maybe a "link to this search" could be added somewhere? (just an idea)
@StefanKottwitz ah but it opens the document directly, I would prefer a link to the search as opening document directly on foreign sites could be a red flag...
Are TeX's reading rules, which define the conversion from text to tokens, and which are described on pp. 46-48 of Knuth's The TeXbook (1996), describe correctly and completely the reading rules of the TeX systems available in TeXLive 2017, namely pdfTeX, XeTeX and LuaTeX? If not, where can I find...
Is there anything useful to say here beyond 'They are TeX engines' and linking to the detailed question/answer about incompatibility we had some time ago?
@JosephWright will try to get to the file parsing later (but time a bit squeezed) the multiple dot thing is sort of (not) reflected in the back end .def files (which is why I didn't parse multiple dots at the time, or rather, why I took it out) the stop at first dot is optimised for filename.eps.gz but these days it's more likely people want to do figure-12.4.png
@JosephWright .... but the current mechanism assumes the calling package can separate out the extension from the filename without (in theory) knowing which extensions are supported by the .def that was loaded (hence rules for .eps.gz etc) if you parse multiple dots you really need some pipeline that works from the end seeing which extensions are known, I suppose that is still possible with the existing def files...
@DavidCarlisle Yes, I'd wondered about 'known' extensions. At the moment I'm working on the basis that might be handled by a driver doing 'Oh look, it's a .gz file: parse again and see if we get a second extension we understand'. As this is purely for L3 work I can be confident of the driver set that has to work.
@DavidCarlisle I'm still not sure if we really want to support .eps.gz nowadays (do people still do this?). What I do have to get my head around is epstopdf-type support for 'change the extension'.
@CarLaTeX To be honest, it is not the first time I saw that error regarding Perl programs, but they seems to be Windows specific, perhaps related to the bundled Perl interpreter shipped with TeX Live.
@DavidCarlisle I am not sure, but I think latexmk is shipped with local modules, so there would be no need of retrieving additional modules from CPAN. However, that specific error is indeed related to a missing module. Surprisingly, that module is pretty common, even for the correct usage of tlmgr, so I would suspect some sort of method deprecation in newer Perl interpreters.
@yo' (and @StefanKottwitz): I will take a closer look later on. :) As Stefan suggested, /pkg/interface3 would be my approach, but I see the advantages on your proposal. :)
@JosephWright actually I suppose we should check does it even work, does texlive let dvipdfmx or xelatex shell out to call gunzip? divips.def used to say that but they stopped that and instead build unzip functionality in to save the danger of a backtick shell escape
@DavidCarlisle Heiko's code in grffile seems to look up if there is a rule for the possible extensions: more or less what I was imagining but done the 'other way around'. I guess we could simply build-in support for 'known' two-part extensions (I know of only .gz and .Z)
@JosephWright gunzip functionality is built in but with no backtick to the shell and no uncompress functionality I don't thing .Z works at all (but I'd need to check)
This is dvips(k) 5.997 Copyright 2017 Radical Eye Software (www.radicaleye.com)
' TeX output 2017.06.21:1501' -> test.ps
<c:/texlive/2017/texmf-dist/dvips/base/tex.pro>
<c:/texlive/2017/texmf-dist/dvips/base/texps.pro>
<c:/texlive/2017/texmf-dist/dvips/base/special.pro>.
<c:/texlive/2017/texmf-dist/fonts/type1/public/amsfonts/cm/cmr10.pfb>[1
dvips: Secure mode is 1 so execute <gzip -d compress-test.eps.gz> will not run
]
@DavidCarlisle OK, so what syntax do I need for \DeclareGraphicsRule?
@DavidCarlisle For dvips it works with \DeclareGraphicsRule{.eps.gz}{eps}{.eps.bb}{#1} (or at least the decompression works: I've messed up the .bb so just used the keyval interface)
@JosephWright nobody told me but for years they put that security block on dvips shelling out and had a texlive graphics.cfg that detected if it was going to default to dvips and patched in modified rules not to use backtick escape. So when we got the graphics.cfg back I took that out and changed the rules in dvips.def not to need patching
@DavidCarlisle What I mean is that while compressing graphics might be somewhat esoteric nowadays, using epstopdf isn't. So there has to be continued support for finding one file and using a separate one, and so the graphics rule mechanism is still required in general terms.
@JosephWright yes but that means we only need to support shelling out to the restricted commands allowed to run by default in restricted shell escape so don't need to support arbitrarily long pipelines of commands making arbitrary conversions
In the older xparse how did we handle e{^}? Wrote something that the user could not compile because hes still on TL16 (we'll update him later in the year)
As per Xparse's new e-type argument (replacement for k-type argument), support for xparse's k_ argument type is no longer available as of TeXLive 2016 and thus have stuck to TeXLive 2015 so far. I have numerous macros that are defined using the older k_ arguments, so wondering if there is an eas...
@DavidCarlisle I've not really got to that part of handling images yet: I'll see what looks sensible given the fact we almost certainly don't want/need a system allowing arbitrary commands
@StefanPinnow Thanks for letting me know! (I'm not using pdfplot (yet) and I had not the time to look through the documentation. So I just gave an obvious quick solution.)
@PauloCereda @DavidCarlisle @JosephWright and here is an english man advertising Mönchengladbach: youtube.com/watch?v=hzR5SzIN3Uw. The best is at the end ;-)
@JosephWright thanks was using it to mess with superscript placement on tall parentheses, and broke on his pc, the e works very well and is easy to understand
@JosephWright @DavidCarlisle Today. It is nothing serious, only another demonstration that keyval values in package options should be handled with care/don't always do what one expect. In this case the underscores disappears in \usepackage[pdftitle={Testing the Under\_score PDF Title}]{hyperref}
@egreg and I actually remember now hearing something about it...
Where do I start? I mean, pardon my sincere tone, but you're actually doing three things that should not be done. (1)Use \xspace.(2)Use \ensuremath improperly.(3) Define or re-define one-letter macros for math symbols instead of using more descriptive names. Note that your code would not compile with the error ! LaTeX Error: Command \P already defined. Or name \end... illegal, see p.192 of the manual. — yo'4 mins ago
@AlanMunn note that I said "use \ensuremath improperly" as there are proper usage cases. OTOH, there are none for \xspace. (looking @DavidCarlisle 's direction)
I you thought the world is boring, or changing or whatever, be advised that one of our nuclear power plants has just chosen an intern based on ... a bikini show performance.
@AlanMunn I am not making this up. Literally, they decided to give a scientific intern to the winner of the "Miss High School" competition. Which basically comprised ... bikini show inside a nuclear power plant cooler tower.
@PauloCereda I've changed TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL = 1 into TEXLIVE_WINDOWS_TRY_EXTERNAL_PERL = 0 in texmf.cnf, as Ulrike suggested to me, and now it works!
@DavidCarlisle Exactly: there is a comment about wanting to allow rpdfcrop but that's not 'live'
@DavidCarlisle So I wonder about special-casing rather than providing a general mechanism for this one use case (I'm not too keen on the unzipping one as that won't work I think with epstopdf and so is very limited in a largely PDF-based workflow world)
@DavidCarlisle I'll see where I get to working on image support, but it seems first I have some l3build feature requests ... (might try to rope in @PauloCereda!)
