# [Fwd: Strange behavior?]

Denis Girou Denis.Girou at idris.fr
Fri Nov 7 10:01:44 CET 1997

-----------------------------------------------------------------------------
This is the PSTricks mailing list, devoted to discussions about computational
graphics in (La)TeX using the PSTricks package from Timothy van Zandt.
For help using this mailing list, see instructions at the end of message.
-----------------------------------------------------------------------------

>>>>> "Ulrich.Dirr" == Ulrich Dirr <udirr at das-team.com> writes:

Ulrich.Dirr> Is the first address correct? <pstricks at tug.cs.umb.edu>

Yes, this is. But alias <pstricks at mail.tug.org> (and www.tug.org for Web
server) doesn't work for the moment, due, as far as I understand, to a conflict
with the Internet organization which attribute names, as another organization
require the "tug.org" name.

Ulrich.Dirr> (1)
Ulrich.Dirr> I have a silly question concerning \psaxes.
Ulrich.Dirr> In Germany the decimal delimiter is a comma and not a point.
Ulrich.Dirr> Now if you have axes with a range say from -2.5 to 4.5 the
Ulrich.Dirr> labeling is with decimal points.
Ulrich.Dirr> Is there an easy way to change the _output_ to commata?

Ulrich.Dirr>     Denis Girou>  Of course, it is not a specific PSTricks question. But for
Ulrich.Dirr>     Denis Girou>  labels of axes, you have to redefine the macros \pshlabel
Ulrich.Dirr>     Denis Girou>  and \psvlabel (notice that there is a typo in PSTricks
Ulrich.Dirr>     Denis Girou>  documentation page 51, refering to \psxlabel and \psylabel,
Ulrich.Dirr>     Denis Girou>  typo reported in pst-doc.err). Something like:

Ulrich.Dirr>     Denis Girou>  % To change decimal points by virgules in axes labels
Ulrich.Dirr>     Denis Girou>  \makeatletter
Ulrich.Dirr>     Denis Girou>  \def\pshlabel#1{\expandafter\LabelVirgule#1..\@nil}
Ulrich.Dirr>     Denis Girou>  \def\psvlabel#1{\expandafter\LabelVirgule#1..\@nil}
Ulrich.Dirr>     Denis Girou>  \def\LabelVirgule#1.#2.#3\@nil{%
Ulrich.Dirr>     Denis Girou>  \ifx#1\@empty0\else#1\fi
Ulrich.Dirr>     Denis Girou>  \ifx#2\@empty\else,#2\fi}
Ulrich.Dirr>     Denis Girou>  \makeatother

Ulrich.Dirr> thanks, this worked well, except e.g. an y-axis from 0 to 12 will be
Ulrich.Dirr> numbered
Ulrich.Dirr> 1, 2, ..., 10, 0, 12
Ulrich.Dirr>               ^^^

Ulrich.Dirr> So you have to write instead of
Ulrich.Dirr> \ifx#1\@empty0\else#1\fi
Ulrich.Dirr> \ifx#1\@empty#1\else#1\fi

Right!

Ulrich.Dirr> and if you want correct negative numbers you have to add some dollar
Ulrich.Dirr> signs:
Ulrich.Dirr> \def\LabelVirgule#1.#2.#3\@nil{%
Ulrich.Dirr> \ifx#1\@empty$#1$\else$#1$\fi
Ulrich.Dirr> \ifx#2\@empty\else,$#2$\fi}

Ulrich.Dirr> May this is not a proper solution but it worked!

No, you are right, it must be typeset in math mode. And you can see in
pst-plot.tex that the defaulls are:

\def\pshlabel#1{$#1$}
\def\psvlabel#1{$#1$}

Nevertheless:

1/ I can't figure today why I named the internal macro \LabelVirgule in
french. \LabelComma seems more consistant.

2/ What I still found unpleasant, even if this is the default behavior,
is to have a ",0" for integer values when Dx or Dy are less than 1. It's easy
to make them disappear:

\documentclass{article}

\usepackage{pst-plot}

% To change decimal points by commas in axes labels
\makeatletter
\def\pshlabel#1{\expandafter\LabelComma#1..\@nil}
\def\psvlabel#1{\expandafter\LabelComma#1..\@nil}
\def\LabelComma#1.#2.#3\@nil{%
\ifx#1\@empty$#1$\else$#1$\fi
\ifx#2\@empty\else\ifnum#2=0\else,$#2$\fi\fi}
\makeatother

\textwidth=19cm
\textheight=25cm

\pagestyle{empty}

\begin{document}

\psset{unit=2}

\begin{pspicture}(-3,-1.5)(3,1)
\psaxes(0,0)(-3,-1)(3,1)
\end{pspicture}

\begin{pspicture}(-3,-1.5)(3.5,1)
\psaxes[Dx=0.5,Dy=0.5](0,0)(-3,-1)(3,1)
\end{pspicture}

\begin{pspicture}(-3,-1.5)(3,1)
\psaxes[Dx=0.5,Dy=0.2](0,0)(-3,-1)(3,1)
\end{pspicture}

\psset{unit=0.25}
\begin{pspicture}(12,12)
\psaxes(12,12)
\end{pspicture}
\hfill
\begin{pspicture}(12,-12)
\psaxes[xunit=0.1,yunit=0.01,Dx=20,Dy=100](-120,-1200)
\end{pspicture}

\end{document}

Ulrich.Dirr> (2)
Ulrich.Dirr> I've recently updated the pstricks package to the pst97 version.
Ulrich.Dirr> I had to make a new edition of a mathematical schoolbook where i had
Ulrich.Dirr> successfully used the "old" pstricks macros.
Ulrich.Dirr> The following problems occured:
Ulrich.Dirr> 1. all hatching with hlines and vlines in a polygon were rotated 90
Ulrich.Dirr> degrees.

Strange, I see no difference between 93 and 97 for hlines and vlines
fillstyle. Send me your test case. And which dvi to ps converter do you used?

Ulrich.Dirr> 2. e.g. take
.......................
Ulrich.Dirr> \rput[Br](13,-.7){x}
Ulrich.Dirr> \rput[tr](-.3,16){y}
Ulrich.Dirr> \rput[Br](-.3,-.7){$0$}
.......................
Ulrich.Dirr> \rput[cr](-.3,1){$1$}
.......................
Ulrich.Dirr> \rput[Bc](1,-.7){$1$}
.......................

Ulrich.Dirr> then x, y, and 0 were positioned correct, but the other digits moved!
Ulrich.Dirr> This behavior is corrected by deleting the "c" in the \rput parameter.
Ulrich.Dirr> But what has changed?

It's a funny case... In fact, the "c" value was never described and you must
had not use it in the past! See the diagram page 44 of the documentation which
show that the values tlrbB are the only defined ones. So we can't consider
this problem as a bug.

But what do you see a difference between 93 and 97 versions?!
The explanation is the following. In the 93 version, "c" was undefined and
ignored. It doesn't generate an error message because in fact these values
are not checked, but it has simply no effect. So, when you used "cr", you got
the result for "r". But in 97 version (in fact in the pst-beta stuff deliver
in 1994 that you hadn't used here, because in this case you would already have
seen the problem...), this part was extensively rewritten by Timothy. And he
introduced the "c" value at this time! It was undocumented, but you can guess
it existence reading page 19 of the beta documentation which say that the
\ncput macro designed according the \rput one use a default value for the ref
parameter of "c". So, now "c" has a meaning! And "rc" has now the effect of
"c", which use the horizontal and vertical centers as reference point. Which
is of course not the same thing that the "r" that you got in 93 version...
And this is why you have what you call the "correct" behaviour when you delete
the "c".

P.S. Even if the "c" value was introduced, you must take care that it
doesn't work the same way that in the graphics/graphicx package. It always
center both horizontally and vertically when for graphic. packages "c", "lc",
"rc", "cb", "cB" and "ct" have different actions.

Ulrich.Dirr> (3)
Ulrich.Dirr> And finally is there a possibility to have more line types?
Ulrich.Dirr> In addition to dotted and dashed something mixed? (-.-.- or --.--.--
Ulrich.Dirr> etc.)
Ulrich.Dirr> It would be useful in some circumstances where there are many lines
Ulrich.Dirr> which have to be distinguished.

No, it is not offer by actual macros, and it will not be too easy to
implement as extension of dashed line style (you must redefine the PSTricks
macro \psset at dash to deal with four parameters and also rewrite the PostScript
DashLine macro).

Nevertheless with the linewidth, dotted, dotsep, dashed and dash parameters
you have already many possibilities to distinguish between lines. Not enough

\documentclass{article}

\usepackage{pstricks}

\newcommand{\MyLine}[1][linestyle=solid]{%
\begin{pspicture}(0,-0.5)(10,0.5)
\psline[#1](10,0)
\end{pspicture}}

\pagestyle{empty}

\begin{document}

\MyLine

\MyLine[linestyle=dashed]

\MyLine[linestyle=dashed,dash=3mm 1mm]

\MyLine[linestyle=dashed,dash=1cm 5mm]

\MyLine[linestyle=dashed,dash=1cm 1cm]

\MyLine[linestyle=dashed,dash=3cm 1cm]

\MyLine[linestyle=dashed,dash=3cm 3cm]

\MyLine[linestyle=dashed,linewidth=1mm,dash=6cm 3cm]

\MyLine[linestyle=dotted]

\MyLine[linestyle=dotted,dotsep=5mm]

\MyLine[linestyle=dotted,linewidth=1mm,dotsep=5mm]

\MyLine[linestyle=dotted,linewidth=1mm,dotsep=2cm]

\end{document}

P.S. In fact, I see a possibility to have the style of lines you are looking
for, as an effect of "tiling", but for that I think it's rather "a harm to
kill a butterfly"...

D.G.

-----------------------------------------------------------------------------