Disable default pygments stylesheet inclusion

[radar]

I am running this command:

bundle exec asciidoctor-epub3 book-highlights.adoc -v -D /Users/ryanbigg/books/rails_book/build/epub -o book.epub -B /Users/ryanbigg/books/rails_book -a generation_date=2020-05-01 -a git_version=f0ebc069d -a pdf-fontsdir=pdf-styles/fonts -a pdf-stylesdir=pdf-styles -a epub3-stylesdir=epub-styles -a pdf-style=book -a icons=font -a pygments-css=class -a pygments-style=dracula -a copycss! -a stylesdir=epub-styles

But what ends up happening is that the default pygments css gets appended to the end of the book's HTML document. This ends up clobbering my own pygments styles because the stylesheet is the final thing in the document.

What attribute do I need to specify to prevent this from happening?

After looking at the code, I've come across this linkcss variable which looks like it might toggle the behaviour that I want... but it is fixed to false.

I want to be able to specify my own pygments stylesheets in the epub-styles stylesheets, and not have the default one included at all.

[slonopotamus]

We have linkcss forced to false because we currently cannot include pygments css as a standalone file.

[radar]

Yeah, I was looking at the code earlier and came to a similar conclusion.

Is there a way to disable that CSS being inserted for ePub books at all?

[mojavelinux]

You can change them. You currently cannot remove them outright. See #43

I am in favor of the request to allow the stylesheets that get loaded / embedded to be customized.

One way to do this would be to honor the stylesheet (or stylesheets) attribute, which could accept a comma-separated list (still relative to epub3-stylesdir).

[mojavelinux]

linkcss doesn't make sense in this context. That's only for the default HTML converter.

[radar]

Maybe I am misunderstanding something here.

What I am talking about is the pygments style sheet that gets appended to the bottom of the HTML file when the ePub is generated. I thought ePub-styles directory was just for the OTHER styling for the ePub, not pygments specifically?

[mojavelinux]

I'm refreshing my memory...

[slonopotamus]

We had pygments-css: style hardcoded from the very beginning of asciidoctor-epub3: 876185b#diff-9f5d719f2acedfb9bfc208ef70b63496R47

Later, in 8e93e26, when I was adding support for other highlighters, I transformed that into a highlighter-agnostic solution via linkcss: false because I needed a way to continue to embed highlighting styles into epub HTML file.

But there wasn't ever a moment in asciidoctor-epub3 history when it supported specifying styles via CSS classes and (using a separate CSS file for those classes or disabling of built-in pygments CSS styles).

[mojavelinux]

First, I want to mention that you can change the built-in Pygments style / theme that is used using -a pygments-style=pastie (or similar).

Marat is correct that this converter has never had support for doing anything other than dumping the CSS from Pygments into chapter HTML file. If being able to replace that with a custom stylesheet is a feature we want, it would have to be designed (from requirements to design to implementation).

[slonopotamus]

I believe that moving highlighter CSS into a separate file and inclusion of custom user CSS after that one would be enough.

If you think there is room for more advanced support, I'm all ears.

[mojavelinux]

Agreed. Instead of embedding the CSS, it should be written to a file in the archive (like epub3-pygments.css or something). But you'd still need to think about how a user might provide the file from a custom location without also having to replace all the other stylesheets too.

[zorro]

@mojavelinux Appending CSS to the end of HTML is causing error on Moon+ Reader app for Android. The app is displaying the stylesheet

[mojavelinux]

@slonopotamus is the person to ping.

[slonopotamus]

@zorro thanks for the report, I'll make sure it renders properly in Moon+ when will be moving highlighter style to separate CSS file.

[slonopotamus]

@mojavelinux I suddenly understood that moving CSS to a separate file is not enough because highlighter CSS file reference is added at the end of HTML body. How do people override highlighter theme when using HTML backend?

[slonopotamus]

Okay, current position of CSS reference is illegal. It was fixed in HTML5 backend in asciidoctor/asciidoctor#3462. We should do the same.

[slonopotamus]

I think I overconfused myself in previous comments. We currently inject syntax highlighter CSS at the end of <head>, not <body>. So everything is fine and this issue can be closed.