From Beat...
Hm... S45ROUND happens to be one of my "dusty corners..." I don't recall ever having used it. But here's what I've just tried:
I twisted an Arial fw slash into the shape I understand is the one you're working on. Then the following low-level code would take care of keeping the line 3 => 2 parallel to line 0 => 1 at a diagonal distance that is an integer multiple of 1 pixel:
Inline("
SPVTL[R], 0, 1
SFVTPV[]
SRP0[], 0
MIRP[m>RBl], 3, 68
SRP0[], 1
MIRP[m>RBl], 2, 68
")
This moves points 2 and 3 perpendicularly to the line 0 => 1 to maintain the (perpendicular) distance. Since the MIRP is rounded, we get full pixels, and we use a cvt (68 in this example).
You may want to put the line 0 => 1 to the grid first. I've done this as follows:
/* VTTTalk glyph 18, char 0x2f (/) */
/* GUI generated Mon Feb 25 18:28:38 2002 */
/* Y direction */
YAnchor(0,8)
YShift(0,3)
YLink(0,1,2)
YShift(1,2)
/* X direction */
XAnchor(0)
XShift(0,3)
XLink(0,1,2)
XShift(1,2)
Basically, this anchors everything else to point 0. If you move point 0, everything else should follow in sync. I've used cvt 2 to link from 0 to 1 in both x and y direction, to force that distance to keep a 45° angle. Then I'm shifting points 3 and 2 along to establish the precondition upon which the inline code expects to work. Finally the inline code does the diagonal distance. At that point we've touched just about every control point, so there is no more need for a Smooth().
Notice that points 3 and 2 may be off by ±1/64 of a pixel. I think this is a case of "accumulated round-offs" in the rasterizer, as the rasterizer couldn't possibly guess what we're trying to do.
I'm not completely sure though whether this is the best way. It sure produces perfectly regular pixel patterns for the given (perfectly regular) outline. But the detail I'd be a bit concerned about is that it gets me a row of pixels along the line 0 => 1. The reason for this is, in TrueType a pixel is turned on if its center is in or on the outline:
If you don't like this, add e.g. XDelta(0, 1/64 @ 
right before the inline code (where 8 happens to be the ppem size). That's the point at which the engineer usually gives up and leaves it to the typographer or graphic designer to decide :-)
As far as choosing cvts is concerned, if it's a strictly mono-line font, then one cvt for all strokes is probably enough. However, the GUI expects separate cvts for x and y, so if you want to use the GUI (at least up to the point where you insert the low-level code), you might have to come up with a simple inheritance tree. Maybe define the grand-parent cvt (e.g. #65) to hold the stroke weight, and then equate your straight and round strokes in x and y to it, e.g. the uc black x straight stroke:
UpperCase
Black
X
StraightStroke
68: 200 = 65 @ 255
where for 200 you'd put the actual stroke weight, and for 255 the ppem size at which the uc black x straight stroke "breaks free" from the parent. Like this, if at some ppem size all strokes are too thin or too thick, you can just add a delta to cvt 65 and everything should be fine again.
Last but not least, it appears that dialog boxes don't quite "fit in" when we choose "large fonts" in the Windows display settings. For fonts we have hints to make sure things "add up" after scaling; however, for dialog boxes there are no hints, hence things sometimes don't quite add up.
Hope this helps
Beat
