I am attempting to compile parts of the most to update version of the Tikz-PGF manual (3.0.1a) :
Find the files here
While trying to compile the first tutorial: A Picture for Karl's Students, I ran into some errors:
I don't know what the error message is about. The macros I imported from the...
Can someone answer this question and explain step by step how to compile the old manuals in the event that the old manuals are no longer available online?
@TorbjørnT. Thank you, I just looked and it seems that the archived versions are not classified by pgf version (version 1; version 1.18; version 2; version 3, etc) which complicates the task considerably.
@AndréC It's not that many, just download all of them, open them one by one to find the version number, then rename the file. A bit tedious, but not very complicated ...
@AndréC These are the TeX Live checkins. But if you want the old sources you can get there by looking at github.com/pgf-tikz/pgf/releases which will also show you the dates of old releases so you can identify which TeX Live checkin is right for you.
@TorbjørnT. @TeXnician The task being tedious, it seems to me that a centralized archive where to keep old manuals is much more convenient and will consume far fewer resources unnecessarily (less electrical energy consumed, etc).
@AndréC You could ask the same question of any LaTeX package, or more widely any piece of software. That's where version control comes in, but as the manual is a derived file, it's not one that's usually kept
@AndréC I have to ask why you need an old manual unless you have an old installation for it to go with
@AndréC Why should one bloat any server with PDFs easily reproducible from sources? It's just a matter of compiling a document. And as the casual user will only need the version he has installed (using texdoc is easy there), this is definitely a rare activity.
@JosephWright I explained it in the application on the pgf github repository. This is because the latest manuals use operations that are only documented in the old manuals. These operations are still functional and often very useful, but they are no longer documented. We are forced to read the old manuals to understand the code. github.com/pgf-tikz/pgf/issues?q=is%3Aissue+is%3Aclosed
@AndréC The pre=moveto is documented in the current manual (p. 371, /pgf/decoration/pre), -to is used on p. 61 but you are right that if this is used in the manual it could be documented.
@AndréC The question you link to is absolutely unclear to me. The user tries to compile a single part of the manual. If you want to get the full manual cd into the version-for-xyztex/en folder and run make. That's easy enough, I guess.
@TorbjørnT. According to what Henri says here, compiling an old manual requires installing the corresponding version of pgf, so in this case, how do you do it in practice? github.com/pgf-tikz/pgf/issues/903#issuecomment-667637618.
@AndréC You can check out the commit from the git repository. They are tagged by version so that you can get it easily. Installing can be done using auxtree from TeX Live (or something similar MikTeX has).
@TeXnician This user tried to compile parts of it since the manual is written in several files, so it seems reasonable to start by trying to compile a single file corresponding to a single part before trying to compile a multitude of files and put them together.
@TeXnician According to what Henri says here, compiling an old manual requires installing the corresponding version of pgf, so in this case, how do you do it in practice? github.com/pgf-tikz/pgf/issues/903#issuecomment-667637618
@AndréC Really? I usually write documents in multiple parts using \include. I would never even try to compile a single part because there are simply all the packages etc. missing which I would have to rebuild. Compiling the whole document will work.
@AndréC I have explained it in the comment you answered to. Check out the tagged commit, configure the auxtree and then run the make command.
@AndréC As I said, compiling the manual is easy. Compiling arbitrary parts not meant for standalone compilation is not. For me, this question you always link to is unclear in terms of what the OP actually wants. Sorry, but if you want this partial compilation you will have to find someone else who knows more about what the PGFmanual's preamble looks like and what has to be adjusted to compile single parts.
@TeXnician Since this is easy for you, will you answer a question (which I will ask) on the main site asking how to compile manuals 1.01; 1.18; 2.10 and 3.0.1a?
My request to archive old TikZ manuals was closed on the grounds that it is sufficient to compile these manuals with the corresponding version of pgf.
Archive old manuals? #903
It is specified that to do this, it is necessary to compile with the corresponding version of pgf.
How do you go about c...
@TeXnician I tried it once (one or two year ago imho) to help Henry debug some problem and didn't find it easy. There are scripts involved as the manual is compiled in various formats and I remember that it took me quite some time to figure it out.
@UlrikeFischer Yes, there are some scripts involved but actually only running a Makefile is necessary for compiling the manual. I don't know about MikTeX though (see my answer which only runs on TeX Live).
@AndréC I tried (just to waste a bit of time) with version 1.0 but I decided to stop --- it even look for pdfelatex ;-), which was probably ok in 2005...
@UlrikeFischer That's probably right. Well, one could argue in favour of WSL today but as a long-time linux user I'm probably biased in terms of my understanding of easy and scripting.
Anyway, I think this is an XY problem. If something is not described in the manual I think there are two possibilities: 1) the thing is deprecated, or internal, so don't use it; 2) you can open an issue asking o add it to the manual, which is the correct way on. At least this is my policy with the packages I manage.
@Rmano Yes, for the old versions you need old distributions.
@Rmano As I mentioned above to AndreC: “The pre=moveto is documented in the current manual (p. 371, /pgf/decoration/pre), -to is used on p. 61 but you are right that if this is used in the manual it could be documented.” so probably 2 would be the best way…
@UlrikeFischer I tried on Linux with a bit of TEXINPUTS magic but it failed to build --- I really think this is archeosoftwaring (!) so just for fun. And in small doses... ;-)
@AndréC @Rmano I've made a pull request to pgf, which replaces those two usages of deprecated arrow tips "to" with ">" in tutorial sections of pgfmanual. See github.com/pgf-tikz/pgf/pull/905.
Is it okay to use {a \choose b} instead of \binom{a}{b} in LaTeX? I have to use the iopart class, which is not compatible with amsmath and has iopams as a workaround. But \binom is not provided.
:-(
I remember being told to avoid \choose but I do not know the reason.
It's a good idea, but keeping the documentation of this will allow all beginners to understand the old TikZ code that is lying around everywhere, here and there on the net ...
@Szabolcs You can define \binom yourself with \DeclareRobustCommand\binom[2]{{\begingroup #1\endgroup \choose #2}}. Using \choose directly can sometimes lead to issues because of the missing grouping, is inconsistent and makes your document harder to port to other engines.
@muzimuzhiZ It's a good idea, but keeping the documentation of this will allow all beginners to understand the old TikZ code that is lying around everywhere, here and there on the net ...
@Szabolcs To be as compatible with the amsmath definition as possible which doesn't separatly group that either. Of course this leads to the question why amsmath is doing it: There is simply no need. The {...}-group around the whole construct already provides grouping. #1 gets separate grouping to avoid leaking stuff into #2, but there is nothing after #2 which could be affected by #2, so we can save a tiny little bit of time and memory by avoiding it.
@AndréC It's simple to provide a one- or two-page doc introducing functionality of deprecated libraries "arrows" and "arrows.spaced", but for pgfmanual maybe their use should be restricted, at least not at tutorial sections.
Yes, I know the documentation for the old code is commented out and not deleted. Indeed, I have already asked Henri to put this documentation back in recent manuals. He refused out of respect for Till Tantau's decision to remove them: he does not want to go against Till Tantau's decision. So, yes, a side document that documents old code is a great idea, but it's a lot of work!
@AndréC I will have a try. Which form is more preferable, a pdf file (uploaded to CTAN or not) or a github url (for example, a markdown file including several svg images)? Personally I slightly prefer the latter one. It is lighter.
@muzimuzhiZ I agree with you, Github seems preferable to me because it will be easier to report obsolete code recently found, which works and which is not documented, etc.
Is there an alternative to \autoref that allows me to put a link on the entire text of figure 4 instead of just on 4? I am happy to type out figure myself. I've been fighting with autoref for half an hour now and I cannot get it to do what I want.
@Szabolcs autoref is rather simple. Its main feature is that it can detect the counter type, but there isn't much formatting option. You can redefine \figureautorefname to get another prefix, but it won't adapt e.g. to the begin of sentences. For more complicated stuff I use zref.
Thanks to both! I ended up defining \newcommand*{\myref}[2]{\hyperref[#2]{#1~\ref{#2}}} and using that with manually typed labels, as the journal discourages too many packages. (I know they'll reformat everything anyway, but I want the arXiv version to be pretty.) I'll check out cref and zref for my personal documents.
@AndréC I think the OP has made the example minimal enough. They're a new user, so asking them to remove a couple of tikz libraries, and one package isn't particularly welcoming. tex.stackexchange.com/questions/557101/…
@AlanMunn I don't agree, learning how to do an MWE is not complicated and is a standard procedure with LaTeX. Especially since the first/style, second/style and third/.style styles are useless. Differentiating between useful and unnecessary must be learned from the start. The right reflexes must be acquired at the earliest, in my humble opinion.
@AndréC This is about how to treat brand new users. In this case, asking for the example to be more minimal makes no difference in your ability to answer the question. If you think that part of the code is useless add an answer and explain why. But if it's useless just because it's not part of the code being asked about, then it's irrelevant to mention its usefulness at all.
LaTeX is inherently difficult, and simplifying code is much easier than writing code. Just comment out a line and see if that changes the result or generates an error. In my opinion asking a LaTeX user to do an MWE is like asking Usain Bolt to walk on foot, if I may allow that metaphor. It's a lot easier than writing LaTeX code.
@JosephWright , @UlrikeFischer Oh, not yet. Thanks for notifying me. There is also a bug pending in the repo. I will have to take a closer look at this whole issue. First tests have shown, that AR just uses the Windows video player instead of Flash if one consents to do so.
some screenshots of the related tables in the PDF ISO spec would help a lot.
@AlexG Sometimes it can useful to ask your favorite search engine if the PDF Association has made a copy of one of the final drafts public. I would suggest a searchterm like site:pdfa.org filetype:pdf "ISO/DIS 32000-2".
@PauloCereda -- Yes, we'd seen it. But this year we owed, so sent in our check, but the state tried to return it to us. What confusion! There have been good elected officials in the state, but not for a while, unfortunately. But we keep hoping and voting.
@JosephWright is there a particular reason I don't understand why in l3keys.dtx line 1608 there is no test for an empty \l__keys_module_str whereas on line 1601 there is? Also line 1618 does \str_set:Nx \l_keys_path_str { \l_keys_path_str }...