Closed dbaynard closed 5 years ago
Excellent! Thanks for doing this. I'll see about updating epub.css.
Hm, epub.css doesn't contain anything relevant. I can confirm that the highlighting doesn't work well in iBooks, but it's not completely gone: I still get boldface, just no colors. Haven't been able to figure out why, but all the relevant styles are embedded in the HTML chapter itself...
OK, I may have been mistaken. When I change the appearance of the EPUB so that a lighter background is used (using iTune menu options), the colors show up.
Code doesn't wrap, though -- shouldn't it?
To answer my own question: no, it never wrapped before.
It didn't, but I think it should?
Also I couldn't get the line numbers to appear in the epub. I think I may need to reintroduce the data-line-number for epub. I don't quite have a suitable testing setup; I've been using Google play books which is a bit of a pain in this case.
The line numbers do appear in iBooks, so maybe this is a problem in Google play books.
As for wrapping: this gets requested from time to time. The main argument against it is that wrapping code can produce (what looks visually like) code that isn't semantically equivalent, or that is syntactically incorrect. So it's better for authors to ensure that code is hard-wrapped to a width that will be adequate when displayed. Counterargument: it's really hard to know what sort of a device will be displaying the code. I don't feel super-strongly about it. Maybe it would be good to make it an option, controllable via CSS that the user could add?
PS. There is code in the current CSS that seems intended to work with wrapping, so I wasn't sure what you intended.
By default, in print CSS, code wraps. With line numbers, it is clear which is a new line. Without line numbers it isn't. There may be a solution, with continuation characters. I'll fix the starting number issue first, then put together an example for you.
The main argument against it is that wrapping code can produce (what looks visually like) code that isn't semantically equivalent, or that is syntactically incorrect.
Incidentally, I agree on this. I suspect using continuation characters to indicate that a line wraps will clarify this. I'll check out the details, tomorrow, and implement something in the print css, if it isn't too complicated.
Maybe it would be good to make it an option, controllable via CSS that the user could add?
I suspect it would be helpful for me to write some guidelines to the default css, and how users might wish to amend it.
Fixes jgm/pandoc#4386. Also fixes #33 (and therefore fixes jgm/pandoc#4278).
As it stands, it doesn't seem to work in epub. I suspect there are changes that need to go in
data/epub.css
(as per #32).