Sorry, I should have clarified.
It’s not really the theme’s fault, however if it wants, it could fix the issue. But for that matter, so could my plugin. The issue just lies in tracking down what the problem is.
The theme has some styling rules (CSS) to make things look how it wants. That’s normal, however SyntaxHighlighter (the highlighting library, not my plugin) gets affected by those global rules just due to how CSS works.
SyntaxHighlighter attempts to override any and all rules that would affect its own rendering by defining values for all of its own properties. For example the theme could say that content text should be red and very large and SyntaxHighlighter will override that within its code blocks to be the font size and color it needs to look right.
Unfortunately SyntaxHighlighter can’t account for every single possible formatting rule that could affect it. It tries to just cover the majority of rules that could affect it:
https://github.com/Viper007Bond/syntaxhighlighter/blob/master/syntaxhighlighter3/styles/shCore.css
https://github.com/Viper007Bond/syntaxhighlighter/blob/master/syntaxhighlighter3/styles/shThemeDefault.css
The theme you’re using is doing something that SyntaxHighlighter didn’t account for.
The solution is one of two things:
A) SyntaxHighlighter adds a new rule to override what your theme is doing, but as I said it’s not really possible for SyntaxHighlighter to cover every possible issue. The list would get very, very long, especially trying to accommodate every theme out there.
B) The theme adds some rules to specifically fix SyntaxHighlighter when used with the theme. This is kind of the reverse issue — why should a theme try to accommodate every single plugin out there?
I’m not sure what the right answer is, especially since I’m not the author of the SyntaxHighlighter highlighting library, only the WordPress plugin that makes it significantly easier to use.