The Geshi rendered output has a font-size of 10px where we would expect
13px just like for <pre>.
Bug 33496 against MediaWiki core dealt with that issue already: in some
(all?) browser 'monospace' has a size of 13px where as the default is
16px. When defining a font-size of 0.8em the monospace is scaled down to
10 px which is too small. By appending another font statement, the
browser treat monospace as a default font and thus scale it starting
with 16px instead of 13px.
This patch append a style to geshi which set the font-family to
"monospace, monospace" thus tricking the browser in considering
monospace a regular font.
Change-Id: I7bbdcc0a21010513473a7ca9d784df77e9920b5b
This can happen if the TitleIsCssOrJsPage hook causes a page without a
.css or .js extension to be considered a CSS/JS page.
Change-Id: I875a7f89f683336f18e70358fe589cef706fd5d1
Remove usage of mw-code-inline:
* That class ended up not being merged into core, so it does nothing.
Only mw-code (for the <pre> wrap) is needed.
7c9b2273c9cbdae90c9f4e3890a13619f769c5d0 (mediawiki/core) had both
in an earlier patch version, but only mw-code was merged.
Follows-up:
* mediawiki/extensions/SyntaxHighlight_GeSHi:
dc147a5ef1
Use .mw-code and .mw-code-inline
* mediawiki/core
7c9b2273c9cbdae90c9f4e3890a13619f769c5d0
Add .mw-code styles in core
Change-Id: I793c05c3e103209cf966d9e35ab37c05528cdbb8
Also make sure mw-content-ltr/rtl is the same as the dir attribute value. Restrict that value to either ltr or rtl (not sure if rtl really needed; source code is always ltr). Also remove text-align:left; as it can/should be set manually in the <source> tag.
Tidy always converts tabs to spaces on input; on a big <pre> section this is ok but it tends to fail on syntax-highlighted output, where the spacing should depend on the *output* not the *input markup*.
As a workaround, when $wgUseTidy is enabled we now apply our own tab-to-space conversion preemptively on the input before feeding it into GeSHi for highlighting; this keeps the right spacing through to output.
* Support for the new GESHI_HEADER_PRE_VALID in geshi 1.0.8
* Strict Standards: Non-static method SyntaxHighlight_GeSHi::validHighlightRange() should not be called statically
* Break input validation out to a function so it doesn't mush up main program flow readability
* Reduce denial of service attack area by imposing an arbitrary limit on the size of line ranges
* Reject 0 as a valid input line
Some further notes:
* Currently, the line numbers given for highlighting seem to ignore the 'start' line number provided for displaying line numbers. This is IMHO a bit confusing; it might be better to add the start line number in so you can specify line numbers which match what will be displayed.
* You can specify line numbers after the end of the document without complaint. It might be better to count the lines and ignore any additional ones.
