In the last 3 days something has happened to RMarkdown. When rendering the default .rmd file produced by RStudio to a PDF file, the plot created has no margins beyond the plot axes and the axis scales and titles are not visible. When rendering to .html or Word format, the figures are as they should be. Today I reinstalled R and RStudio and updated all of the libraries (update.packages()) and the problem remains. This first cropped up in a bookdown project so I checked the .png files that bookdown produces and they all have the same problem - no axis scales or titles and the axis margins are at the figure limits.
Update: I un/reinstalled miktex and the pdf compiled correctly. When I removed MikTex and used tinytex instead, the axes were cutoff again. If I use MikTex instead of tinytex, every rmarkdown chunk generates an error that the MikTex database is locked by another program (no other apps were running so it much be something in the background) and results in a ~1-2 minute delay and a total compile times approach 45 minutes (before this problem it was ~5 minutes, still pretty slow). So it appears that there's an issue with tinytex and how it generates the .png files. I'm at a loss.
Any thoughts?
Current versions
R $version.string
[1] "R version 4.1.3 (2022-03-10)"
RStudio version
[1] ‘2022.2.1.461’
for me...
worked again after returning to earlier tinytex version
tinytex::install_tinytex(version = "2021.03")
tinytex::tlmgr("option repository https://ftp.tu-chemnitz.de/pub/tug/historic/systems/texlive/2020/tlnet-final")
for me, the PDF image files in figure_latex folder lacked axis/titles
happened shortly after I re-installed tinytex, even for the simplest code:
rmarkdown::render("test.Rmd",output_format='pdf_document')
in the jaml
output:
pdf_document:
keep_tex: true
plot(1:10,xlab='as 1',ylab='as 2')
html worked fine
Related
I am trying to detect the .pdf file text.
They are first converted to an image, then given to Tesseract.
The detection is good but they make too many line breaks.
For example if the file is a bit panched on the right, the sentence:
"I like Tesseract for reading text"
become:
"text read for Tesseract like I"
And that's already after a treatment because the raw text is :
"textreadforTesseractlikeI"
The bug occurs since the source .pdf are in 300DPI, I understand that the problem comes from the resolution but I cannot find how to solve it.
Here is my Tesseract cmd Tesseract.exe dummy.pdf dumy-ocr.pdf --psm 12 --dpi 300 -l bvr+fra+eng+deu hocr pdf
First, I would like to solve the problem of too many lines,
Then I would find out how to make the image perfectly straight
Thank you in advance for your help
https://i.stack.imgur.com/crmdO.jpg
You seem to be working backwards.
The "many" lines and thus word reversal are due to the anti-clockwise rotation.
text"
reading
for
Tesseract
like
"I
Fix that first and then the words will naturally all be placed on the same lines.
If using Leptonica in conjunction with Tesseract it is supposed to help with the pre-processing including deskew.
However there is a very small but powerful open source GUI and Command Line tool for Windows, Linux, and macOS that you could use from a shell see https://galfar.vevb.net/wp/projects/deskew/ it is also available on GitHub as an appveyor CI artifact so for the most up to date version (currently 5 days ago) follow the green tick at https://github.com/galfar/deskew
When I run the script below on a DM EELS spectrum that already contains background and signal ROIs, it is ok if I don't show any images.
ImageDocument imdoc = GetFrontImageDocument()
image i0 = ImageDocumentGetImage(imdoc,0)
image subt = eelssubtractpowerlawbackground(i0,800,900)
//image irrelevant = realimage("irrelevant",4,100,100)
//showimage(irrelevant)
But if I show any image after running the background subtraction command (activate the last 2 lines for example) the pre-existing ROIs on the initial image are changed (sig disappears and bckgd is moved to the new position).
This is despite i0 being in theory a new image, not part of the initial one.
Creating copies within the script and working on them appears in any case not to solve the problem.
More surprising is that if I first make a duplicate of the initial image and run the script on that, then close the new windows and the (modified) spectrum on which the script was run, then try and duplicate the initial image, the duplicate has the modified ROIs rather than its own. A second duplicate seems to be ok. I have no idea what's going on. Grateful for any ideas.
(The problem was initially part of a much bigger script in which I need to show images, I've reduced it to the essentials here). I'm using v2.3.2.
I have tested your script on an EELS Spectrum with ROIs in GMS 2.3.3 and in GMS 3.2.2
GMS 2.3.3:
It does not seem to happen due to the ShowImage() but rather whenever the display of the image the last Background/Signal ROI was used on is refreshing its display. You get the same behavior when you run your script without the last two lines, but then click on another image (to select it) and then the spectrum again. And you get the same if you've used the background-subtraction ROI on a completely different image and then run the script. It messes up that last images' ROIs.
GMS 3.2.2: Doesn't show this. All is fine regardless what you do.
So, from these two tests I would conclude it is a bug in GMS 2.3 which has since been fixed.
The behaviour is indeed very odd, and I see nothing wrong with your code.
The bug seems to be that the command eelssubtractpowerlawbackground() messes with the settings of the last active signal-extracting ROIs, regardless on where they are placed on. It doesn't matter what the input image is. It seems to "reuse" these last ROIs.
Unfortunately, I don't know a good workaround for it.
Community
I'm facing problem in rdlc. i'm using (.rdlc) in window application to print report.
Issue : (space between char)Fonts of report are getting overlap horizontally same issue also happens in export and Print.This issue facing after system format.
to fix this i'have tried all way like System Font set to 100%, replaced rdlc,printer driver,import all required fonts to systems(Arial-11pt).but still issue is exist.
Image Here
After hours of searching, I believe I found at least part of the answer to this problem. As described in one of the comments here, it can be fixed using this hotfix. However, the hotfix is no longer available for download.
I have a crazy issue that's driving me insane :)
Using highcharts export to PDF feature, it generates the graph data but without text.
I am using Debian 6 and installed the libbatik-java which had a transcode issue when it came to exporting to PDF. After some reading the solution found on stackoverflow was to download batik from apache's site which I done and can now export to PDF.
However the text isnt shown as it appears to be rendered off screen because when I edit one the x/y values it can then see the text.
I works perfectly fine when exporting to PNG or JPG.
I also copied the SVG to another server which is running AIX and ran batik command there and it converted to PDF without issues.
I also tried copying the batik DIR from our AIX box to the Debian box but still have the same problem.
Not sure what else I can do :(
Any help would be appreciated.
UPDATE: I wrote to Wolfram support about this and will update the post if they can resolve the problem. Sorry for spamming SO with a technical support question, but here it remains in case anyone else is having the same issue.
Is anyone else having this problem with Mathematica 8? I recently upgraded and noticed that when I export Graphics to a PDF file, although the file appears fine on my computer, it prints as a blank page. For example, try
Rectangle[{1,1}]//
Graphics//
Export["~/test.pdf",#]&
which creates a PDF file containing a black square. This file opens fine, but if I send it to my department printer I just get a blank page. If I don't export the graphics but print the notebook from MM, no problem, the graphics print as expected. If I use MM 7 to do exactly the same thing, the PDF file prints as expected. Exporting to PNG in MM8 seems to work fine. And, using the context menu Save Graphics As ... or File > Save Selection As ... to create a PDF containing just the graphic also works. However, these graphics eventually get included in a TeX document, and it would be far better if I could continue using the script I've got that doesn't require any button clicking to generate them.
I'm running MM 8.0.0.0 on Mac OS 10.6.7. I have not been able to test this on another printer yet, but this printer has never given me problems before and prints other PDF documents fine. Any ideas why this is happening?
Wolfram Research responds:
...
This issue has been reported by other users as
well and our developers are currently looking into it. I have added your
details to the report so you can be notified when this is resolved.
In the meantime, the alternatives that you could try are:
Try a different printer.
Rasterize the image with the function 'Rasterize' before exporting. If
the rasterized image loses some resolution, you could use the option
'ImageResolution' to edit this.
Rasterize[image, ImageResolution -> xxx]
Surely this is a bug (please report it to support#wolfram.com), but you can work around the problem by selecting the graphic and choosing File > Save Selection As... from the menu (or Save Graphic As... from the contextual menu). This produces a slightly different file that doesn't appear to exhibit the undesirable behavior we observe from Export[].
These problematic files, and LaTeX PDFs that include them, can be properly printed by Adobe Reader 10.1.2. That's if you're okay with installing and using a 450MB PDF reader.
I reproduced the problem (leading me to this question) with Mathematica 8.0.4.0 on Mac OS X 10.7.2. Wolfram suggested lame workarounds like Rasterize and told me
This issue has been addressed by our developers, and a fix will be included in a future version of Mathematica.