Preview in disorder when insert .pdf file as figure

[ghost]

When the latex source code contains:

\begin{figure}[!htbp]
\centering
\includegraphics[width=0.99\columnwidth]{fig/**example.pdf**}
\caption{An example}\label{fig. 1}
\end{figure}

the figure in compiled PDF file will be presented in disorder through atom-pdf-view. But the real pdf file is normal when previewed by other softwares.

In my view, it may cause by inserting .pdf file as figure?

[izuzak]

Thanks for taking the time to open an issue, @wujw13!

In my view, it may cause by inserting .pdf file as figure?

Yeah, possibly. Can you share the generated PDF for that latext source so that other people can verify that the problem happens for them as well? You can attach the PDF in a comment here.

Also, which version of Atom and pdf-view are you using, and which OS+version?

[ovirtanen]

Hi,

I have the same problem.

Atom: 1.74 pdf-view: 0.50.0 OS: OS X 10.11.5

\documentclass[a4paper,12pt]{artikel3}
\usepackage{graphicx}
\usepackage{float}

\title{Test document}
\date{}

\begin{document}
\maketitle

\section{The only section}

There is one figure in this section.

\begin{figure}
  \begin{center}
  \includegraphics[width = 0.75\textwidth]{Fig_1.pdf}
  \caption{This is a pdf figure.}
  \label{}
  \end{center}
\end{figure}

\end{document}

bug.pdf

[ghost]

I used Atom 1.7.4/pdf-view 0.50.0/Mac OS X 10.11.5 when encountering the problem I mentioned, and I think @ovirtanen had the same problem.

However, the problem seems disappear when I tried to compile and view .tex file in atom today. I have no idea what exactly happened here.

[izuzak]

Thanks @ovirtanen @wujw13 -- I'm seeing the same problem as @ovirtanen. Not sure why that's happening, though. I probably won't have time to investigate this myself anytime soon, so if someone else wants to help and open a pull request to fix this -- I'd be happy to review it.

[183amir]

I am also affected by this.

[mdering]

do you think this is a problem with pdf.js or with this package?

[izuzak]

do you think this is a problem with pdf.js or with this package?

@mdering Wish I knew, but I don't. There's nothing special happening in this package for this case -- all PDFs are handled the same: the bytes are read from disk and passed to pdf.js for display. Perhaps this package needs to do something special for this case, but perhaps it needs to happen in pdf.js. If someone wants to dig in and investigate -- I think that'd be great.

[mdering]

@izuzak Allegedly pdf.js is what powers firefox, when I put my messed up pdfs in firefox it looks fine. i tried updating your package to the most recent release of pdf.js and it still doesn't look correct, so I'm not sure where to go from there.

[mdering]

ah, I wish anyone had any thoughts on this, it's very disconcerting!

[epimorphic]

(Sorry, should've checked before commenting, but I couldn't actually reproduce issue 137 using the test file provided by Haydnspass. Since the zoom issue I was running into was with embedded figures, I'll move my efforts here instead.)

I've traced the bug to this line in pdf-editor-view.js. On a pixel-doubled / "retina" screen, that line is supposed to double the size / resolution of the rendered image. However the change in scaling doesn't apply to certain embedded figures (possibly those that involve running the beginGroup–endGroup pair in pdf.js) because they seem to be drawn based on context._transformMatrix, which is only defined in pdf.js and thus unaffected by the default scale method. These figures end up being drawn at the 1x coordinates, hence appearing small and displaced.

It's only after the initial invocation of context.scale that pdf.js initializes the context properly and overwrites the scale method with ctxScale, which does interact with _transformMatrix. On subsequent renders the call context.scale(2,2) doubles the entries of context._transformMatrix each time, and so the figures get drawn at 2x, 4x, 8x, etc.

Note that ovirtanen's screenshot here and fabianp's on the other issue was taken on a retina display, while jiaweiw's wasn't.

Edit: Just pushed a workaround.

[izuzak]

Thanks for investigating and opening a pull request to fix this, @epimorphic! 🌟 I just merged the pull request and pushed a new version, so I'm going to close this for now.

If anyone can still reproduce the problem -- please add a comment! :bow: