Support Alternate Themes

[Miserlou]

It is difficult to read a long manuscript with the current style settings.

It might be useful to build on the work of other projects which convert Markdown into the usual academic style:

https://github.com/ickc/markdown-latex-css
https://github.com/thomaspark/pubcss/ // https://thomaspark.co/project/pubcss/demo/acm-sig-sample-web-theme.html
https://gist.github.com/killercup/5917178
etc

[dhimmel]

It is difficult to read a long manuscript with the current style settings.

What exactly do you dislike?

It might be useful to build on the work of other projects which convert Markdown into the usual academic style

Our current github-pandoc.css was based off of this gist.

Regarding the alternatives:

• Markdown Latex CSS looks pretty basic and outdated IMO
• PubCSS seems promising. It looks like it can produce nice HTML pages that when printed take on more a traditional journal article appearance. Would be really interested to see how PubCSS looks for some manuscripts.
• Regarding https://gist.github.com/killercup/5917178, I think I may have tested it. Is likely similar to our current github-pandoc.css. Would need to see evidence that it's better.

Anyways, the frontend stuff is a bit outside my expertise, so we'd need a contributor to take the lead if we wanted alternative viewers. Another longterm option would be to use a JATS XML viewer, such as Lens Viewer (dependent on JATS export in #82). Then the webpage could look like this.

Note that currently the way we generate the PDF is to use WeasyPrint to essentially print the webpage to PDF. Ideally, we want nice HTML and PDF output.

[dhimmel]

If you're looking for the most beefy Manubot manuscripts out there, the following are good options:

• https://github.com/greenelab/scihub-manuscript
• https://github.com/greenelab/deep-review
• https://github.com/dhimmel/rephetio-manuscript (outdated Manubot version)
• https://github.com/dhimmel/bitcoin-whitepaper/ (contains math & code)

If a display style works for these manuscripts, that's good as they are long and have lot's of formatting and complexity.

[michaelmhoffman]

I am trying to make a double-spaced PDF of a manuscript for editing without changing the display on the web for others. @vincerubinetti's suggestion in #169 of setting line-height in build/themes/default.html works. I have two issues, however:

1. There's not an easy way to create e.g. a build/themes/double-spaced.html that inherits any future changes from default.html. Whereas this would be possible if the CSS were split out to a CSS file that could be imported by another CSS file. Please correct me if I'm wrong.
2. I can't select the theme at the command-line from build.sh as it is hardcoded.

[vincerubinetti]

@michaelmhoffman In the future we'll have some easy way to do this, since line spacing is a pretty common variation.

For now though, you can try this:

Create a new theme file build/themes/double-spaced.html and put * { line-height: 2 !important; } in it. Then, inside build.sh, find where the default.html theme is inserted into the outputted html document. Duplicate that line to also include double-spaced.html in the output. That should give you all of the CSS from the default them AND the double space theme.

[michaelmhoffman]

Would you support moving the CSS to build/themes/default.css? I feel like that would allow modular setting of CSS themes separate from the HTML.

[vincerubinetti]

I'm not sure what you mean. If you look at the theme files, they really are just CSS. The only reason we give them the .html extension is because those files also have to include the surrounding <style> </style> tags, because the files are just inserted verbatim into the output html.

In other words, it already is modular. If you add another theme, it's just like adding more CSS. You'll keep the old CSS rules/classes/etc, and add the new ones.

[dhimmel]

I am trying to make a double-spaced PDF of a manuscript for editing without changing the display on the web for others.

@michaelmhoffman is your ideal behavior:

1. The HTML display in-browser stays unchanged, but prints to PDF using double spaced lines. This means every PDF output going forward will use double spacing.

2. A single PDF is created from a single HTML output with double spacing. The goal would be to allow review of one specific version, while keeping future auto-generated PDFs as single spaced?

@vincerubinetti is there a line in default.html that sets the spacing just for the print (i.e. PDF) view? If so and @michaelmhoffman wants option 1, I'd recommend just editing default.html. This will only cause a conflict going forward if the same lines in default.html are edited.

[vincerubinetti]

@vincerubinetti is there a line in default.html that sets the spacing just for the print (i.e. PDF) view?

Yes:

rootstock/build/themes/default.html

Line 502 in 9f16be0

line-height: 1.35;

Unfortunately because of the nature of CSS and fonts, setting line-height to 2 for example really looks more like 1.5 line spacing for most fonts. So you have to just play with that number until it looks like the spacing you want. Double spacing will probably need around line-height: 2.5.

[michaelmhoffman]

If the theme were in a CSS file that we could easily @import from another CSS it would be easy to make a drop-in replacement for default.html that inherits from it. Specifying the theme for build.sh could be done quite easily by setting a THEME_PATH variable within build.sh and replacing any use of build/themes/default.html with "$THEME_PATH". We could then set THEME_PATH either from the environment or from a command-line option to build.sh. As easy change.

The only way to inherit now is to add an additional --include-after-body= in two different places. But you don't want the --include-after-body= if you aren't using a user theme. This is fine (if slightly awkward and DRY-violating) for hard-coding the additional user theme in build.sh, but makes the code quite a bit more complex if you wanted to make the user theme an option a user can transiently set. Which I would find worthwhile as a collaborator on a document where my reviewing preferences are different (double-spaced) for what one would want for the final document (single-spaced).

[dhimmel]

@michaelmhoffman would you have the time to open a PR that does this? It would help us evaluate to see the implementation. You could even create a stub PR with the build.sh changes and then @vincerubinetti and I can do any extra changes to CSS / HTML / documentation that would be necessary.

[michaelmhoffman]

Stub PR would be no problem.