# [tex-k] dvips: 'fun' with translation combined with scaling/rotation

Joseph Wright joseph.wright at morningstar2.co.uk
Mon Mar 5 10:51:17 CET 2018

On 05/03/2018 07:32, Tomas Rokicki wrote:
> I don’t think dvips supports what you are trying to do.
>
> I’m also not sure what you are trying to accomplish.  Can you clarify?
>
> -tom

Hi Tom,

I'll try to: this might be a bit long!

The background here is I'm looking at how one creates 'drawings':
inserting specials for lines, etc., into a box such that it 'works' as
part of a document. The well-known TikZ package does that, and I'll
looking at the code and trying to understand it. It's not always clear
why things are done a particular way: driver interactions are often complex.

More specifically, if one creates such a 'drawing', depending on the
driver in use you need to fiddle about with the reference point, etc.
That is the case in dvips but not in pdfTeX (direct PDF output). That
has a knock-on if you want to then put some normal TeX material inside a
'drawing' (e.g. 'Put the word XXX at the end of a line drawn from the
drawing origin to (1cm,1cm)'). All of the strange PostScript fiddling
about in the example I sent is meant to allow that. Crucially, from a
TeX point of view all of the 'drawing' stuff has no size, so any TeX
material is inserted at (or relative to) the reference point of the
\hbox everything is inside (this is the origin of the drawing).

Everything works fine for the simple case of the TeX 'inner' box being
inserted at the origin with no scaling/rotation/shear. If we want to do
those operations, we have to apply some driver-specific code or use raw
PostScript/PDF insertion, depending on the driver involved. In dvips, we
don't have high-level functions so it comes down to using a raw
PostScript concat operation. This also works fine: the text is not
displaced and does get transformed as requested.

The other thing we might make to a box is to shift it (to put the
content somewhere other than at the origin). That can be done two ways:
by doing it from the 'TeX side' using \kern, \raise, \lower, etc., or
from the 'PostScript side' by adding a shift component to the concat
operation. If you look at TikZ, with dvips it does the latter, but with
pdfTeX in PDF mode it uses \kern + \lower for the shifts, and only uses
the CTM to apply any scalings, etc. Again, this works fine: it's when I
combine the two that odd stuff happens.

Ideally, I'd like to be able to split up 'move the box around' and
'change the shape of the box'. So I was aiming to use a common flow:

- 'Escape' from the drawing set up (driver-dependent)
- Adjust the box position using a horizontal \kern and a \lower
- Change the box shape using a driver-specific application of the CTM
("\pdfsetmatrix" for pdfTeX, "pdf:btrans" for (x)dvipdfmx, "ps::
<matrix> concat" for dvips)
- Insert the box (at zero size)
- Tidy up (end the CTM scope, etc.)

Initially I thought it all worked well: doing either 'change the box
shape' or 'shift the box' is fine across all of the drivers I've tried.
The only place it's fallen down (at least I've found so far) is
combining a shift and a shape-change with dvips.

As I said at the start, my assumption is I'm missing something about the
dvips set up. If that comes down to 'You can't separate out the two
things in dvips' then I'll go back to handling all of it together. I'm
mainly wanting to make sure I've not missed something obvious.

Joseph