I am having a time figuring out coordinates when using the rotation option with setfont and then textcenter. I am trying to print a barcode on a prescription label on the right side printing from bottom to top. I have set rotation to -90 and set top, bottom, left, and right coordinates for the rectangle. The barcode prints, oriented as I want.

My questions are, how do I define the coordinates and what point is the rectangle rotated about? I was a draftsman for years, but this logic eludes me . I have defined the coordinates as if the rectangle was being printed with zero degrees rotation, then adding the -90 degrees, but not getting what I expected. Really I don't know what to expect.

Obviously it doesn't quite work as "expected" (regardless of what that might mean). The centering logic is failing to fully take into account the rotation (or "escapement") of the font. But it seems to be partially taking it into account (to the extent that it seems to recognize that the string will be narrow, but not that it will be tall). And on top of that, it seems to act as if there is a space at the beginning of the string.

It seems correct, though, that the rectangle coordinates remain un-rotated.

Theoretically we could adjust for the rotation, at least in the single line mode case. I guess I'll look into that. But if you need a quick workaround, trial and error may be the most expedient. Otherwise, in theory you could use MX_GDICALC with the MXGDI_CALCRECT opcode, starting with the non-rotated font, and then rotate the coordinates yourself (to get the starting position) and reset the font to the rotated mode.

I guess I sort of expected with a rectangle that the rotation would take place around the lower left corner. When I try the above scenario with the the new textrectangle that is obviously big enough no matter how the rotation takes place, I get nothing with -90 degrees. With 0 degrees, it prints corectly. In both cases I set the flags parameter to (trf_hcenter or trf_vcenter or trf_wordbreak).

With textcenter, I suppose I expected it to again rotate about the lower left corner.

I'm really not sure if it is expected to leave the right, left, top, and bottom coordinates the same with rotation and without. In other words, a wide, short rectangle at 0 degrees becomes tall and narrow at -90 degrees or +90 degrees and would print upside down at 180 degrees? So to move a rectangle to the left at -90 degrees, would you set the top and bottom to a smaller number?

I think I'll make this work in 1235.3, but probably only for rotations of 90 and -90, and only in trf_singleline mode. The complication with multi-line mode is that it requires a fancier WIN32 API function (the one used to implement the various trf_xxxx options), but that function doesn't handle rotated text very well (as you've seen). I easily simulate centering of a single-line of text though (provided it actually fits in the box).

I've got to take off early this afternoon, but I'll work on that over the weekend.

No need for the weekend work on this. It is a few week project for me to finish. By the way, I can use either textcenter or textrectangle for this and trf_singleline is fine. Thank you.

Ok, I think this works now (limited to single line mode and multiples of 90 degree rotation) in 5.1.1235.3

Here's a sample text file, TEXTRECTR.TXT , which prints like this:

I have tested the -90 rotation and works great. Responds correctly to my 25/1000ths of an inch movement and centers nicely. Thank you for your time.