27 |
The height needs to be passed in a coordsys to enable interpolation |
The height needs to be passed in a coordsys to enable interpolation |
28 |
(very desirable). Also, the origin of the text, and the direction. |
(very desirable). Also, the origin of the text, and the direction. |
29 |
|
|
30 |
The solution is to pass these three (origin, direction, height) |
The solution is to pass nothing about what should be done to the width |
31 |
in one coordinate system and the "aspect ratio" in another. |
of the string, but simply the unit square of the font. I.e.: the |
32 |
|
font will have its normal aspect ratio if the distances |
33 |
Thus: |
(0,1)..(0,0) and (0,1)..(1,1) are the same. |
|
|
|
|
Two coordinate systems are passed. The second will correctly default to zero. |
|
|
The first coordinate system determines the height of the text and its location |
|
|
on the screen. The second coordinate system determines the aspect ratio and the |
|
|
direction in which the text continues. |
|
|
|
|
|
(Benja:) I don't like this... I think the first coordinate system |
|
|
should determine the aspect ratio (because changing the aspect ratio |
|
|
should be handled through transformations). What's the problem anyway? |
|
|
Let's say we want a strip of text with height 10. We create a scaled |
|
|
coordsys, x scaled by 10 and y scaled by 10. If we want to have |
|
|
a different aspect ratio, we set x to something different (or we create |
|
|
a sub-cs that has x scaled but not y, and put the text into that). |
|
|
|
|
|
Also, for AWT, we need a method to look up the best point size for |
|
|
a given height, in order to implement this right: that is part of |
|
|
implementing this peg. (Will need a table-driven approach, most likely.) |
|
|
|
|
|
With these changes/additions, I'm for accepting this PEG. |
|
|
|
|
|
Algorithm:: |
|
|
|
|
|
a = cs1(0,0); b = cs1(0,1); # Convert left edge of text bbox |
|
|
topleft = cs2^-1(a); bottomleft = cs2^-1(b); |
|
|
textdir = (topleft - bottomleft).clockwise90() |
|
|
|
|