[XeTeX] Graphics overwriting text

[Karljurgen Feuerherm]

For what it's worth, this last few months I have found that Beamer presentations with embedded JPG graphics (which worked fine last year) when recompiled exhibit the same problem. Not always, but fairly consistently.

Evidently something has changed in the handling of such files. I've been using e.g.

 \pgfdeclareimage[height=60mm]{<labelname>}{<path to file>}

Then invocations of the form

\begin{pgfpicture}{0mm}{0mm}{80mm}{-60mm}
\pgfputat{\pgfxy(0,0.5)}{\pgfbox[left,top]{\pgfuseimage{EgyptNG}}}
\end{pgfpicture}

Same problem until the file is re-encoded. The system used to be more forgiving; perhaps the internal file settings were overridden in favour of the explicit framing dimensions, but no longer?

I've found it simplest to just run a batch conversion to .PNG on everything now rather than fix them on a case-by-case basis....

K

Karljürgen G. Feuerherm, PhD | 2-139 Department of History | Wilfrid Laurier University | 75 University Avenue West | Waterloo, Ontario N2L 3C5


From: Wilfred van Rooijen <wvanrooijen at yahoo.com<mailto:wvanrooijen at yahoo.com>>
Reply-To: Wilfred van Rooijen <wvanrooijen at yahoo.com<mailto:wvanrooijen at yahoo.com>>, "xetex at tug.org<mailto:xetex at tug.org>" <xetex at tug.org<mailto:xetex at tug.org>>
Date: Friday, November 21, 2014 at 08:15
To: "johann.spies at alterit.co.za<mailto:johann.spies at alterit.co.za>" <johann.spies at alterit.co.za<mailto:johann.spies at alterit.co.za>>, "xetex at tug.org<mailto:xetex at tug.org>" <xetex at tug.org<mailto:xetex at tug.org>>
Subject: Re: [XeTeX] Graphics overwriting text

I have a feeling that the JPG image is the source of the problem, and that somehow the calculation of the bounding box (i.e. the calculation of the size of the figure) somehow goes wrong. Apparently, the actual image is larger than what latex expects.

Note the following: LaTeX does not know about figures. LaTeX will open the figure file to determine how much space should be reserved for the figure. LaTeX then leaves so much space white. When LaTeX finishes, and the PDF conversion software starts to process, then the figure is actually included in the PDF. In the present case, apparently the figure is larger in the PDF file than what LaTeX expects.

I think you should inspect the JPG file with some reasonable graphics software like GIMP and correct the settings (bounding box and/or resolution)

Wilfred



On Friday, November 21, 2014 7:12 PM, Johann Spies <johann.spies at alterit.co.za<mailto:johann.spies at alterit.co.za>> wrote:


I cannot rememember whether I ever had a problem like this.  Today,
xelatex seems to ignore settings like [width=0.8\linewidth] when I use
includegraphics. I had to scale it down to [width=0.25\linewidth] today
to get a a picture in my text which which I could work.

Another problem showed up: the image lies over some text.  In the past
LateX / XeLaTeX respected the boundaries and that did not happen. The
following code cased the output in the attachment:
--------------------------
\item  ``It must be help which is quite uncalculating.  Those who
  helped did not think that they were helping Christ, and thus piling
  up eternal merit; they helped because the could not stop themselves
  helping'' \cite[359]{barclay_gospel_1968}.

\end{itemize}

\includegraphics[scale=0.1]{DSC_3936.JPG}

--------------------------------

What is going on here?

Regards
Johann
--
J.H. Spies - Tel. 021-982 2694 / 082 782 0336 / 021-808 4599(w)
            Posbus 4668, Tygervallei 7536

    "A new commandment I give unto you; That ye love one
      another. As I have loved you, so ye also must love one
      another.  By this shall all men know that ye are my
      disciples, if ye have love one to another."
                        John 13:34,35



--------------------------------------------------
Subscriptions, Archive, and List information, etc.:
  http://tug.org/mailman/listinfo/xetex


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/xetex/attachments/20141121/f6cb74de/attachment-0001.html>