I am trying to write a scientific article using Jupyter Notebook and I am having issues with displaying some characters, such as CO2, which will be shown in this way:
I tried to follow the documentation of Jupyter Notebook for showing formulas and special characters.
This how I've written it:
The NEE decreased significantly with increasing catch crop diversity (Fig. 1), suggesting increasing $$CO_2$$-C uptake from the atmosphere.
Try using the subscript 2 symbol (₂) inside your text, like this:
[…] suggesting increasing CO₂-C uptake from the atmosphere.
you can also use latex $CO_2$ or $\text{CO}_2$ in a markdown cell
Related
When I am writing math equations in a markdown cell of a jupyter notebook, I casually put all of that in $ ... $. Today, I converted an .ipynb file to .tex, and realized most of these equations are converted into messy stuff in the output pdf. For instance, I realized it is converting all '$'s into '$'s.
This is an example of what has happened:
Jupyter Notebook markdown:
$ \nabla ^{2} f(x) = \frac{-1}{(x+1)^{2}} $
Tex Output:
\$ \nabla \^{}\{2\} f(x) = \frac{-1}{(x+1)^{2}} \$
Does anyone have any ideas why this is happening? Is there a better way to write down in-line math equations so that it is more compatible with LaTeX?
If you are eventually going to LaTeX version, the traditional advice is spelled out in minrk's comment from November 8 of 2012:
"The best solution for that right now would be to use 'raw' cells instead of markdown, and just type LaTeX as you would. Then use nbconvert to turn the ipynb to TeX (code, figures and all), and run latex to render that to PDF, etc. You don't get live-rendered TeX in the browser like you do with MathJax / Markdown, but you do still have TeX / code in one document."
The step where you are converting now is probably using nbconvert under the hood even if you aren't directly. (You may be using it directly since you tagged with 'nbconvert`.)
Alternatively, if you are going to LaTeX ultimately, you may want to use a code cell and use the LaTeX magic cell line at the start of that cell. See here and here about %%latex cell magic. (You'll note it is also mentioned among the StackOverflow thread I referenced earlier.) In regards to the %%latex cell magic, I suggest actually consulting the link that leads use in an example notebook in this post because it seems it has to be full-blown LaTeX code and not just simple equations that work easily elsewhere with just dollar signs bracketing them, i.e., MathJax.
I tried that option with your equation and when I output the notebook as LaTeX, I didn't see additional backslashes added. (I didn't however actually try rendering the LaTeX, and so I cannot address if all the cruft/boilerplate that Jupyter is adding causes any issues for downstream useability.)
I'm writing a slide deck using the Jupyter notebook and compiling it to slides using jupyter nbconvert FILENAME.ipynb --to=slides, which uses Reveal.js (if I understand correctly). I'm consequently writing the slide content in Markdown.
I'd like to have a slide with two columns, if possible. I cannot seem to make this work. Here is what I have tried:
The splitcell notebook extension suggested here. This does not work because (I think) it's for RISE, and I'm using Reveal.js. By "does not work" I mean that the split cells are treated as if I had not split them; it seems to have no effect.
The CSS suggestions suggested in many responses to this question. While several of the answers to that question successfully let me create two columns, none lets me use Markdown inside the columns, even though several of them explicitly say that they do. I have tried obeying all the suggestions in the comments as well, including blank lines and data-markdown. Perhaps those solutions work correctly when compiling from Markdown to slides through Reveal.js, but something is different about jupyter nbconvert?
The contributed notebook extension Split Cells (repo on GitHub) does exactly this.
This blog post shows Split Cells in action.
ggplot(data=NULL,aes(x=1,y=1))+
geom_text(size=10,label="ক্ত", family="Kohinoor Bangla")
On my machine, the Bengali conjunct cluster "ক্ত" is rendered as its constituents plus a virana:
I have tried several different fonts to no avail. Is there a trick to making conjuncts render correctly?
EDIT:
Explicitly using the unicode still doesn't not render correctly:
This renders correctly for me:
print(stringi::stri_enc_toutf8("\u0995\u09cd\u09a4"))
This still gives me the exact same result as before
ggplot(data=NULL,aes(x=1,y=1))+
geom_text(size=10,label="\u0995\u09cd\u09a4", family="Kohinoor Bangla")
Why is there a difference between the console output and ggplot output?
I'm not familiar with the Bengali language, but if you would look up the unicode characters for the text that you want to render, you could simply use those in geom_text()
# According to unicode code chart, these are some Bengali characters
# U+099x4
# U+09Ex3
ggplot(data=NULL,aes(x=1,y=1))+
# Substitute 'U+' by '\u', leave the 'x' out
geom_text(size = 10, label = "\u0994\u09E3")
Substitute the unicode characters as you see fit.
Hope that helped!
EDIT: I tried your last piece of code, which gave me a warning about the font not being installed. So I ran it without the family = "Kohinoor Bangla":
ggplot(data=NULL,aes(x=1,y=1))+
geom_text(size=10,label="\u0995\u09cd\u09a4")
Which gave me the following output:
From a visual comparison with the character that you posted, it looks quite similar. Next, I ran the same piece of code on my work computer, which gave me the following output:
The difference between work and home, is that work runs on a linux, while home runs on windows, work has R 3.4.4, home has R 3.5.3. Both are in RStudio, both are ggplot 3.2.0. I can't update R on work because of backwards compatibility issues, to check wether the version of R might be the problem. However, you could check wether your version of R is older than 3.5.3 and see if updating relieves the problem. Otherwise, I would guess it is a platform issue.
On some computers, the following code used in conjunction with the packages siar and SIBER does not render the delta and/or permil symbol correctly in the axes labels. Instead, either a blank axis label, or text such as "\u2030" is rendered in its place.
plot(0,xlab = expression(paste(delta^13,"C (\u2030)")))
One often encountered problem is that your computer's region settings (i.e. your operating system, not the applications R or Rstudio) is set to use a non-UTF8 character set. If you type
Sys.setlocale()
in the R command window, you should see something like
"en_IE.UTF-8/en_IE.UTF-8/en_IE.UTF-8/C/en_IE.UTF-8/en_IE.UTF-8"
which for me means I'm using UTF-8 in english with Irish region settings.
If you don't see UTF-8 then the \u2030 and other character codes won't work
I am using the effects package in R to derive (and plot) the effects of a complicated linear model.
When I use allEffects(linearModel) I can see the results on screen and save it to a pdf file as usual. Since the model has many terms, the output is not useful as it stands.
Therefore I use effects(someTerm, linearModel) to focus on the terms of interest and the results on screen are what I need. However, when saving it to a pdf file, the file contains no useful output (though it does take up 3.5Kb of space). There is no error message from R at the console.
To ease understanding, I created a simple data set and a script for generating the effects plots, in the same way that I tried with the "real" model.
factorData.csv
A,B,C,y
a1,b1,c1,3
a1,b2,c1,4
a2,b1,c1,5
a2,b2,c1,6
a1,b1,c1,2
a1,b1,c2,3.5
a1,b2,c2,4
a2,b1,c2,5.1
a2,b2,c2,6.2
plotEffect.r
require(effects)
dataFile <- '/tmp/factorData.csv'
effectABfile <- '/tmp/effect_AB.pdf'
effectABCfile <- '/tmp/effect_ABC.pdf'
allEffectFile <- '/tmp/lm_eff.pdf'
df <- read.csv(file=dataFile,header=TRUE,sep=',')
linearModel <- lm(y~A*B*C,data=df)
lm_eff <- allEffects(linearModel)
pdf(file=effectABfile)
plot(effect('A:B',linearModel))
dev.off()
pdf(file=allEffectFile)
plot(lm_eff)
dev.off()
pdf(file=effectABCfile)
plot(Effect(c('A','B','C'),linearModel))
dev.off()
As you can see, I tried allEffects, effect and Effect; allEffects is the only one that works for me. Please note that the script assumes that the data is placed in /tmp/factorData.csv - you might need to change the path of course. I also randomised the order in which the plots are generated, with no effect.
I had a look elsewhere on stackoverflow and saving plots to pdfs fails was the closest but the advice there (to issue dev.off() after each plot to 'close' the pdf file) is something I do already, as seen in plotEffect.r.
I tried this script on 2 machines, each running Lubuntu 14.04.1 64-bit with R version 3.0.2 and the latest effects package installed within R using install.packages. The results were the same.
I would be very grateful for advice on how to fix the problem of saving (instances of) this plot type to a pdf.
Fix/workaround
As suggested by #Roland in the comments below, if you wish to save grid plots (such as the output from the effects plots in this instance) into pdf files, it is better/more reliable to generate the plots separately/manually (rather than in a script). It does not appear to be (as much of) an issue for base graphics or even ggplot2 graphics, where I for one have never encountered this problem/needed this workaround in the past. Thanks to #Roland for suggesting this fix!
#Roland also added that Sys.sleep() might help in scripts. Although it did not do so in my case, I discovered that it was possible to paste several such plotting commands and R would run them as a batch, saving the plots to pdf correctly. Therefore, I believe it should be possible to recover much of the benefits of running the script by taking these steps:
Use R to create the text representation of the pdf(), plot() and dev.off() triad of commands
The main script outputs this plotting command text (specific to each instance of a plot) to a file
Open the plotting command text in a text editor
Copy the entire contents of the commands file and paste it into the R console
Optionally, you may wish to use the command line in Step 3 and 4 - How can I load a file's contents into the clipboard? has useful advice.
This two stage procedure is a reasonable workaround, but arguably there should be no need for it.