Native support for perspective-transformed text rendering (PostScript-level transformation)

[Esteban82]

I would like to share a PostScript prototype I implemented and ask for feedback before attempting to integrate this into the GMT source code.

This is related to #8816, but I decided to post it separately for clarity.

I implemented a PostScript prototype that applies a backward rotation around the bottom edge of a text object, followed by a perspective projection. The visual effect is similar to the perspective tool in GIMP. The prototype is intended for text elements such as titles, for now.

How it would be used

The user would only need to provide a rotation angle and a Field-of-View (FOV) (as in GIMP).
All other parameters (text bounding box, rotation axis, focal distance, vanishing point, depth scaling) are computed automatically.
The rotation axis and vanishing point are hire-wire the the bottom edge and the center of figure respectively.

How it would be used

The user would only need to provide:

• A rotation angle
• A Field-of-View (FOV)

Conceptually, something like:

+p<angle>/<fov>

All other parameters (bounding box, focal distance, depth scaling, etc.) are computed automatically.

Currently, the rotation axis and vanishing point are hard-wired to:

• The bottom edge of the text (rotation axis)
• The center of the figure (vanishing point)

However, both could be made configurable without major changes.

Current Question

Before moving toward a C-level implementation inside GMT (likely within PSL or the text rendering logic), I would appreciate feedback on the PostScript prototype.

In particular:

• Are there obvious inefficiencies in the current path transformation approach?
• Is there an existing PSL mechanism that could simplify this?
• Any recommendations to improve performance or numerical stability?

My goal is to ensure the PostScript logic is clean and efficient before porting it into the GMT source code.

Postscript prototype

Output:

File:

%!PS-Adobe-3.0
%%BoundingBox: 0 0 245 100

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 1. USER PARAMETERS
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

/ang_rotation 30 def     % Rotation angle (degrees)
/fov 45 def              % Field of view (perspective angle in degrees)

/texto {
  (Episode IV)
} def                    % Text to render

/Times-Roman findfont 54 scalefont setfont  % Font configuration

/z_near 0 def            % Canvas is located at z = 0 (added just in case)

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 2. BASIC MATH UTILITIES 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% Basic trigonometric functions. This could be done in C.
/tan { dup sin exch cos div } bind def
/tan_f { fov 2 div tan } bind def
/cos_ang_rotation { ang_rotation cos } bind def
/sin_ang_rotation { ang_rotation sin } bind def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 3. TEXT BOUNDING BOX
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Computes bounding box and dimensions of the text path

/Get_Text_Bounding_Box {
  true charpath
  pathbbox
  /top exch def
  /right exch def
  /bottom exch def
  /left exch def
  /height top bottom sub def
  /width right left sub def
} bind def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 4. ROTATION SETUP
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

/Rotation_Setup {
  % Use bottom edge as rotation axis (it can be modified)
  /axisOriginY bottom def
} bind def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 5. PERSPECTIVE SETUP
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

/Calculate_Focal_distance {
  /focal height 2 div tan_f div def
} bind def

/Set_Vanishing_point {                    % Set at the center of the figure
  /Cx right left add 2 div def        % Vanishing point X (center)
  /Cy top bottom add 2 div def        % Vanishing point Y (center)
} bind def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 6. PATH TRANSFORMATION UTILITIES from Bill Casselman.
%% https://personal.math.ubc.ca/~cass/graphics/manual/transform.inc
%% I have his permission to use it.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

% The original file includes a subdivide procedure. I am not using it. 
% But maybe it can be included.

/ctransform {
  load
  8 dict begin
  /f exch def
  [
    { [ 3 1 roll f {moveto} ] }
    { [ 3 1 roll f {lineto} ] }
    { [ 7 1 roll f 6 2 roll f 6 2 roll f 6 2 roll {curveto} ] }
    { [ {closepath} ] }
    pathforall
  ]
  newpath
  { aload pop exec } forall
  end
} def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 7. ROTATION + PERSPECTIVE PROJECTION
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% Transforms (x, y) -> (xp, yp)

/rotate-project {
  /y exch def
  /x exch def

  % Compute depth (z') after rotation
  y axisOriginY sub
  sin_ang_rotation mul
  z_near add
  /z exch def

  % Perspective scaling factor (depends on Z)
  /s z focal add focal exch div def

  % Transform X
  x Cx sub s mul Cx add

  % Rotate Y around axis, then apply perspective
  y axisOriginY sub
  cos_ang_rotation mul
  axisOriginY add
  Cy sub s mul Cy add
} bind def

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%% 8. RENDERING
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

0 62 translate
0.6 setgray

% --- Compute text metrics ---
newpath
0 0 moveto
texto

Get_Text_Bounding_Box
Rotation_Setup
Calculate_Focal_distance
Set_Vanishing_point

% --- Draw original text (gray) ---
newpath
0 -50 moveto
texto
show

% --- Draw perspective-transformed text (red) ---
newpath
0 0 moveto
texto
true charpath
/rotate-project ctransform
1 0 0 setrgbcolor
fill

showpage

[joa-quim]

Federico,

Maybe @remkos has some opinion on this as he knows postcript but I am skeptical that this may work. It is one thing to make a text look in a perspective way, but it is very different (I think) make a full ps file like those produced by GMT be transformed to perspectivelly. Rotation, translations and scalings cand be done with postscript operators but perspective transformations need more complex operations. And to work, they would need to operate on whatever is in the ps code that follows. Again, this just my view of the situation but Claude does not disagrees with me. Here's what it opinionated:

● Question:

  I'd like to make an image appear as if viewed in perspective. To achieve this, one would need to apply some matrix
  transformations. Would it be possible to have a suitable operator for this that could be applied generically to any
  PostScript file to obtain a perspective effect?

  Answer:

  Not directly. PostScript's transformations (translate, rotate, scale, concat) are all affine — the CTM is a 3x2 matrix (6 elements):

  [a  b]
  [c  d]
  [tx ty]


  This covers translation, rotation, scaling, and shearing, but not perspective. A true perspective transformation requires a projective 3x3 matrix where the last
  row is not [0, 0, 1]:

  [a  b  p]
  [c  d  q]
  [tx ty  1]


  The p and q terms are what create the "vanishing point" effect — and PostScript does not support them natively.

  Possible workarounds:

  1. Slice the image into strips — decompose it into N thin horizontal strips and apply a different scale/translation to each strip (strips "further away" become
  narrower). This creates a trapezoidal effect that simulates perspective. It's the classic trick in PostScript/PDF.
  2. Pre-transform coordinates — compute the perspective projection of vertices outside of PS (e.g., in a programming language) and draw with already-transformed
  coordinates. Works well for lines and polygons; not for raster images.
  3. Shear as an approximation — a concat with shearing gives an oblique projection effect (like a cavalier projection), but it's not true perspective.

[Esteban82]

Hi Joaquim,

Thanks for your feedback.

In principle, there are three types of graphical elements to which distortion could be applied: text, lines, and images. The prototype I implemented works for text and lines. For lines, the distortion could in fact be implemented directly in C, which would probably be a clean and efficient solution.

The situation with raster images is more complicated and may be quite difficult to implement. I haven’t analyzed it in detail yet. I suspect that for workaround 1 it might be feasible, but it would likely require a very large number of horizontal strips to achieve acceptable image quality.

I was thinking that workaround 2 could perhaps be implemented using raster images. My understanding is that this is essentially what the existing perspective projection in GMT already does. The challenging part would then be drawing a consistent PostScript frame that properly matches the distorted image.

That said, for now I have focused only on making perspective work for text. The rest (lines and especially images) I would consider addressing at a later stage.

[joa-quim]

Though I understand your strategy, mind you that it is a terrible waste of effort if a simpler case can be done but not the next one. Anything of this kind must work with text, lines, points and images (imagine wanting to overlay some lines on an image).

The Claude's slice idea is a kind off hallucination. That is not how GMT works. IMO, this would be a new projection (that is how GMT works) and must be dealt as such. But this leaves out texts which are not shapes (well, they are, but at the glyph level in the text fonts).

[Esteban82]

Hi Joaquim,

I think at the beginning I did not fully understand your comments, and I was probably not very clear in my replies.

I agree that implementing a true perspective transformation in GMT through the existing -p option would be very difficult. If it were done at that level, it should consistently apply to all graphical elements (raster images, lines, and text), which makes it a much broader and more complex task.

However, what I am proposing here is much more limited in scope. My idea is only to modify how text is rendered, and to implement it specifically within gmt text, using the -F option. This would not aim to provide a general perspective projection for all GMT elements, but rather a text-specific distortion that I would personally find useful.

[joa-quim]

The first 730 lines of a GMT ps file are filled with Postscript macros written for use by GMT. You cannot simply throw in in your prototype. Honestly, I still cannot see how this can work without a true projection, and not via -p which can only do affine transforms, but via -J.

[Esteban82]

Yes, I saw that. My next step is to integrate my PS code into the GMT PSL prolog so it works within that framework.