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

[Joseph Wright]

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