[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Groff] incorrect position of 'caron' glyph??

From: Joerg van den Hoff
Subject: Re: [Groff] incorrect position of 'caron' glyph??
Date: Wed, 08 Mar 2006 09:47:14 +0100
User-agent: Thunderbird 1.5 (Macintosh/20051201)

(Ted Harding) wrote:
On 07-Mar-06 Joerg van den Hoff wrote:
hi everybody,

I noted the following. when defining

.ds Macasek "Mac\['a]\o'\[ah]s'ek
.ds macasek "Mac\['a]\[vs]ek

one gets an optically pleasing 'scaron' (\[vs] (second line), but a seemingly slightly off-center (to the left) 'caron' (\[ah]) if you overstrike it with the letter 's' (first line).

at least if one generates pdf output and really zooms in ...

in short, my question is:



yield exactly the same as


Not necessarily. It depends:

a) If you are using a PS font which includes the s-hacek as a
   single glyph, and this is accessed, as such, from groff
   using "\[vs]", then you can expect this to be "perfectly
   formed" anyway.

b) When you use "\o'\[ah]s'" to create the composite character
   by over striking "\[ah]" with "s", then the alignment may
   not be perfect. Essentially, "\o'XY'" simply prints "X",
   then moves back and prints "Y" so that the horizontal centre
   of "Y" is at the horizontal centre of "X". While one may
   expect the metrics of "\[ah]" to be well chosen as a compromise
   for placing it as an accent to any character in a font in this
   sort of way, there  is no guarantee that it is perfect for any
   particular combination.

c) If "\[vs]" is defined as a composite character using groff
   code (like the code in the "acc" module of s.tmac -- see
   recent posts), then whether the placement of the hacek is
   perfect depends on details of the code:-- is it fine-tuned
   for this particular combination?

   On the other hand (as in the old way of making accented
   characters) the groff code is as crude as the "overstrike"
   method above, then ov course the two would be identical,
   and may or may not be good.

d) If you want "perfect" results, then ideally, when defining
   groff code for composite characters, you should define each
   character individually and fine-tune the positioning. Whether
   you need to do this for any particular composite character
   depends on how well they fit together without fine-tuning:
   you can only judge this by eye!

Hoping this helps,


thanks for clarifying this (well, to some extent...).
concerning your remark b):

I tried it simply with the 'canonical' troff font (Times Roman). in this font the accent generated by overstriking seems off-center to the left in virtually all combinations (most of them of course not useful), see attachment. maybe the metrics of \[ah] are not quite right after all? especially accents over the frequently occuring 'c' and 's' would profit from a slight shift to the right.

but anyway: thanks again.


Attachment: bin4qHQvIGb8u.bin
Description: application/applefile

Attachment: overstrike_caron.trf
Description: Binary data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]