Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am getting the following error while compiling my Latex File :
! LaTeX Error: Cannot determine size of graphic in tree.jpg (no BoundingBox).
Why do I get this error ? What has this to do with an .eps file ?
In fact, I could compile it fine with MacTex on my machine. But when I submit it online to a scientific journal for publication, it compiles it on the server and sends me the resultant PDF which has all these errors that prevent it from compiling.
I am using the following syntax for including the images :
\begin{figure}[!h]
\begin{center}
\scalebox{0.45}{
\includegraphics{tree.jpg}}
\end{center}
\caption{\small A sample}
\label{tree}
\end{figure}
What should I do ? Could it be that their server is using an old compiler ?
UPDATE : It finally worked. I converted the first image to PDF and the compilation happened perfectly. I guess it used the bounding box value from that PDF and applied it to all images.
To include png and jpg, you need to specify the Bounding Box explicitly.
\includegraphics[bb=0 0 1280 960]{images/some_image.png}
Where 1280 and 960 are respectively width and height.
I've had the same problems including jpegs in LaTeX. The engine isn't really built to gather all the necessary size and scale information from JPGs. It is often better to take the JPEG and convert it into a PDF (on a mac) or EPS (on a PC). GraphicsConvertor on a mac will do that for you easily. Whereas a PDF includes DPI and size, a JPEG has only a size in terms of pixels.
( I know this is not the answer you wanted, but it's probably better to give them EPS/PDF that they can use than to worry about what happens when they try to scale your JPG).
Using .jpg files do not forget about compiling directly to .pdf (pdflatex) and use:
graphicx package with pdftex option (\usepackage[pdftex]{graphicx}).
If you have Gimp, I saw that exporting the image in .eps format would do the job.
I use MacTex, and my editor is TexShop. It probably has to do with what compiler you are using. When I use pdftex, the command:
\includegraphics[height=60mm, width=100mm]{number2.png}
works fine, but when I use "Tex and Ghostscript", I get the same error as you, about not being able to get the size information. Use pdftex.
Incidentally, you can change this in TexShop from the "Typeset" menu.
Hope this helps.
On a Mac (pdftex) I managed to include a png file simply with
\includegraphics[width=1.2\textwidth]{filename.png}
. But in order for that to work I had to comment out the following 2 packages:
%\usepackage[dvips]{epsfig}
%\usepackage[dvips]{graphicx}
...and simply use package graphicx:
\usepackage{graphicx}
It seems [dvips] is problematic when used with pdftex.
I had the same problem, caused by a clash between the graphicx package and an inclusion of the epsfig package that survived the ages...
Please check that there is no inclusion of epsfig, it is deprecated.
Related
I'm trying to convert a page of a PDF to an image. I'm successful with most PDF's I've tried with but this one in particular always ends up with a lot of whitespace on one side or strange scaling.
I've tried every combination of every fixed media, fixed resolution, fit page, use crop/bleed/trim/art box, etc. parameter to fix the issue but nothing does it. The best I get is the right content size but offset and chopped off.
Here's what it should look like, according to every PDF reader I've tried:
Here's a link to the PDF (8 MB) for testing.
https://drive.google.com/file/d/1ErS3KxADb1YAdzM7FG7T5dO8QnW4l1AQ/view?usp=sharing
Edit 1:
Here's what it looks like using just -dUseCropBox without a cropbox override:
I'm using Ghostscript.NET with very simple code. I create a rasterizer, call Ope(PDF file, ghostscript dll in bytes), then GetPage(DPI, page number). To use other flags I add a custom switch to the rasterizer before calling open
using(var rasterizer = new GhostscriptRasterizer()) {
//rasterizer.CustomSwitches.Add("-dFIXEDMEDIA");
//rasterizer.CustomSwitches.Add("-dFIXEDRESOLUTION");
//rasterizer.CustomSwitches.Add("-dPSFitPage");
//rasterizer.CustomSwitches.Add("-dFitPage");
//rasterizer.CustomSwitches.Add("-dPDFFitPage");
//rasterizer.CustomSwitches.Add("-dUseCropBox");
//rasterizer.CustomSwitches.Add("-dPrinted");
//rasterizer.CustomSwitches.Add("-dUseBleedBox");
//rasterizer.CustomSwitches.Add("-dUseTrimBox");
//rasterizer.CustomSwitches.Add("-dUseArtBox");
//rasterizer.CustomSwitches.Add("-sPAPERSIZE=letter");
//rasterizer.CustomSwitches.Add("-dORIENT1=true");
//etc
rasterizer.Open(pdfFilePath, ghostscriptDLL);
img = rasterizer.GetPage(dpi, pageNumber);
img.Save(pageFilePath, imageFormat);
}
I'll try again with the latest version of just ghostscript (no .NET) and see if that makes a difference.
Edit 2:
Using just gswin64c version 9.55.0 and -dUseCropBox works as KenS said. Since I don't need Ghostscript.NET to do that, that's a good resolution.
Using just gswin64c version 9.55.0 and -dUseCropBox works as KenS said. Since I don't need Ghostscript.NET to do that, that's a good resolution.
I am having an issue with PDF's in the latest Typo3 release. If I add PDF to the Image content element, I get this:
The file info looks like this:
Checking the Image Processing Test of Typo3, no errors are returned. PDF/AI also seems to be fine.
I tested several PDF's and AI files as well, they won't show dimensions either.
I have the suspicion that the command 'identify' does not work within Typo3, it still returns perfect results from shell.
Any idea where to look?
multiple reasons possible:
you just need to reimport metadata (scheduler task)
your PDF is coded in an unsual format (there is more then one option in PDF to include the title image)
missing/wrong rights:
maybe another program is executed from commandline than from PHP.
maybe the file can't be accessed correctly from ghostscript started from web
I'm working with a bunch of PDF files, some of which have been scanned at a bit of an angle. Adobe Acrobat allows me to rotate PDF files by 90 or 180 degrees. But is there a way to rotate a PDF just a few degrees - just enough to make it straighter?
I could perhaps take a screenshot, open it in Photoshop and rotate it, then somehow convert the Photoshop file to a PDF. However, that seems like a really clumsy process.
PDF supports for complete pages only /Rotate values of 90 degrees, because that is (of course) simple. What you need to do is rotate the contents, not the page. So you need to use something which can remake the PDF file for you.
You could use either Ghostscript or MuPDF to do this. Either will require some coding:
MuPDF will require coding in C,
Ghostscript will require you to do some PostScript programming.
Using Ghostscript you would need to define a BeginPage procedure which rotates the content by a small amount and moves the origin of the content slightly as well (because the rotation rotates around the origin, which is at the bottom left, not the centre).
Here is a short utility script for rotating pages (written in Perl). It converts each page of the input PDF to a PDF XObject Form, rotates the form, then outputs the rotated page.
#! /usr/bin/perl
use warnings; use strict;
use PDF::API2;
use Getopt::Long;
my $degrees = 3;
my $scale = 1.0;
my $x = 0;
my $y = 0;
GetOptions ("rotate=i" => \$degrees, "scale=f" => \$scale, "x=f" => \$x, "y=f" => \$y)
or die "usage: $0 IN_PDF OUT_PDF --rotate=DEG --scale=ALPHA --x=POINTS --y=POINTS";
my $infile = shift (#ARGV);
my $outfile = shift (#ARGV);
my $pdf_in = PDF::API2->open($infile);
my $pdf_out = PDF::API2->new;
foreach my $pagenum (1 .. $pdf_in->pages) {
my $page_in = $pdf_in->openpage($pagenum);
#
# create a new page
#
my $page_out = $pdf_out->page(0);
my #mbox = $page_in->get_mediabox;
$page_out->mediabox(#mbox);
my $xo = $pdf_out->importPageIntoForm($pdf_in, $pagenum);
#
# lay up the input page in the output page
# note that you can adjust the position and scale, if required
#
my $gfx = $page_out->gfx;
$gfx->rotate($degrees);
$gfx->formimage($xo, $x, $y, $scale);
}
$pdf_out->saveas($outfile);
You'll need to ensure the PDF::API2 and Geopt::Long modules are installed from CPAN.
The script by default rotates 3 degrees anticlockwise, this is configurable vi the --rotate options.
There are also -x, -y and --scale options to allow fine adjustments of the positioning and scale of the output pages.
This question has also been asked on unix.stackexchange.com .
Another option is using LaTeX:
\documentclass{standalone}
\usepackage{graphicx}
\begin{document}
\includegraphics[angle=-1.5]{odd-scan}
\end{document}
In this case, I have the file odd-scan.pdf (a slightly rotated one page scan) in the same folder as the LaTeX file rotated.tex with the content above and then I run pdflatex rotated.tex. The output is a file rotated.pdf with the PDF rotated by 1.5 degrees clockwise.
(I assume a *nix-style environment. On Windows, you can follow these instructions in Cygwin, although I think you might have to build MuPDF from source there as it doesn't appear to be in the Cygwin repos. If you don't want to do that and you're okay with rasterizing the PDF, ImageMagick is in the Cygwin repos and can do the whole job if needed—see below.)
MuPDF's mutool utility can do this. Say you have a PDF file rotate_me.pdf and you want a version of it rotated by 20° clockwise written to a file rotated.pdf:
#!/bin/bash
mutool draw -R 20 -o rotated.pdf rotate_me.pdf
(mutool draw docs)
You can also rasterize the PDF using mutool convert, work with the image files, and then create a new PDF from them (this assumes rotate_me.pdf has between a hundred and a thousand pages—edit the %3d to your liking):
#!/bin/bash
# - for whatever reason convert's `rotate` is counter-clockwise
# - %nd is replaced with the page number
mutool convert -O rotate=-20 -o 'rotated_%3d.png' rotate_me.pdf
(mutool convert docs)
Once you've done whatever else you need to do the image files and you're ready to turn them back into a PDF, you can use ImageMagick:
#!/bin/bash
magick convert $(ls | grep -P 'rotated_[0-9]{3}\.png') rotated_finished.pdf
(If you get an error saying the security policy for PDFs doesn't permit this, you may need to edit /etc/ImageMagick-7/policy.xml and comment out or remove the <policy domain="coder" rights="none" pattern="PDF" /> line. Be aware of this Ghostscript pre-v9.24 vulnerability which that security policy may be intended to mitigate. If you're working with files you made yourself, you should be safe here, but you may want to re-enable this policy afterwards depending on your needs and environment. If you're not working with files you made yourself, especially PDFs, be careful, whether you have a pre-v9.24 Ghostscript installed or not. PDF as a format is very complex and offers many different places to squirrel away maliciousness, and practically speaking you can never be 100% confident that the software you're using to work with it is perfectly hardened.)
ImageMagick can also rasterize PDFs on its own, although it's a bit more complicated. For example:
#!/bin/bash
magick convert -density 150 -rotate 20 rotate_me.pdf rotated.pdf
This might look similar to the mutool draw command, but the difference is that ImageMagick will rasterize the input PDF and then use the resulting images to make the output PDF, so you can use all the regular ImageMagick transformations with this command.
Anyway, -density is for DPI. It will default to 72 DPI if you don't pass that argument, which is likely to not look very good. Also, ImageMagick doesn't seem to be quite as smart as MuPDF about margins and things like that as far as PDFs go, so you may need to do more work with it than this to get reasonable output for your use case. If you do have access to both MuPDF and ImageMagick, I think doing the rasterization with MuPDF and then doing further work on the resulting images with ImageMagick tends to give the nicest results with the least work, but of course that may or may not be practical for you.
(magick convert docs)
Rasterization has obvious disadvantages if your PDF is vector-based—increased file size, fixed resolution, loss of flexibility, etc. Also, even if your PDF is already storing raster graphics, you may lose text data or the like from it in the conversion. If the PDF is really horrible, though, sometimes this is the least painful approach. You can OCR it if needed once you've cleaned it up using Tesseract, often with superior results to whatever may have been done before you arrived.
This can be done with cpdf:
cpdf -rotate-contents 5 in.pdf -o out.pdf
(Rotates around the centre of the page by five degrees)
I had this at one time. I don't know how many pages there are that you have.
What I did is print the pages that wear off use a paper cutter to square them up and rescanned them. Hope this helps.
And yes I've try to find some type of program to fix this and I still have not found one .
I have a really weird problem:
plt.xlabel("$t$[ms]")
plt.ylabel("$\dot{q}$[deg]")
plt.axvline(x=span2Stop,lw='0.3',c='0.5')
plt.axvspan(spanStart, spanStop, facecolor='0.9', alpha=1,edgecolor='0.9',lw=0)
plt.annotate('11ms',fontsize='9', xy=(11, -500),xytext=(2, -500),verticalalignment='center',arrowprops=myarrow)
plt.annotate('13ms',fontsize='9', xy=(13, 1000),xytext=(2, 1000),verticalalignment='center',arrowprops=myarrow)
plt.annotate('17ms',fontsize='9', xy=(17, -500),xytext=(20, -500),verticalalignment='center',arrowprops=myarrow)
plt.tight_layout()
plt.savefig(imagePath + "snapAHVjoints.pdf")
plt.savefig(imagePath + "snapAHVjoints.svg")
plt.show()
generates a nice looking picture. But plt.axvline(x=span2Stop,lw='0.3',c='0.5') causes a broken pdfmark in the exported pdf if included in latex as a pdf. I spent ages to find that.
Compiled with xelatex to pdf. The problem does not seem to be related to the loaded packages (to be honest I didn't try to to disable hyperref but tested almost all options I found).
Any Idea what's wrong with that?
lw='0.3' should be lw=0.3 Nevertheless, no broken pdf should be exported. If you export it as eps matplotlib complains, so I recognized it that way
Is that a bug or am I again getting wrong soem pythonic things?
I am trying to install a custom font into my iPhone application. When I add the 'Fonts provided by application’ key into my info.plist file I get the following error ': FT_Open_Face failed: error 85.’
I am not sure what the problem is as I have successfully been able to use custom fonts in the past.
Any help will be appreciated.
If you leave the first element in your font array in the plist (index 0) blank, you will get this error.
PostScript fonts cannot be used with UIFont directly. You can use them only with CoreText or CATextLayer.
This can occur if the font in question is a Font Suitcase format. Open your application package, and if the font .ttf file shows a size of "Zero bytes", it's probably a font suitcase.
Files of this type can be converted using Fondu.
When running Fondu, I had to specify not just the suitcase file, but the resource fork inside it:
fondu mysuitcasefont.ttf/..namedfork/rsrc
This will extract any fonts in the suitcase to the current directory. It is these extracted files you will want to include in your iOS project and reference from the .plist.
I received this error when using a .ttf font. I was able to correct it by removing the file extension from the filename in (a) the resource in xcode and (b) the "Fonts provided by application" array in the .plist file.
Hopefully this will help.
I was trying to use Google Signika font on my App, and got the exact issue.
I solve the issue by using the .otf version of the font
Accepted answer is totally wrong and unnecessary. Probably you made a mistake when writing your font name.
Thats rules for that.
First Step : Write font name before .ttf extension. Example: For FFFTusj.ttf => FFFTusj
Second Step : Write - and after font style. Example: Bold or Medium etc. Example: #"FFFTusj-Bold"
And also dont forget add your font file to your project.
Check this link:
http://www.bycoder.com/post/2013/03/28/XCode-Custom-font-doesnt-work
If your font is REGULAR dont write -Regular at end of font name.