Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix headers and footers bug introduced in commit 4b7c6f41e4bda1645eb5… #248

Merged
merged 3 commits into from
Dec 19, 2021

Conversation

ret2src
Copy link
Contributor

@ret2src ret2src commented Jul 15, 2021

Hi,

I think that commit 4b7c6f41e4bda1645eb5b88d9e510348dcf261f3 introduced an unintended side-effect caused by a difference in the syntax of scrlayer-scrpage and fancyhdr.

When building a document with the option oneside set, I still get two different versions of the headers and footers:

image

In my opinion, this should not be the case. Instead, if oneside is set, I should always get the same headers and footers, like this (taken from the version in this pull request):

image

On page 267 of the KOMA-Script manual we can see that scrlayer-scrpage only requires two arguments for plain scrheadings and normal scrheadings, e. g. \ihead*[plain.scrheadings content]{scrheadings content}.

fancyhdr on the other side requires two arguments for even and odd pages, as can be seen on page 45 of the manual:

As you see, if there is an optional parameter, this one applies to the evenpages, whereas the required parameter applies to the odd pages

Previous versions of Eisvogel (i. e. v 2.0.0) had a completely different plain style for headers and footers (a centered page number in a footer without a rule and no header at all):

image

If my suspicions about the author's intentions are correct, we can simply replace the code with two arguments with the star-version - as has been done in this pull request.

By the way - this also has the correct behavior if oneside is not set:

image

@ret2src
Copy link
Contributor Author

ret2src commented Jul 15, 2021

I've just added some additional control over listings when the --listings option is used:

By default, Eisvogel uses the following colorscheme and sets the language to java when the --listings option is used:

image

The first improvement in this pull request lets you set the language to a custom value using the listings-syntax-highlighting-language option, e. g. python (note the color of the comment and some Python-specific keywords):

image

Next, I've introduced variables that let the user change the colors used in listings completely:

image

Additionally, I've added the option listings-disable-font-styling to disable bold and italic font styles in listings:

image

I know this might allow users to create pretty ugly code listings that do not pair well with the overall design of the Eisvogel template.

However, some users might need these options because they have specific requirements. For example, you might be aware of the noraj/OSCP-Exam-Report-Template-Markdown project which makes extensive use of the Eisvogel template. I'm currently using this project to write my report and one of the recommendations by Offensive Security is to highlight commands in blue and important code changes in red. To follow this recommendation, I mix LaTeX with Markdown, set all code listing text colors to black and disable font styling. This allows me to create listings like this:

image

Listings like this allow the reader to instantly grasp important details without being overloaded with styles and colors.

@Wandmalfarbe
Copy link
Owner

Could you split these two distinct changes into two Pull Requests?

For the second change: I prefer if users can't style the listings on their own. However, the option to change the default language from java to something other is very much appreciated. Could you change the name from listings-syntax-highlighting-language to listings-default-language.

@Wandmalfarbe Wandmalfarbe merged commit 1c3ba2c into Wandmalfarbe:master Dec 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants