@HenriMenke Fine, you're the boss. But honestly I cannot see how this is a bug whereas the original definition of canvas is xy plane at z= in the old version of the 3d library was not. IMHO it is precisely the other way around.
@JouleV I usually have a separate document for each figure and then a Makefile to build the whole project. The separate figures are embedded using \includegraphics and they use a shared preamble with the main document to match fonts, colors, etc.
@HenriMenke Not much except that I am not sure that I understand the definition of "bug". My naive definition would be it is something where the results deviate from what is written in the manual.
@HenriMenke @marmot I don't think I need to externalize anything yet. The compilation time is still very fast (I only have about 1-2 TikZ pictures each 2-3 page). But the number of pages is not small. Also, I am writing it instead of copying it - so there may be some mistakes (grammar etc) in the document, and I am wondering if I can compile the document everytime I find an error.
So far I do like that, and now when n is about 25, it is still very good. But I don't think it is good for n about 50 or 80...
@JouleV There are some standard tricks like \includeonly, which I am using when writing huge documents or long beamer presentations. This allows you to only compile the current chapter, say, while keeping the labels.
@JouleV I managed to do something a bit strange for a book. All the figures are in an external document that can be compiled on its own and we thus have PDF versions of each. Each image has a "key" given to it. In the book we pull in the figures using a macro and the key. With a configuration in the preamble, we can switch between using the PDF version i.e. fast compilation, or, "drumroll" pulling in the actual tikzpicture environment from that external file
(just in case we had not configured the two documents in exactly the same way)
@JosephWright it doesn't get started until line 185, and a lot of it is patching things eg the default graphics extensions that wouldn't need patching if it was built in from te start.
@DavidCarlisle I was thinking, seriously, that if we do pre-load expl3, and my medium-term plan of moving l3color and l3graphics to l3kernel works, then it might not be a bad plan ...
@DavidCarlisle Depends I guess: xgraphics presumably would be keyval-based and likely deal with the 'minimum size/maximum size' stuff that for example adjustbox currently adds
@HenriMenke Does this still work for you to get the text back on the grid after formulas for you? It does not here (with updated mkiv). Do you know if something has changed?
@DavidCarlisle I'm really not sure about a 'user level' xgraphics. Unlike xfp, it won't really add anything to the existing structures. It's more a thing for l3trial, like xbox: making sure we can implement everything based on the tools we have
even with adjustbox, as it has the export option to push the extra keys on to \includegraphics rather than making the user wrap in an\adjusbox it is a bit like mathtools, in that it affects the preamble loading but not really document syntax and adding keys has a chance of breaking things, adjustbox for example:-)
@UlrikeFischer If it's in l3experimental it's explicitly for testing ... and we are talking about something with a compatible interface ... though I might also need xbox
@UlrikeFischer Er, no I don't think so: if I do this, I'll block loading of graphicx by setting \ver@graphicx.sty, and there should be no interference with adjustbox
@UlrikeFischer We are still talking explicitly for testing
@JosephWright Wouldn't be that bad, perhaps. Thank you! Do you know why keyval as class options are not forwarded to packages; is it a general L2e deficiency?
@AlexG the l3 package option code ignores the whole list (as you commented the other day, even dvisvgm is not seen) if the package is using kvoptions from Heiko then it should see them if I recall correctly. If it is using xkeyval I have no idea, if koma or memoir have their own package option code they do what they do if ...
@AlexG we actually "fixed" that in the github version (last year I think) but had push back from koma script maintainer and elsewhere (it broke stuff) so we backed it out, but we do hope to bring back a more generally consistent supported k-v interface at some point...
@AlexG something like "key=value" is passed to packages, but only as string (and after spaces have been removed, and various \edef executed), if the packages then can handle this as keyval depends on their code. Eg\documentclass[pdftitle=blub]{scrreprt}\usepackage{hyperref} does work.
@AlexG check with @JosephWright on the details there:-)
@AlexG whenever this comes up, it comes down to complaining about \zap@space existing, we brought @UlrikeFischer on to the team so we could blame her for that.
@AlexG If you use l3keys2e, it depends which function you choose: I was asked to make use of global options, er, optional!
@AlexG In expl3 itself, I coded a pretty minimal approach: we use \DeclareOption* to pick up things like the driver option. In l3keys2e it was a bit easier as expl3 is loaded ...
@AlexG I'm happy to re-work but I think we need to sort out the whole load-in-the-format business first
@JosephWright The problem with using l3keys2e is that expl3 has been already loaded then. Too late to tell driver options to expl3 again. But you will sort this out, I am convinced ;-).
@AlexG yes it's Ok where it's OK, but when people started doing [foo=\wibble, bb= 1 2 3 4, something= a and b] then passing the whole lot through \zap@space doesn't end well.
@JosephWright ah looks OK actually, I did see some github alert about new template features I think a while back but I didn't look at the details then, perhaps that was related
@AlexG I have a feeling I am their most regular 'customer'
@AlexG Luckily, everything is semi-automated nowadays: it was a lot more work in the days of uploading to Cambridge (I always favoured 'bothering' Robin)
@UlrikeFischer They've been doing it for a long time
@UlrikeFischer did they say what's actually involved?
@UlrikeFischer Probably this is a job that a 'general TeX user' might be good for: doesn't need so much TeX experience, more server experience (@StefanKottwitz ...)
@JosephWright yes, Joachim made a rather long talk about it. But as it was quite clear to me that this is not something for me I didn't try to remember all.
@JosephWright no tex didn't seem to be involved at all. Only server administration.
@UlrikeFischer What I imagined: so it would be sensible to 'advertise'. Is there anything that could be linked to, e.g. from my blog or perhaps the team site?
@JosephWright -- There are a couple of earlier articles by Peter Abbott that may allude to a code archive. (There was definitely an earlier archive of the texhax mailing list.) I just looked at the first article describing the beginning of CTAN, but Aston doesn't seem to be mentioned there.
@JosephWright -- If memory serves correctly, Aston was the first actual code archive. Before that, tapes were available for various architectures for the basic tex distribution from architecture-specific locations, but those contained essentially only what was created at Stanford. (Look up "site reports" in the TUGboat index.) The current TeX Live collection was largely the brainchild of Sebastian, and really did depend on the existence of CTAN.
@barbarabeeton There was also the site at SHSU, but the two soon merged to form CTAN. As far as I remember, I could access the former with Bitnet and our Vax/VMS system, but not Aston until we got linked to the Internet and TCP/IP.
@JosephWright -- One of my "treasures" is a sweatshirt with the Bibby drawing of the UK TeX archive. Quite delightful! (I used to post AMS stuff directly to Cambridge; Robin was most cooperative and patient. A super nice person. If you do get in touch, please give him my best wishes.)
@barbarabeeton Sorry if I'm going off on a tangent here. Some years ago I read a science fiction novel set a few thousand years in the future. In that world, software archaeology was a very useful discipline: If you needed code to solve an uncommon problem, you would contact a software archaelogist. Given a few thousand years of programming, few problems were so weird that nobody had written code for them in all that time. The trick, of course, was to find relevant code.
@HaraldHanche-Olsen -- Oh, that's quite a charming tangent. (I was a devotee of sci fi in high school, to the point where my senior English term paper was a treatise on robotics. At that point, still far in the future, and very different from present reality! Still accepting recommendations on well-written short stories and novels.) It pleases me to think that I may have helped to make software archaeology feasible.
@HenriMenke Regarding my question earlier today: \setupformulas[option=depth] seems to resolve the problem. I don't know if that is the "right" way of doing it, though.
I submitted PGF 3.1.3 to CTAN. I fixed the \scantokens regression in pgfkeys and hopefully worked around the local/global shadings problem. As a new feature pgf-cmykshadings is now part of the core, thanks to @DavidPurton. The pgfparser was extended to pass arguments to rules, thanks to @Skillmon.
@JosephWright I'm pondering about global/local questions. Does it make any sense that \driver_pdf_compresslevel:n sets the variable locally (compared to pdf version)? And what about pdfpagesattr?
@UlrikeFischer We probably need to sort that out ... this is tricky as really the engine should handle this properly (they should be intricately global)
@JosephWright imho yes, but they don't set them globally. I just tried with \pdfpagesattr. And it seemed to have confused Heiko too. In \PDF@SetupDoc he has \pdfpagesattr=, and in a later command there is \global\pdfpageattr.
@UlrikeFischer Currently yes, but I want to change that in the future. Please adjust your code to export the definition out of the group if you really have to set up the shading in a group. To this end I added \pgfutil@pushmacro and \pgfutil@popmacro from ConTeXt. github.com/pgf-tikz/pgf/commit/…