I am creating a PDF using MigraDoc and have now ran into a little problem. I am using a A4 size image (2480px x 3508px / 96KB in size) as a background for my PDF using the following code:
Dim frame = Section.Headers.FirstPage.AddTextFrame
frame.AddImage("background.png")
frame.WrapFormat.Style = WrapStyle.Through
frame.RelativeHorizontal = RelativeHorizontal.Page
Using this causes the PDF to render around 10 times longer (say 10 seconds) then without or a smaller sized file (say 1 second). Is there anyway to speed this up?
I have tried to not use a frame thinking this could be the problem displaying the image using:
Dim backing As Image = Section.Headers.FirstPage.AddImage("background.png")
But still the same results, the reason I want time cut down is I create up to 1000 of these and this can take a long time at the current speed.
I cant downsize the image any more but I don't see why it should be a problem with the size. If this is the problem and there is no way around it please do let me know.
Maybe it goes faster when you use a JPEG file (if that is an option).
JPEG files are copied into the PDF as they are. PNGs and other formats have to be converted into "PDF images".
You can use pages from PDF files just like images. This is another option you can try: once create a PDF with your background image, and create all other files with that PDF instead of the PNG (if JPEG is not appropriate for your image).
There are two builds of MigraDoc: one using GDI+, one using WPF. You could try both to see if that makes a difference.
BTW: Images can be positioned like TextFrames, so there is no need to put an Image into a TextFrame.
Related
I am using inkscape to change the file type from a pdf to an emf. I noticed when I open the files in corel (to check that it was outputted correctly) that they are different sizes than each other - the pdf is the size I set it to be initially (as you'd expect), while the emf is a plain letter size (8.5 x 11).
If I am only using
inkscape 49.pdf -o 49.emf
on the command line, why is it changing the document size? Is there a way to preserve it? Has any one else had this problem? I've checked the man page for options and I haven't seen an explicit command to preserve page size (though I don't believe I should have to even do).
Thank you so much for your input!
I read my hyperspectral (.raw) file and combine three bands to "gai_out_r" Then I output as following:
writeRaster(gai_out_r,filepath,format="GTiff")
finally I got gai_out_r.tif
But, why Win10 can't display this small tif as the pic that I output the same way from envi--save image as--tif
Two tiffs are displayed by Win10 as following:
Default windows image viewing applications doesn't support Hyperspectral Images-since you are just reading and combining 3 bands from your .raw file, the resulting image will be a hyperspectral image.You need to have separate dedicated softwares to view hypercubes or can view it using spectral-python also.
In sPy, using envi.save_image , will save it as a ENVI type file only. To save it as an rgb image file(readable in windows OS) we need to use other methods.
You are using writeRaster to write to a GTiff (GeoTiff) format file. To write to a standard tif file you can use the tiff method. With writeRaster you could also write to a PNG instead
writeRaster(gai_out_r, "gai.png")
Cause of the issue:
I had a similar issue and recognised that the exported .tif files had a different bit depth than .tif images I could open. The images could not be displayed using common applications, although they were not broken and I could open them in R or QGIS. Hence, the values were coded in a way Windows would not expect.
When you type ?writeRaster() you will find that there are various options when it comes to saving a .tif (or other format) using the raster::writeRaster() function. Click on the links therein to get to the dataType {raster} help site and you'll find there are various integer types to choose from.
Solution (write a Windows-readable GeoTIFF):
I set the following options to make the resulting .tif file readable (note the datatype option):
writeRaster(raster, filename = "/path/to/your/output.tif",
format = "GTiff", datatype = "INT1U")
Note:
I realised your post is from 2 and a half years ago... Anyways, may this answer help others who encounter this problem.
So, on my projects I require an aerial photo of a site. I usually use ones in public record. I use the USGS high res ortho photos located here https://earthexplorer.usgs.gov/. I have them uploaded to my server and they are TIFs and have TFWs and XMLs associated with them (I am unsure of what the xml is for). I can load these into autocad fine, and print them just fine. average file size of these appears to be in the 250,000 kb range.
On some of my projects, I need more detail. I get privately flown aerial photos of a site. These come as a JPG format and are georefernced by a .jgw. These files are about 25000 kb depending on the site ( I did not notice this at first, as i was told they are very large relative to the TIFs). When these are loaded into autocad and i try to plot, the whole system freezed and wont plot for about 15-20 mins. At first I thought this was a file size issue. So I did the following in R, to try to reduce the size. My code is as follows.
library(jpeg)
library(tiff)
img <- readJPEG("ortho.jpg", native = TRUE)
writeJPEG(img, quality = 0.2)'
This got the file size down to about 9000 kb. I loaded this into autocad and it still would not plot. This leads me to assume that size is not the issue. With this is mind what could be a property of this photo that would freeze autocad? How could I fix those properties in R or in Autocad.
First I would check out the first and third causes listed here: https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/Some-OLE-objects-do-not-plot.html and see if that fixes your issue.
Second I would convert to a png (in my limited experience those seem to be the most stable in autocad.)
library(png)
writePNG(img)
If you really need it in jpg I would try the solutions here too: https://www.landfx.com/kb/autocad-fxcad/images/item/1926-raster-disappear.html
I am doing a forest plot and want to save it to a PDF file.
My forest plot is oversize (8in*20in). It can fit in a one page PDF like this:
dev.print(pdf, file="C:\\Work\\plot.pdf", width=8, height=20);
But then it is too long: When I print this PDF on a A4 paper, it has to be shrinked to fit the paper.
So I want to save it to a two-page PDF file (from R). Ps: it is not a question about how to set the printer.
How to do this?
So, you are able to generate an 8in x 20in == 203.2mm x 508mm == 576pt x 1440pt sized PDF showing a plot.
It is not entirely clear to me from your question what exactly you want:
Generate the PDF plot so that it is divided into two different pages from the beginning?
Take the PDF as is and during the print job setup find these settings which would print it onto two different pages by posterizing the original page?
Post-process the PDF that you created to posterize it and create a 2-page output PDF (which you can then print)?
Assuming '1.': generate PDF plot distributed over 2 pages
Sorry, I cannot help here...
Assuming '2.': print setup to print 1 PDF page on 2 sheets of paper
If you print a PDF from Adobe Acrobat or from Adobe Reader, then you'll find a setting in the print dialog named "Poster". Here you can select to print one PDF page across multiple pieces of paper. (It also lets you select if you want some overlap from piece to piece, and if you want to add cut marks and the like to the printouts).
Assuming '3.': post-process 1 PDF page to stretch over 2 A4 pages
MuPDF is a lightweight PDF (and other document formats) viewer, made by the same company that also maintains Ghostscript. MuPDF ships with an additional command line utility, mutool.
Its subcommand poster can divide PDF pages into smaller tiles and 'posterize' them. So this command will achieve what you want:
mutool poster -x 1 -y 2 input.pdf output.pdf
The output.pdf will be divided into 1 part (i.e. not divided) in x-, and into 2 equal parts in y-direction. (You could divide it into any other number of segments if you wanted). So output.pdf will have two pages, each sized 8in x 10in. A4 paper is sized 8.26in x 11.69in when measured in Inches.
When printing these, you'll still need to enable the Print to fit Page Size checkbox in the print dialog if you want to make best use of the A4 page size.
Ghostscript is a command line tool that can (amongst many other functions) be used to process PDF files (PDF in, modified PDF out). It can be (ab)used to cut PDF pages into halfs.
Here are a few previous StackOverflow answers which describe how to do it. You'll need to adapt some parameters to your specific size(s), but the principles should be clear from those examples (even though some of these split pages into left and right halves, not top/bottom as you may require):
Linux-based tool to chop PDFs into multiple pages (SuperUser)
Freeware to split a pdf's pages down the middle? (SuperUser)
Convert PDF 2 sides per page to 1 side per page (SuperUser)
How can I split a PDF's pages down the middle? (SuperUser)
Cropping a PDF using Ghostscript 9.01 (StackOverflow)
PDF - Remove White Margins (StackOverflow)
Split one PDF page into two (StackOverflow)
The method described there is more tedious and not as straight-forward as with the mutool poster method.
Maybe not the answer you are looking for but you could print it in another vectorial format (e.g. svg) and then export it as pdf on two pages with a (vectorial) image editor.
Edit: If ploting in pdf works well despite the big size of the graph there are also tools to split pdf pages. You can find some directions here:
https://superuser.com/questions/437148/how-to-split-a-pdf-onto-multiple-pages-on-command-line
Windows equivalent of pdfposter could be Rasterbator or PosteRazor, for example.
I have a script that makes barplots, and opens a new window when 6 barplots have been written to the screen and keeps opening new graphic devices whenever necessary.
Depending on the input, this leaves me with a potential large number of openened windows (graphic devices) which I would like to write to a single PDF file.
Considering my Perl background, I decided to iterate over the different graphics devices, printing them out one by one. I would like to keep appending to a single PDF file, but I do not know how to do this, or if this is even possible. I would like to avoid looping in R. :)
The code I use:
for (i in 1:length(dev.list())
{
dev.set(which = dev.list()[i]
dev.copy2pdf(device = quartz, file = "/Users/Tim/Desktop/R/Filename.pdf")
}
However, this is not working as it will overwrite the file each time. Now is there an append function in R, like there is in Perl. Which allows me to keep adding pages to the existing pdf file?
Or is there a way to contain the information in a graphic window to a object, and keep adding new graphic devices to this object and finally print the whole thing to a file?
Other possible solutions I thought about:
writing different pdf files, combining them after creation (perhaps even possible in R, with the right libraries installed?)
copying the information in all different windows to one big graphic device and then print this to a pdf file.
Quick comments:
use the onefile=TRUE argument which gets passed through to pdf(), see the help pages for dev.copypdf and pdf
as a general rule, you may find it easier to open the devices directly; again see help(pdf)
So in sum, add onefile=TRUE to you call and you should be fine but consider using pdf() directly.
To further elaborate on the possibility to append to a pdf. Although, multiples graphs can be put easaly into one file it turns out that it is impossiple or at least not simple to really append a pdf once finished by dev.off() - see here.
I generate many separate pages and then join them with something like system('pdfjam pages.pdf -o output.pdf' )*