Re: colortbl query | output differences...

On Jan 23, 2:58 pm, cooc...@xxxxxxxxxxxxxxxxx wrote:

\documentclass[10pt,letterpaper,oneside]{article}
\usepackage{colortbl}
\begin{document}

\begin{center}
\begin{tabular}{|c|c|} \hline
\cellcolor[gray]{0.9} \emph{E1} & 0 \\
\hline
0 & \cellcolor[gray]{0.9} \emph{E2}\\
\hline
\end{tabular}
\end{center}
\end{document}

When I generate using LaTeX, and preview the DVI, everything looks as
I expect. However, strange things happen depending on how I generate
the PDF.

1. if I go my usual LaTeX -> DVI -> PS -> PDF route, using

-dBATCH -dNOPAUSE -sDEVICE=pdfwrite -r600 -dCompatabilityLevel=1.4
-dPDFSETTINGS=/prepress
[...]
It appears
(for lack of a more precise description) that for the shaded cells,
the shading overlaps cell borders on the left-hand side for any shaded
cell.

2. If I use PDFLaTeX instead, the problem seems to vanish - on screen,
but still seems to show up when printed.


This seems to be a pixel rounding problem. Every
display and printing device has a minimum sized
dot that it can print or display. If the absolute
size of two rules (which TeX computes to amazing
accuracy) causes their boundary to land in the middle
of one of these dots then that dot must be assigned to
one rule or the other. When one rule is less than one
pixel wide, and the boundary dot happens to be
assigned to the other rule, the first rule can disappear.

Colored boxes are implemented as rules, with
colored ink.

Different display devices round pixels in different ways.
When I see such a problem, I try to view/print it three
different ways: with a DVI viewer, a PS viewer like
in gsview, and with a PDF viewer like Acrobat Reader
or gsview. In each (except when printing), I try
several different zoom levels. If the rule disappears in
some and reappears in others, then this pixel
rounding is most likely the problem. Occasionally
giving dvips a large resolution argument will save the
printed version. Try
dvips -D 7200 ...
This requires that all fonts are available to dvips in
type1 format or else dvips will try to create pixel-based
fonts at this enormous resolution. You can also try
dvips -h tex.pro -h alt-rule.pro ...
which uses an alternate algorithm for specifying rules.
You can also try both sets of options.

As long as screen and printer resolutions are such
that standard thickness lines (.4 to .5 pt) have a width
of less than, say 2 pixels, there is not much that can be
done unless all display and print drivers were to agree on
the algorithm for rounding rule boundaries to pixel boundaries.


Dan
.

Relevant Pages

  • Re: colortbl query | output differences...
    ... This seems to be a pixel rounding problem. ... dot that it can print or display. ... dvips -D 7200 ... ... the algorithm for rounding rule boundaries to pixel boundaries. ...
    (comp.text.tex)
  • Re: [solved] Cant make fonts look any better
    ... arbitrarily choosing a value black or white for the pixel, ... a blurred glyph, one subdivides the pixel into smaller squares ... blur the boundaries which are horizontal or vertical. ... Practically this works better with TTF fonts that with ...
    (comp.unix.bsd.freebsd.misc)
  • Re: Sigma SD9...your thoughts?
    ... Definition of a pixel ... ... The smallest image-forming unit of a video display. ... pixel depends on how you've set the resolution for the display screen. ... dot size) of the display. ...
    (alt.photography)
  • Re: scan dpi for photos
    ... There is a brightness value for each pixel. ... A halftone dot on a printing press is the same as a "pixel". ... The dot in an inkjet, dot matrix, or laser printer is NOT the same as a pixel. ... If it prints 81 black dots the resulting pixel is very black. ...
    (rec.photo.digital)
  • Re: Sigma SD9...your thoughts?
    ... >> Sigma a 10.2 MP camera. ... "A pixel is one of the many tiny ... As the resolution of said camera is quite obviously 3.2MP, ... > dot size) of the display. ...
    (alt.photography)