Same thing here. Seems like the difference increases dramatically as the degree of slant increases. At more typical italic slants (12-15 degrees), it's still there, but just slightly. It may be that the interactive slant tool reports the angle value incorrectly.

If I use the transform panel to slant a rectangle 30°, slanting it -30° will put it upright again (nearly so--there appears to be a rounding error). If I put it upright using the slant tool, it reports the angle as 35.23°. If I undo and apply that angle with the transform panel, slants it past upright, just as with your example.

I mentioned that rounding error when using the transform panel to slant it back to upright. The error increases if I slant it back further than upright. Starting from a rectangle slanted 30°, here are the results I get if I slant it backwards again by various amounts:

(The values in the first three columns are in degrees.)

This isn't directly related to the problem you are having, but it might be relevant.

On a related note, has anybody else noticed that the angle measurements for selected segments reported at the top of the glyph palette tend to be incorrect?

I get what I presume is the same problem in the Windows version. The manual slant tool meter is inaccurate. Funnily, I've never noticed this before because I only ever use the manual slant tool when I want a purely visual adjustment and don't actually care about the angle. If I want to slant something a particular number of degrees, I always use either the transformation palette or Tim Ahren's RMX Slanter script.

Hmmm, are we sure the transformation palette isn't messing up too?

(BTW, yet another reason to avoid non-sensical
degrees and stick to grid-savvy integer slopes! :-)

hhp

@JH, Funnily, I've never noticed this before because I only ever use the manual slant tool when I want a purely visual adjustment and don't actually care about the angle.

My normal mode is to slant interactively, and then, once I'm happy with a few glyphs, capture the interactive slant angle, slant the whole repertoire required and then adjust individual glyphs for optical conformity.

@HP, (BTW, yet another reason to avoid non-sensical degrees and stick to grid-savvy integer slopes! :-)

I thought I already said "There is no Slanta Claus!"

Or do you think there really are some angles that are better than others for smaller grids?

Since digital type is all on a grid, a slope of 1/n where
n is an integer is what makes sense. An integer degree
slope produces erratic stair-steps, with no benefit.
Degrees have basically become a dysfunctional legacy.
There's also something else: when you're editing a font
and you have to move a point, you know that for every
unit of horizontal movement there must be a vertical
shift of n.

BTW, for onscreen type the grid is so coarse that
each point size benefits from having its own slope!

In Patria (which influenced Ernestine) the slope of the
Italic is 1/16, which is about as slight as I think one
should go; it's ~3.6 degrees. I could have chosen 1/15,
but the nice things about 16 are that: being a power of
2 it can be halved all the way; and at 12 pt (on Windows)
you get precisely one step (in the middle). Sometimes. :-)

hhp

@Hrant - "BTW, for onscreen type the grid is so coarse that
each point size benefits from having its own slope! ...Sometimes. :-)"

Even if you could find the perfect italic angle for each size that works all the way from the ascender to the descender hitting integer pixels at the baseline and the x-ht, you cannot make the diagonal strokes of an italic, which require many angles to cover K, S, V, W, X, Y and Z e.g., step evenly. These diagonals will stand out with uneven stair steps relative to the idealized per ppm italic slant you are promoting.

Bitmaps are no longer in the mainstream of screen font technology, but if you are doing a Baskerville outline font for Google, you'll finally have to face this issue and present a solution to the real world.

> you cannot make the diagonal strokes of an italic

Until you wrote that I would have actually agreed :-) but
now that you've made me think about it more, might it
not in fact be possible to find some 1/integer slope for
each one of those elements? Maybe not. But in any case,
stems are king; the Latin alphabet (especially the UC)
is primarily built on a stem-plus-"augmentation" strategy.
In case anybody really needs academic backing to believe
this, they could consult "Canons of Alphabetic Change"
by W C Watt, in "The Alphabet and the Brain" (1988).
But it's pretty obvious anyway.

> you'll finally have to face this issue
> and present a solution to the real world.

Or do what so many others have been doing: give
up and pretend what I've made is satisfactory.

hhp

David: ...capture the interactive slant angle...

The workaround for the bug is to use the measuring tool to capture the resulting slant angle, rather than relying on the feedback from the Free Transform tool. This seems to be accurate, albeit recorded in the measurement panel as a value relative to the horizontal (e.g. a 14 degree right slant off vertical is recorded as 76 degrees).

In Windows FL, a right click drag with the measuring tool will give you the option to insert an angled guideline following the line of drag. You can then check the properties for this guideline to get the angle.
_____

Hrant, I agree that being able to specify slant in terms of rise-over-run em unit integers would be a good feature in font tools. There will still be rounding errors, however, due to varying vertical distance between points, which will not always snap to multiples of the rise value.

> will not always snap to multiples of the rise value.

True. One nice think I/to do though is make the key
guides (like descender, x, ascender, cap) multiples of
the integer. Plus when I'm really close to the integer
I can snap to it and gain some confidence & accuracy.

hhp

@JH - "...varying vertical distance between points, which will not always snap to multiples of the rise value."

Not to leave out the fact that a well-designed typeface requires a variety of runs (angles), and side bearings for optical consistency. Snapping to multiples here is hopeless without both x and y hinting.

@JH - "...In Windows FL, a right click drag with the measuring tool..."

I don't use FL, but thanks for the tip!

@HP - "stems are king; the Latin alphabet (especially the UC)
is primarily built on a stem-plus-"augmentation" strategy."

I think there is no such thing as a dominant, "king" feature in type. There is background, beat (the main stems) and variety. And the beat itself, likes variety in the angles... and the variety in angle, one of the largest parameters to vary, shows up as a pixel difference early in the ppm spectrum relative to spacing, stem thickness or alignment varieties.

@Mark Simonson: The error increases if I slant it back further than upright. Starting from a rectangle slanted 30°, here are the results I get if I slant it backwards again by various amounts:

This is to be expected; the angles from consecutive slantings in general do not add. In fact, a slanting by theta and then a slanting by phi will result in a slanting of arctan[tan(theta)+tan(phi)]. The data in your table agrees very closely with this formula. The one oddness is slanting by 30 and then by -30 should return the shape to vertical. I'm assuming that the error you report is due to rounding to integer units after the first transformation; the error is too large to attribute to inaccuracy of floating point arithmetic.