search

dimidd / tikzedt

Automatically exported from code.google.com/p/tikzedt
1 stars 1 forks source link

Display errros when using 'addplot3' in combination with 'shader=interp' #31

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
\begin{tikzpicture}
\begin{axis}
\addplot3[surf,shader=interp]{x*y};
%\addplot3[surf,shader=faceted]{x*y};
\end{axis}
\end{tikzpicture}

What is the expected output? What do you see instead?
Expected output is the graph with shader=faceted, only with color 
interpolation. This is indeed the output, but the surface is shifted in 
positive z-direction when using 'shader=interp' instead of 'shader=faceted'.

What version of the product are you using? On what operating system?
TikzEdt 0.2.1.0, latest version of TikZ/PGFPlots

Please provide any additional information below.
muPDF (?) obviously has problems with 'shader=interp'. When exporting to PDF 
and viewing with Adobe Reader, everything is fine. So the preview is in fact 
misleading (it is known that many PDF viewers (e.g evince) are having trouble 
displaying with different shading types).

Original issue reported on code.google.com by markus.b...@gmail.com on 11 Apr 2012 at 8:54

GoogleCodeExporter commented 9 years ago 
Just tested opening the output PDF directly with mupdf-1.0rc1-windows and there 
are no such display problems. Maybe an update of mupdf within TikzEdt may 
resolve the problem.

Original comment by markus.b...@gmail.com on 11 Apr 2012 at 9:07

GoogleCodeExporter commented 9 years ago 
Even opening it with Adobe Reader reveals that the output is correct, so just 
the preview within TikzEdt is wrong and therefore misleading.

Original comment by markus.b...@gmail.com on 11 Apr 2012 at 11:42

GoogleCodeExporter commented 9 years ago 
Thanks for reporting this. I can confirm the issue and the comments. 

We currently use Antonio Sandoval's .NET mupdf wrapper, which is unfortunately 
discontinued and has not been updated to use the latest version of mupdf for 
some while.

The solution will be to use the mupdf binary directly and render the pdf to a 
png or bmp file and then to screen (instead of directly to screen as we do 
currently). This might be a bit slower, though, especially when zooming... I 
need to do some tests.

(Another solution is, of course, to maintain the wrapper ourselves, but this is 
time consuming.... we had to do that initially to fix some of its memory leaks.)

Original comment by t.willwa...@gmail.com on 12 Apr 2012 at 11:20

GoogleCodeExporter commented 9 years ago 
In the development version I changed the rendering to use the mupdf binary 
directly.
The sample is rendered correctly now.
There seems to be only a small hit on performance.

I still have to check whether licensing issues allow me to distribute the mupdf 
binary.... if so it'll be included in the next release.

Original comment by t.willwa...@gmail.com on 13 Apr 2012 at 10:28