ghostscript fornece indefinido em --execute-- ao usar color.tex com pstricks em texto simples

ghostscript fornece indefinido em --execute-- ao usar color.tex com pstricks em texto simples

Suponha o seguinte arquivo TeX simples:

\input pstricks
\input color
\pscircle{1.5}
\bye

Compilar usando eTeX funciona bem, dvips também. No entanto, o arquivo PS resultante não pode ser processado usando gs. Postarei a mensagem de erro, se necessário. Quandonãousando o pacote de cores, o fluxo de processamento funciona bem. A diferença entre os dois arquivos Postscripts gerados é:

<  0.8 SLW 0. setgray   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round
< sub dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW 0. setgray  1.
< .setopacityalpha   0  setlinejoin 0  setlinecap stroke  grestore end
---
>  0.8 SLW gray 0   0.0 0.0 2 copy moveto 42.67911 0 CLW mul round sub
> dup 0 rmoveto 0 360 arc closepath  gsave 0.8 SLW gray 0  1. .setopacityalpha
>   0  setlinejoin 0  setlinecap stroke  grestore end

ou seja, uma vez é usado "0. setgray" e na outra vez "gray 0". Tentei esclarecer, se "cinza" é um comando Postscript válido, pelo que descobri, a forma usual de definir uma cor é "setxxx".

Ainda não estou 100% se isso é um problema no color.sty ou no ghostscript. Você poderia me dar uma breve dica? Obrigado!

Responder1

O PSTricks precisa de pelo menos a cor definida black, que é definida internamente como \blacka qual se expande para 0 setgray. Mas só se estiver definido. No entanto, isso funciona:

\input pstricks
\input color
\newgray{black}{0}
\pscircle{1.5}
\bye

a parte problemática está em color.sty:

\ifx\color@gray\@undefined
  \ifx\color@rgb\@undefined
  \else
    \definecolor{black}{rgb}{0,0,0}
    \definecolor{white}{rgb}{1,1,1}
  \fi
\else
  \definecolor{black}{gray}{0}
  \definecolor{white}{gray}{1}
\fi

Por algumas razões históricas, o PSTricks define por padrão a cor \black. \color@graynão está definido, então color faz um \definecolor{black}{gray}{0} que é passado para o arquivo ps em vez de 0 setgray. No entanto, não há necessidade real de usar package color. Pode-se definir as cores com as macros PSTricks para plainTeX.

Responder2

Não é um problema de GS (o PostScript gerado é um erro)

Funciona em látex, pois (eu acho) xcolor é carregado nesse caso, mesmo que não seja explicitamente

\documentclass{article}
\usepackage{pstricks}
\usepackage{color}
\begin{document}


\pscircle{1.5}

\end{document}

As cores em tons de cinza também funcionam normalmente

\special{color push gray 0.5}
on two
\special{color pop}
three four

\bye

o especial dvips (com os argumentos que vêm após o comando color) é convertido para PostScript

0.5 TeXcolorgray

que é mais ou menos apenas a chamada PostScript primitiva

 0.5 setgray

A maneira como o pacote de cores funciona é que normalmente ele mantém a cor interna na "sintaxe especial específica do driver", então cinza é gray 0.5preto, gray 0etc. e quando necessário, o látex serve \special{color push \current@color}e o código correto é gerado.

Mas aqui a interface para converter para o formato interno do pstricks, então o pstricks está exibindo black as gray 0em vez de chamar o comando infame \c@lor@to@psque sempre aparecia como indefinido se você tentasse usar o pstricks com pdflatex .

\c@lor@to@ps gray 0aqui chamaria \c@lor@ps@gray 0qual se expande para 0 setgrayqual funcionaria.

informação relacionada