Load graphicx without specifying the driver. #1

jfbu · 2015-12-30T09:18:17Z

On the current main TeX installations (TeXLive, MikTeX), \pdftexversion is defined also when running latex to produce dvi files. This commit deletes TeX code which resulted in the "pdftex" driver being always assumed, which made it a priori impossible to compile via latex.

The graphicx packages is smart enough to detect correctly the driver (pdftex, xetex, ...) and defaults to dvips.

This is issue sphinx-doc#2164. On the current main TeX installations (TeXLive, MikTeX), \pdftexversion is defined also when running latex to produce dvi files. This commit deletes TeX code which resulted in the "pdftex" driver being always assumed, which made it a priori impossible to compile via latex. The graphicx packages is smart enough to detect correctly the driver (pdftex, xetex, ...) and defaults to dvips.

@list

Allow code-blocks at maximal nesting depth of lists/quotes in LaTeX (which by default is 6), by patching fancyvrb's original Verbatim way of checking list depth which resulted in a loss of 1 possible level. Memo 1: latex can have by default a maximum of 4 nested enumerated lists, 4 nested labeled lists, and in total 6 nested lists. This includes quoted blocks as they use the `\list` macro. Memo 2: fancyvrb's rationale for using the \@list... macros (in its \FV@ListNesting) is to set vertical positioning. To set a Verbatim at level N it uses vertical parameters for list level N+1, hence can't work at max level. But in Sphinx, this happens inside a \vbox for framing, hence the vertical positioning set by fancyvrb turns out to be inoperant anyhow. The execution of \@list<level> also sets the \leftmargin, but fancyvrb resets it to zero later (#1=\z@ in \FV@ListNesting). To sum up, fancyvrb's \FV@ListNesting does nothing but has the after effect to raise an error if the code-block is at level equal to max - 1. The effect of this commit is to make inoperant fancyvrb's check of nesting depth, hence now the code-block can appear at maximal depth. This is second commit improving in Sphinx the maximal depth for code-blocks in nested lists or quote blocks. It used to be 4 (with LaTeX's defaults for lists), it is now at 6 (or at the max depth allowed by the document class).

C++, allow arbitrary initializer for variable concepts.

This goes for the quick solution, hence uses the pre-existing architecture underlying the `\PYG` macro from the Pygments highlighting code. Each domain can add its own style to LaTeX by defining suitable macro for supporting css styles. For example, here we added \@namedef{PYG@tok@k-cpp}{% \def\PYG@tc##1{\textcolor[RGB]{0,0,"FF}{##1}}% }% to sphinx.sty to emulate the CSS code.k-cpp { color: #0000FF; } (previous commit uses `#0000AA` but I chose `#0000FF` for better seeing things...) For a fully developed example all the `\@namedef` would be in some `sphinxcpp.sty` style file and either the document will do `\usepackage{sphinxcpp.sty}` or `sphinx.sty` will do `\RequirePackage{sphinxcpp.sty}`. The user could override this file via `latex_additional_files`. In absence of such file, the macro definitions will be lacking but this will raise no error. For the example here (from last commit message) the latex output contains \PYG{d+k+k-cpp} and the `\PYG` macro nests "action of d(of k(of k-cpp...)))". Turns out that Pygments already has some macro for "k", which uses bold face (as can be seen in PDF output) and changes the text color, but has "k-cpp" is deeper nested it is executed last and sets the good text color. Thus it would perhaps be better if the latex writer produces something like \PYG{cssd+cssk+cssk-cpp} to avoid name clashes with Pygments pre-defined styles. Or here it is OK that "k" is styled boldface by Pygments in LaTeX. Important: class names must not contain the `+` character which is use by Pygments LaTeX code as separator. There are some issues in the Pygments code with the scope of some changes; this is already corrected by Sphinx (refs: sphinx-doc#4250), but some more scrutiny is perhaps needed because so far the Pygments code is exercised only inside Verbatim environments where each code-line is a scope in itself so border effects do not propagate, hence I have not checked closely the Pygments LaTeX code, but perhaps sphinx-doc#4250 fixes already all problems.

This goes for the quick solution, hence uses the pre-existing architecture underlying the `\PYG` macro from the Pygments highlighting code. Each domain can add its own style to LaTeX by defining suitable macro for supporting css styles. For example, here we added \@namedef{PYG@tok@k-cpp}{% \def\PYG@tc##1{\textcolor[RGB]{0,0,"FF}{##1}}% }% to sphinx.sty to emulate the CSS code.k-cpp { color: #0000FF; } (previous commit uses `#0000AA` but I chose `#0000FF` for better seeing things... also syntax `\textcolor[HTML]{0000FF}` is possible)) For a fully developed example all the `\@namedef` would be in some `sphinxcpp.sty` style file and either the document will do `\usepackage{sphinxcpp}` or `sphinx.sty` will do `\RequirePackage{sphinxcpp}`. The user could override this file via `latex_additional_files`. In absence of such file, the macro definitions will be lacking but this will raise no error. For the example here (from last commit message) the latex output contains \PYG{d+k+k-cpp} and the `\PYG` macro nests "action of d(of k(of k-cpp...)))". Turns out that Pygments already has some macro for "k", which uses bold face (as can be seen in PDF output) and changes the text color, but as "k-cpp" is deeper nested it is executed last and sets the good text color. Thus it would perhaps be better if the latex writer produced something like \PYG{cssd+cssk+cssk-cpp} to avoid name clashes with Pygments pre-defined styles. Or here it is OK that "k" is styled boldface by Pygments in LaTeX. Important: class names must not contain the `+` character which is used by Pygments LaTeX code as separator. There are some issues in the Pygments code with the scope of some changes; this is already corrected by Sphinx (refs: sphinx-doc#4250), but some more scrutiny is perhaps needed because so far the Pygments code is exercised only inside Verbatim environments where each code-line is a scope in itself so border effects do not propagate, hence I have not checked closely the Pygments LaTeX code, but perhaps sphinx-doc#4250 fixes already all problems.

This goes for the quick solution, hence uses the pre-existing architecture underlying the `\PYG` macro from the Pygments highlighting code. Each domain can add its own style to LaTeX by defining suitable macro for supporting css styles. For example, here we added \@namedef{PYG@tok@k-cpp}{% \def\PYG@tc##1{\textcolor[RGB]{0,0,"FF}{##1}}% }% to sphinx.sty to emulate the CSS code.k-cpp { color: #0000FF; } (previous commit uses `#0000AA` but I chose `#0000FF` for better seeing things... also syntax `\textcolor[HTML]{0000FF}` is possible)) For a fully developed example all the `\@namedef` would be in some `sphinxcpp.sty` style file and either the document will do `\usepackage{sphinxcpp}` or `sphinx.sty` will do `\RequirePackage{sphinxcpp}`. The user could override this file via `latex_additional_files`. In absence of such file, the macro definitions will be lacking but this will raise no error. For the example here (from last commit message) the latex output contains \PYG{d+k+k-cpp}{\sphinxcode{template}} The `\PYG` macro first does preparation for the styling in the order "d" then "k" then "k-cpp", the last one can override any preliminary config. Turns out that Pygments Sphinx latex style has no pre-defined "d" style but it has one for "k", which activates bold face and sets the text to a certain color. As "k-cpp" comes last it will set the blue color. It would perhaps be better if the latex writer produced something like \PYG{cssd+cssk+cssk-cpp} to avoid name clashes with Pygments pre-defined styles. Or here it is OK that "k" is styled boldface by Pygments in LaTeX. (to be examined more) - The `\sphinxcode` main role is to switch to monospace font (`\texttt`), and it does things to allow wrapping long inline literal and prevent some TeX ligatures and make quotes straight. Certainly this `\sphinxcode` should be removed here, else `\texttt` will always be there and win. We can't move `\sphinxcode` to outer level, because it makes the `-` active, which is for "k-cpp" class name.. - We could thus remove the `\sphinxcode` and do rather \@namedef{PYG@tok@d}{\def\PYG@ff##1{\texttt{##1}}}% Then it can be modified by other classes, as the "d" gets executed first. If the other classes to not modify the font family, the `\texttt` will have effect. - class names must not contain the `+` character which is used by Pygments LaTeX code as separator. But as `+` must be escaped in CSS classes/selectors names, this is probably not much of a worry here.

…te`` Since sphinx-doc#2627 (1.4.4), `\code`, and then again at sphinx-doc#3116 (1.5) `\sphinxcode` which is the new name has become more complicated than the original `\texttt{#1}`. This was to obtain straight codes in PDF output, and to allow long inline literals to break across lineswq. This means though that user who wants to customize `\sphinxcode`, for example to not only do `\texttt` but to use some colour, has to copy about 10 lines of complicated LaTeX macros with @ letter. This moves all the code out of `\sphinxcode` into new macro `\sphinxupquote`. The LaTeX files will contain `\sphinxcode{\sphinxupquote{foo}}` in place of former `\sphinxcode{foo}`. Moving the `\texttt` from innermost to outermost level is with no consequence.

…te`` Since sphinx-doc#2627 (1.4.4), `\code`, and then again at sphinx-doc#3116 (1.5) `\sphinxcode` which is the new name has become more complicated than the original `\texttt{#1}`. This was to obtain straight quotes in PDF output, and to allow long inline literals to break across lines. This means though that users who want to customize `\sphinxcode`, for example to not only do `\texttt` but to use some colour, have to copy about 10 lines of complicated LaTeX macros which should be not modified in any way. This commit moves all the code out of `\sphinxcode` into a separate macro `\sphinxupquote`. The LaTeX writer will output `\sphinxcode{\sphinxupquote{foo}}` in place of former `\sphinxcode{foo}`. Moving the `\texttt` from innermost to outermost level is with no consequence.

This goes for the quick solution, hence uses the pre-existing architecture underlying the `\PYG` macro from the Pygments highlighting code. Each domain can add its own style to LaTeX by defining suitable macro for supporting css styles. For example, here we added \@namedef{PYG@tok@k-cpp}{% \def\PYG@tc##1{\textcolor[HTML]{0000FF}{##1}}% }% to sphinx.sty to emulate the CSS code.k-cpp { color: #0000FF; } (previous commit uses `0000AA` for html output but I chose `0000FF` for latex output in this proof of concept... ) For a fully developed example all the `\@namedef` would be in some `sphinxcpp.sty` style file and either the document will do `\usepackage{sphinxcpp}` or `sphinx.sty` will do `\RequirePackage{sphinxcpp}`. The user could override this file via `latex_additional_files`. In absence of such file, the macro definitions will be lacking but this will raise no error. For the example here (from last commit message) the latex output contains \PYG{d+k+k-cpp}{\sphinxupquote{template}} The `\PYG` macro first does preparation for the styling in the order "d" then "k" then "k-cpp", the last one can override any preliminary config. Turns out that Pygments Sphinx latex style has no pre-defined "d" style but it has one for "k", which activates bold face and sets the text to a certain color. As "k-cpp" comes last it will set the blue color. It would perhaps be better if the latex writer produced something like \PYG{cssd+cssk+cssk-cpp} to avoid name clashes with Pygments pre-defined styles. Or here it is OK that "k" is styled boldface by Pygments in LaTeX. (to be examined more) - The merged master branch has refactored the `\sphinxcode` to only do `\texttt`. The fancy stuff about getting straight quotes was moved to `\sphinxupquote` and this is why `\sphinxupquote` macro appears in the LaTeX macros output from latex.visit_desc_element(). - There is no `\sphinxcode` in latex.visit_desc_element(), because its use was moved into the `\PYG@tok@d` styling macro. \@namedef{PYG@tok@d}{% \def\PYG@ff##1{\sphinxcode{##1}}% default \sphinxcode is \texttt }% - Class names must not contain the `+` character which is used by Pygments LaTeX code as separator. But as `+` must be escaped in CSS classes/selectors names, this is probably not much of a worry here.

Fix sphinx-doc#4019: exception treatment for NoneType group attribute.

jfbu closed this Dec 30, 2015

jfbu deleted the jfbu-patch-1 branch December 30, 2015 09:30

jfbu pushed a commit that referenced this pull request Aug 30, 2016

Merge pull request #1 from mickk-on-cpp/cpp-concepts

494aeb9

C++, allow arbitrary initializer for variable concepts.

jfbu pushed a commit that referenced this pull request Feb 21, 2018

Merge pull request #1 from dpizetta/bug-objname-nonetype

953a303

Fix sphinx-doc#4019: exception treatment for NoneType group attribute.

github-actions bot locked as resolved and limited conversation to collaborators Jul 15, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Load graphicx without specifying the driver. #1

Load graphicx without specifying the driver. #1

jfbu commented Dec 30, 2015

Load graphicx without specifying the driver. #1

Load graphicx without specifying the driver. #1

Conversation

jfbu commented Dec 30, 2015