[OS X TeX] Re: Apple PDF viewer bugs on this shading

Tue Dec 1 00:20:34 CET 2009

On Nov 30, 2009, at 5:02 PM, Ross Moore wrote:

> Hi Quark (?)
> 
> On 01/12/2009, at 7:00 AM, Quark67 wrote:
> 
>> Hello, sorry for my english, I'm the original poster from the french newsgroup which Alain Matthes speak.
>> 
>> In your message http://www.tug.org/pipermail/macostex-archives/2009-November/042073.html you have posted a screenshoot attachment and you say "It looks fine for me, in both Preview and TeXshop.  " . I suppose you have compiled this with tex+dvi in TexShop ?
> 
> No. It was compiled with pdftex as the engine.
> When I do it again using TeX+dvi mode then the squares are more
> prominent, as you say.
> 
> 
> On the MacOS X TeX list the interest seemed to be in the results
> obtained with different viewers. I seemed to be getting different
> results from what others claimed, but they didn't post any images
> to show what was the issue. Now that you have shown what is the
> real problem, we can examine it in more detail.
> 
> 
> Even with pdftex, the squares are visible when blowing-up to
> ~400% , and even noticeable at ~200%.
> An attached image shows this, where the squares are just discernible
> on the right, in Preview, but not on the left using Adobe Reader.
> 
> 
> <withPdfTeX.png>
> 
> These were done using pdfTeX:
>  This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
> 
> 
> Using TeX+dvi+Ghostscript the squares are much more prominent.
> Both PDF viewers seem to give similar results (as in the 2nd attached
> image):
> 
> <withDVI+GS.png>
> 
> 
> 
> The results that I see are explained reasonably easily.
> 
> With TeX+dvi+GS the Postscript code produces small lines of colour
> that are stroked for a particular length:  1.1 setlinewidth
> and with equal linewidth:                  1.1 0 rlineto stroke
> This gives the coloured squares that you see.
> 
> 
> With pdfTeX, the coding is wrapped up differently:
> 
> 12 0 obj <<
> /Shading << /Sh << /ShadingType 1
> /ColorSpace /DeviceRGB /Matrix [1 0 0 1 56.69363 56.69363]
> /Domain [-56.69363 56.69363 -56.69363 56.69363] /Function 4 0 R >> >>
> 
> /ShadingType 1   sets the shading to be constant in the squares,
> with the colour being calculated by  /Function 4 0 R
> and the grid determined by the  /Domain  specification.
> 
> It would seem that Adobe handles the /ShadingType 1  a bit more
> smoothly than does Preview. (Perhaps it has some extra
> anti-aliasing at the edges of the squares?)
> 
> 
> The conceptual difference between the PDF coding and the
> PostScript coding is that with the PDF it is clear that we are
> shading an extended region, so the result is supposed to look
> smooth. (There is even the possibility of an extra setting
>  /Antialias /True
> which a viewer might implement, but doesn't have to.)
> 
> With the PostScript, on the other hand, it is really just
> a collection of separate strokes in different colours.
> The renderer does not have the extra hint that these are
> meant to be filling a region. In particular there could
> be some interaction with the pixel boundaries, leading
> to a less-smooth result, visually.
> 
> 
> 
> The PDF Spec offers the following alternatives:
> 
> 
> 8.7.4.3   Shading Dictionaries
> 
> A shading dictionary specifies details of a particular gradient fill, including the type of shading to be used, the geometry of the area to be shaded, and the geometry of the gradient fill. Various shading types are available, depending on the value of the dictionary’s ShadingType entry:
> 
> •Function-based shadings (type 1) define the colour of every point in the domain using a mathematical function (not necessarily smooth or continuous).
> 
> •Axial shadings (type 2) define a colour blend along a line between two points, optionally extended beyond the boundary points by continuing the boundary colours.
> 
> •Radial shadings (type 3) define a blend between two circles, optionally extended beyond the boundary circles by continuing the boundary colours. This type of shading is commonly used to represent three-dimensional spheres and cones.
> 
> ... and more ...
> 
> 
> In an uncompressed version of the PDF you can simply edit
> to replace  /ShadingType 1  by  /ShadingType 2 .
> However Adobe Reader reports an error and shows no colour.
> 
> Preview, on the other hand, seems to be ignoring this parameter.
> The colour remains, with no perceptible change.
> 
> 
> But the /Function  needs to produce a different collection
> of data, to suit the type 2 and type 3 shadings.
> Tikz can use type 2 --- with  \pgfdeclarehorizontalshading
> and \pgfdeclareverticalshading ---  and type 3 with
> \pgfdeclareradialshading .
> It would be interesting to see the results using these.
> 
> Perhaps the biggest problem with this, though, is that
> whereas type 1 uses a single function of 2 parameters,
> to assign colours within a 2-dimensional region,
> types 2 and 3 use only a single parameter, varying in
> a 1-dimensional way. So you would need to create a number
> of radial strips (narrow sectors) and setup the shading
> separately within each of these.
> You would need to setup the sectors in TeX; or do a single
> sector multiply, each shaded differently then rotated into
> the correct place.
> 
>> 
>> But, for me, this is not very good : if you look closer, you can see this (compiled with tex+dvi):
>> <pgf4.png>
>> 
>> Not smooth shade... I see big squarre (compare picture 1 and picture 3 here : http://quark67.free.fr/pgf.html ).
> 
> 
> Hope this helps.
> 
> And I'd still like to see what others get with later versions
> of different viewer software.
> How does it fit with the above analysis?
> 
> 
> Cheers,
> 
> 	Ross

Howdy,

Here are screen shots for pdflatex+Preview, the same pdf file and Adobe Reader and finally latex(->dvips->ps2pdf)+Preview.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdflatex+Preview.pdf
Type: application/applefile
Size: 25522 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdflatex+Preview.pdf
Type: application/pdf
Size: 44505 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment.pdf>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdflatex+AdobeReader.pdf
Type: application/applefile
Size: 28747 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdflatex+AdobeReader.pdf
Type: application/pdf
Size: 174670 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment-0001.pdf>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: latex+Preview.pdf
Type: application/applefile
Size: 30636 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: latex+Preview.pdf
Type: application/pdf
Size: 67047 bytes
Desc: not available
URL: <http://tug.org/pipermail/macostex-archives/attachments/20091130/0b6a92d4/attachment-0002.pdf>
-------------- next part --------------

So there seems to be a difference between what you're seeing and what I (and presumably Alain) are seeing with OS X 10.6.2.

Good Luck,

Herb Schulz
(herbs at wideopenwest dot com)