7

When viewed on screen, look of document processed via dvipdfmx is better, than that of produced via pdftex.

This happens with absolutely any document, even with plain format.

I tried with these viewers:

atril xpdf evince qpdfview mupdf okular gv zathura

Each of them produces different screen output on documents, obtained via dvipdfmx (or dvips+ps2pdf) and pdftex.

As is shown on the pictures, in pdf mode the font color is grey and links color is blurry, in comparison with dvi mode.

enter image description herepdftex.pdf enter image description heredvipdfmx.pdf

$ pdffonts dvi.pdf 
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
FESNVM+CMSY10                        Type 1C           Builtin          yes yes yes      4  0
XZXPQO+CMR10                         Type 1C           Builtin          yes yes no       5  0
CSTOKE+CMR8                          Type 1C           Builtin          yes yes no       6  0
LXXLBC+CMBX10                        Type 1C           Builtin          yes yes no       7  0
LIFJYF+CMTI10                        Type 1C           Builtin          yes yes no      11  0
$ pdffonts pdf.pdf
name                                 type              encoding         emb sub uni object ID
------------------------------------ ----------------- ---------------- --- --- --- ---------
IGWWSQ+CMSY10                        Type 1            Builtin          yes yes no       8  0
GVEKFU+CMR10                         Type 1            Builtin          yes yes no       9  0
JBEWTB+CMR8                          Type 1            Builtin          yes yes no      10  0
RRATMA+CMBX10                        Type 1            Builtin          yes yes no      11  0
YOSONK+CMTI10                        Type 1            Builtin          yes yes no      14  0

In one of the topics it was proposed to convert Type1 fonts to Type1C fonts via ps2pdf, but the problem is that ps2pdf converts fonts to raster images while creating pdf, thus this is not a proper way. Moreover, although the converted document is better, it is still a little blurry in comparison with the one, obtained via dvipdfmx.

I will accept if this is not possible to correct pdf viewer or pdftex, but at least why do not I get the same look of the document from pdftex and dvipdfmx?

NOTE the answer should not assume changing fonts - default Computer Modern must be used.

UPDATE

This is very strange: compile the following code with pdftex and tex+dvipdfmx - the colors are not the same at all! Maybe this is the key for understanding this mystery?

1) code for dvipdfmx:

\special{color push rgb 0 0 1}
\vrule width 5cm height 5cm
\special{color pop}
\bye

2) code for pdftex:

\input pdfcolor
\Blue
\vrule width 5cm height 5cm
\bye

enter image description heredvi mode enter image description herepdf mode

And the same for \Black !!!

enter image description here enter image description here

  • What font info is reported for the two docs? – Joseph Wright Jan 14 '16 at 7:02
  • 1
    using \input color \color{blue} rather than \input pdfcolor \Blue produces correct color. – user4686 Jan 14 '16 at 9:51
  • 1
    In LaTeX you can use \documentclass{article} \usepackage[rgb]{xcolor} \begin{document} \color[cmyk]{1,1,0,0} \rule {5cm}{5cm} \end{document} to produce the same output as with \color{blue}. The rgb option to xcolor tells it to convert the color to rgb-model. I believe this means the pdf is then created with something akin to \pdfliteral {0 0 1 rg 0 0 1 RG} (apart from using the pdf color stack). I don't know why using a \pdfliteral color specification in cmyk model seems to result in a very different color space at the time of pdf rendering. – user4686 Jan 14 '16 at 17:46
  • 1
    Perhaps this answer will prove useful ? what I understand is that the \Blue in pdfcolor.tex is in an abstract cmyk model, whose naive conversion to rgb model does correspond to R0 G0 B255, this is for example what xcolor would do if asked to do that conversion cmyk->rgb; but if one lets the cmyk color spec inscribed as is inside the pdf it will end up rendered very differently than the supposedly equivalent rgb spec. Other (non-linear ?) conversions are done PDF spec. – user4686 Jan 14 '16 at 18:00
  • 1
    As I said first, you are comparing different colors. Please try %tex + dvipdfmx \input color \definecolor{myblue}{rgb}{0,0,1} \definecolor{Myblue}{cmyk}{1,1,0,0} \color{myblue} \vrule width 5cm height 5cm \color{Myblue} \hskip5mm\vrule width 5cm height 5cm \bye – Akira Kakuto Jan 15 '16 at 5:12
2

There were actually two clashing problems, which in the beginning I thought was one problem - and as such messed up some points in my question.

In light of newly revealed facts, I would like reclassify the above mentioned viewers into two categories.

a) the following viewers differ only with respect to color model (rgb vs. cmyk)

gv mupdf

b) the following viewers differ with respect to color model and with respect to fonts handling (Type1 vs. Type1C)

qpdfview evince okular xpdf atril zathura

1) Answer for the problem with color model:

use \pdfliteral{0 0 1 rg} and \pdfliteral{0 0 0 rg} for blue and black correspondingly

2) Answer for the problem with greyish look: convert the document with ps2pdf (it does not produce raster fonts, as I mistakenly wrote in my question)

ps2pdf -dPDFSETTINGS=/prepress -dAutoRotatePages=/None -dEmbedAllFonts=true -dSubsetFonts=true orig.pdf new.pdf

Now when I compare output of ps2pdf with output of dvipdfmx there are any differences.

The only thing left to do is to ensure that this ps2pdf command works without loss of information, i.e., how to convert back to Type1 fonts and compare hash sums with the original?

Summary: Apart from the problem with color model, I presume this to be a bug of pdf viewer and/or pdf library in handling Type1 fonts vs. Type1C fonts, because output of gv and mupdf looks absolutely the same before and after processing with ps2pdf, as it should be.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.