Why does save_kable command of the kableExtra package results in bad resolution PDF? I have observed that when a PDF is rendered with magick(which is standard in kableExtra) the quality is pretty bad (see screenshot below). When magick is not installed, it works, but with another renderer (Qt5.5.1 in my case; Macbook Pro 2018, OSX 10.14.6; imagemagick#6 is installed vie brew). However, uninstalling R's magick, rebooting etc. works but is not convenient (especially if you need magick also for other R packages like summarytools) and therefore does not turn out to be a permanent solution. I might handle something not in the way it was intended and I am happy to get some help on this.
Fortunately, I found a solution which looks pretty standard. Simply include density in the save_kable function. This would have save me a lot of time.
p <- kable(yourdata, escape = F) %>%
kable_styling(bootstrap_options = c("condensed"), full_width = F)
p %>% save_kable("yourdata.pdf", density = 300)
Related
I work on computational music. I have found the ps13 pitch spelling algorithm implemented in Lisp in 2003, precisely "Digitool MCL 4.3". I would like to run this code, preferably on a Linux x86 machine, to compare its results with other similar codes.
I am new to Lisp, but so far my research led me to think that Digitool MCL is no longer available. I thought of two ways which may help me:
a virtual environment (Docker or else) which would emulate a machine from 2003…
a code translation tool which would transform the 2003 source code into something executable today
I have not succeeded in finding one of these two options, nor running it directly with sbcl (but, as a newbie, I may have missed a small modification to make it run easily).
May someone help me?
Summary
This code is very close to being portable CL: you won't need something emulating an antique Mac to run it. I ran it on three implementations (SBCL, LispWorks, CCL) within a few minutes. However if you're not a Lisp person (and don't want to become one) it will be somewhat more fiddly to do that.
However I can't just send you a fixed version, both because this isn't the right forum for that, and also because we'd need to get the author's permission to do so. I have asked him if he would be interested in a portabalised version, and if he is, I will send him one in due course. You could also get in touch and ask to be notified.
(Meta-summary: while I think the question is fine, any reasonable answer probably doesn't fit on SO.)
Details
One initial problem with this code is that the file uses old Mac line end conventions (I think: not Unix anyway): unless whatever Lisp you're using is smart enough to spot this (some are, SBCL seems not to be although I am sure there are options to tell it) you'll need to convert it.
Given that, the code that implements this algorithm is very, very close to being portable Common Lisp. It has four dependencies on non-standard things:
two global variables, *save-local-symbols* and *verbose-eval-selection*;
two functions: choose-file-dialog and choose-directory-dialog.
The global variables can probably be safely commented out as I think they are just controls for the compiler, probably. The functions have fairly obvious specifications: they're obviously meant to pop up file / directory choosers.
However you can just not use the bits of the code that use these functions, so you can compile it, get a few compiler warnings about undefined functions, and then it's fine.
But it gets better than that in fact: the latter-day descendant of MCL is Clozure CL: CCL is free, and open source. CCL has both choose-file-dialog and choose-directory-dialog already and both of the globals exist although one is no longer exported.
Unfortunately there are then some hidden portability problems to do with assumptions about what pathnames look like as strings: it's making some assumption about what things looked like on pre-OSX Macs I think. This kind of problem is easy but often a bit fiddly to fix (I think in this case it would be easy). So, again, the answer to that is just not call the things that are doing a lot of pathname munging:
> (ps13-test-from-file-list (directory "~/Downloads/d/*.opnd"))
[... much output ...]
Total number of errors = 81.
Total number of notes = 41544.
Percentage correct = 99.81%
nil
Note that the above output came from LispWorks, not CCL: CCL works just as well though, as will any CL probably.
SBCL has one additional problem: the CL-USER package in SBCL already uses a package which exports int which is defined in this code. So you need to compile it in some other package. But given that, it's fine in SBCL as well.
I have two CentOS 7.4.1708 machines, running gnuplot 4.6 patchlevel 2,
currently behaving differently, and I can't work out why.
Install fonts:
sudo yum install dejavu-sans-mono-fonts
Then create the following GNUplot script:
cat << EOF > test.gnuplot
set terminal pngcairo enhanced font "DejaVuSansMono,10"
set encoding utf8
set title "同"
plot sin(x)
EOF
Finally, pipe it into the application:
cat test.gnuplot | gnuplot > test.png
On one machine I get this:
But on another I get this:
I can't work out the cause of the discrepancy. The desired character is U+540C so it's not like the second machine is interpreting the input bytes any differently; it's just not rendering the glyph.
What differences in system configuration should I be looking for?
More broadly, how can I "fix" the output in the second case? I don't even vastly care if some characters end up getting replaced by placeholders like this (after all, I must recognise that not all fonts implement all glyphs), but those placeholders being rendered at super-size is a problem.
This post is rather a collection of observations than a complete answer, but perhaps it might be useful as well (I tried your example on an almost fresh install of CentOS and it does reproduce the second plot in your post):
judging from the charset table printed by the command
fc-match -v DejaVuSansMono
it seems that 540C is indeed not supported. Perhaps the first machine has some additional fonts installed which are used as a fallback for this particular glyph? How would the output of fc-list differ?
Hard to say if it is complete, but the list of fonts supporting this glyph seems to be rather limited. Nonetheless, for example Google Droid is available via yum, so if I do
sudo yum install google-droid-sans-fonts google-droid-sans-mono-fonts
and rerun the Gnuplot script, the plot renders in an acceptable way.
as for the size of the "fallback" box, I first noticed that its size is directly proportional to the specified font size, i.e., it also doubles if one doubles the font size. From src/wxterminal/gp_cairo.c, it seems that Gnuplot uses by default an "oversampling" strategy to render the text, i.e., it renders everything in plot->oversampling_scale times larger resolution and then scales it back (via the transformation matrix defined in void gp_cairo_initialize_context(plot_struct*)).
For example, when rendering the text, it calls
pango_font_description_set_size(desc, \
(int) (plot->fontsize*PANGO_SCALE*plot->oversampling_scale));
However, for some reason, the "fallback" box is not scaled back and thus is plot->oversampling_scale times larger than the specified font size. The default value of plot->oversampling_scale is set to GP_CAIRO_SCALE which is defined to be 20 in src/wxterminal/gp_cairo.h.
I downloaded the source of Gnuplot 4.6.2 and replaced plot->oversampling = TRUE; with plot->oversampling = FALSE; in void gp_cairo_initialize_plot(plot_struct*) in src/wxterminal/gp_cairo.c. After recompilation, the "fallback" box is rendered with the same size as the rest of text. Unfortunately, I haven't found a way how to change this behavior directly from Gnuplot.
I run matlab 2008 on Ubuntu 15.10. I need to put some czech words including "á", "í" and so on. Console disp is not a problem (but who cares for inline czech statements Píšeš háčky a čárky, obludo?). The issue is titles, legends etc. in figures. Naturally, the direct input from the keyboard doesn't work. Here is what I have tried based on docs and google:
Try to switch the font, it works fine for some of them. I haven't been successful so far and I have tried many. Is there any recommended one?
TeX that. It is a nice choice for a caron (háček) (e.g. \v{s}), but there is a problem with an accent (čárka) cause \'{a} would end the matlab string prematurely.
If the gnuplot would be a better choice, I wouldn't mind switching the enviroments.
The trick is to use \''{a} and to be sure that the interpreter is set to latex (not tex). Example:
title('Maxim\''{a}ln\''{i}','FontSize',30,'Interpreter','latex')
S5 is a sparse specification for slide presentations that run in the browser. It looks quite nice, and there's a couple of exporters for org-mode.
I am running Org 7.9.2 in Emacs 23, and I have a nearly working example:
* Joint diagonalization
Why does this work?
- Covariance matrices are commuting normal matrices
\begin{equation*}
(A^*A)
\end{equation*}
This produces one slide, but the equation snippets don't appear as evaluated.
Figured it out as I was writing the question, but it's worth mentioning as I couldn't find the answer anywhere else. As given in this page, the standard way for org-mode to export math into HTML is to use MathJax, set up to connect to the org-mode website to get at the script. This applies as well for S5.
That means you have to have a working connection to render that, or you have to set the path option in your org file like this: #+HTML_MATHJAX: path:"/MathJax/MathJax.js"
Also, if you run NoScript like me, you also have to make sure the domain specified is allowed to run scripts in your browser, or it'll never work ;)
fname = dir('*sir');
dayH = zeros(length(fname),1360,3600);
for i=1:length(fname)
dayH(i,:,:) = loadsir(fname(i).name);
end
fname = dir('*sir');
dayH = cell(1,length(fname));
for i=1:2
dayH{i} = loadsir(fname(i).name);
end
Basically it loads all my files. I have a separate .m file called loadsir that loads those specialized files. The output of the .sir files will be an array 1360x3600.
Right now that code is crashing saying, "Cannot display summaries of variables with more than 524288 elements." I guess it's because 1360X3600 = 5,000,000 about?
Putting Serg's comment as an answer:
Most likely you missed a semicolon (;) somewhere in loadsir. Matlab then thinks you want to print the output, which it won't do due to the large number of elements.
Additionally, to prevent such things from happening in the future:
Matlab is an interpreted language, meaning, no compilation is necessary. Any and all code can be parsed while you type it, which allows for things like auto-correct. Of course, this sort of thing is included already in standard Matlab. If you don't already, code in Matlab's own editor every now and then. It warns you of such silly mistakes/errors (and a lot more), including but not limited to, via the right vertical bar in the editor. The little square at the top right of the window should always be green. If it's orange or red, there's things to be improved or corrected, respectively.
The right vertical bar is an overview of all the lines in your file that leave room for improvement. If a small orange/red bar appears somewhere, a mouseover will tell you what's wrong with what line. Clicking it will navigate the editor to the line, which will likely be wavy-underlined in either orange or red. Mouse-over the line often gives useful suggestions, and <alt>+<enter> is often enough to fix the simple mistakes. I find it an indispensable tool when developing larger applications in Matlab.
You can of course configure which errors/warnings this tool ("code analyzer", formerly "mlint") displays. Sometimes, there will be a warning about an inefficiency that you simply cannot work around. Add an OK-directive behind the line to suppress it (%#ok), but don't make a habit of suppressing anything and everything "annoying" because that will of course completely beat the purpose of the code analyzer :)