first impressions

[stubner]

Hello,

I have used my thesis in theoretical physics as test for MTPro II (version from 2006-03-13). I had to change almost nothing in the sources, and the output looks, in general, good. Some intial comments about details:

In expressions like
$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

Similar for the distance behind the prime in
$\varepsilon,\varepsilon',\omega$.

I find it unfortunate that one needs the option 'subscriptcorrection' to get things like
$\varepsilon_{j},\varepsilon_{k}, \varepsilon_{l}$
to look 'right'. Why is that needed?

$ij$ is wider than in CM or Pazo, $\mathit{ij}$ would be to narrow. This has the effect that some of my equations are wider with MTProII than with Pazo. ;-)

$\tilde{\omega}$ looks off-center to me.

Some minor comments concerning the LaTeX package:

Why is \mathbold only available with 'boldalphabet' option?

Why is \rmdefault not set? I understand that MTPro can be used together with different text fonts, but how about an option 'rmdefault' to set \rmdefault to ptm? Or maybe a keyvalue based interface. Just using 'rmdefault' sets \rmdefault to ptm, while rmdefault=foo sets \rmdefault to foo.

One final question: Is it possible to define a command that gives 'bold' math when used in 'normal' context but 'heavy' math when used in 'bold' context? Something like a 'make bolder command'.

cheerio
ralf

[schleg1]

...

Why is \rmdefault not set? I understand that MTPro can be used together with different text fonts, but how about an option 'rmdefault' to set \rmdefault to ptm? Or maybe a keyvalue based interface. Just using 'rmdefault' sets \rmdefault to ptm, while rmdefault=foo sets \rmdefault to foo.

It is in general a problem when a math-package unconditionally defines an operator font as it happens in mathpazo: you cannot define an alternative operator font without changing source code inside the package itself (or there might be no transparence about what else might happen).

One final question: Is it possible to define a command that gives 'bold' math when used in 'normal' context but 'heavy' math when used in 'bold' context? Something like a 'make bolder command'.

A typical scenario is that there is the need for a bold/"bolder" scheme in section titles: the title is printed in bold (not at all places, depending on the styles used, like running heads and toc) while bold elements like vectors should be heavy.
So I think it would be plausible to have such a capability to switch mathversions locally.

Best,
Hilmar
###

ralf

[Michael Spivak]

Hello,

In expressions like
$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

Similar for the distance behind the prime in
$\varepsilon,\varepsilon',\omega$.

cheerio
ralf

What do you mean by "behind". Do you mean to the left or to the right?

[WaS]

I find it unfortunate that one needs the option 'subscriptcorrection' to get things like
$\varepsilon_{j},\varepsilon_{k}, \varepsilon_{l}$
to look 'right'. Why is that needed?

???
Because TeX can' t control that via font metrics alone. (Mike ?)
Or are you asking why subscriptcorrection is not enabled by default?
Doing so would be too dangerous, because the underscore character
needs to be made active; this may clash with other things.

[...]Why is \mathbold only available with 'boldalphabet' option?

Because it needs to change the math family of the lc Greek letters to
mathalpha, and there are documents and macros around which do not
like that.
I -- personally -- prefer the use of \mathbold over \bm, but the latter
seems to have become the canonical solution, so I have implemented
\mathbold only as an option.

Why is \rmdefault not set?[...]

Well, I just think that the present behavior is clear and easy to
understand (and so far noone has asked me to change it ;-)
I agree that a full-blown key-value interface would be nice, but it would
also break the compatibility with the previous version. Of course,
I could do that; the decision is up to PCTeX Inc.
A new kv-option for the roman font family only, with the other options
remaining unchanged, is not a resonable solution, IMO.

One final question: Is it possible to define a command that gives 'bold' math when used in 'normal' context but 'heavy' math when used in 'bold' context?

No. (Note that the issue is in no way specific for MT-Pro!)

[PTIForAdmin]

Why is \rmdefault not set?[...]

Well, I just think that the present behavior is clear and easy to
understand (and so far noone has asked me to change it ;-)
I agree that a full-blown key-value interface would be nice, but it would
also break the compatibility with the previous version. Of course,
I could do that; the decision is up to PCTeX Inc.
A new kv-option for the roman font family only, with the other options
remaining unchanged, is not a resonable solution, IMO.

What is a full-blown key-value interface?

What are the compatibility issues with mtpro1? Is this a useful enough feature to justify the incompatibility?

[Michael Spivak]

Hello,

I find it unfortunate that one needs the option 'subscriptcorrection' to get things like
$\varepsilon_{j},\varepsilon_{k}, \varepsilon_{l}$
to look 'right'. Why is that needed?

cheerio
ralf

For a discussion of this see

http://support.pctex.com/files/JWPXMWRZTYLV/try2.pdf

[murray]

...What is a full-blown key-value interface? .../quote]

Presumably like the options to the LaTeX graphicx package as contrasted with the graphics package.

[stubner]

$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

Similar for the distance behind the prime in
$\varepsilon,\varepsilon',\omega$.

What do you mean by "behind". Do you mean to the left or to the right?

I meant to the right, ie, IMO the distance between 'i' and '\omega' or 'H' is a bit to large. Similar for the distance between the prime and the comma.

cheerio
ralf

[stubner]

I find it unfortunate that one needs the option 'subscriptcorrection' to get things like
$\varepsilon_{j},\varepsilon_{k}, \varepsilon_{l}$
to look 'right'. Why is that needed?

???
Because TeX can' t control that via font metrics alone. (Mike ?)

The PDF file try2.pdf does explain this very nicely. Especially, why this is needed with MTProII but not with CM. Thanks!

Or are you asking why subscriptcorrection is not enabled by default?
Doing so would be too dangerous, because the underscore character
needs to be made active; this may clash with other things.

I can imagine that it might clash with other things. However, without this option enabled, using things like 'j' in a subscript looks unacceptable to me. IMO using this option should be strongly recommended in the documentation. The current section 2.10 is IMO not strong enough. Maybe because with \varepsilon the effect is much stronger than with C?

Even better would be to have it on by default but provide an option to turn off the subscript correction.

Why is \rmdefault not set?[...]

Well, I just think that the present behavior is clear and easy to
understand (and so far noone has asked me to change it ;-)
I agree that a full-blown key-value interface would be nice, but it would
also break the compatibility with the previous version.

I don't think it is necessary to break compatibility. If the hypothetical option rmdefault is not used, the behaviour could be the same as it is now.

A new kv-option for the roman font family only, with the other options
remaining unchanged, is not a resonable solution, IMO.

You mean an interface for \rmdefault without one for \sfdefault and \ttdefault doesn't make sense? I am not sure if I agree with that. It would, however, make such an interface rather complicated, since options for scaling the fonts wrt each other would be useful then.

One final question: Is it possible to define a command that gives 'bold' math when used in 'normal' context but 'heavy' math when used in 'bold' context?

No. (Note that the issue is in no way specific for MT-Pro!)

Indeed, this is not an MTPro issue. However, MTPro provides heavy math (is there any other font that does that?). Such a command would make this heavy math usable. Typical use case is as Hilmar described. To bad, if this is not possible. IMO this would be a 'killer feature' ...

cheerio
ralf

[Michael Spivak]

One final question: Is it possible to define a command that gives 'bold' math when used in 'normal' context but 'heavy' math when used in 'bold' context?

No. (Note that the issue is in no way specific for MT-Pro!)

Indeed, this is not an MTPro issue. However, MTPro provides heavy math (is there any other font that does that?). Such a command would make this heavy math usable. Typical use case is as Hilmar described. To bad, if this is not possible. IMO this would be a 'killer feature' ...

cheerio
ralf

Remember that there really isn't ``heavy math'', because there aren't heavy letters(!), so one couldn't make a vector bold x heavy. The heavy math option was really designed for something completely different, as described, to make the distinction between ordinary plus and a bold version more distinct, in cases where both are being used together. Of course, one
could also simply ask for heavy letters also (and I guess even heavy versions of the math bold!). That could presumably also be added, but
not for this release!---it would take quite a long time to do (I have to
admit that having heavy letters is a fairly attractive idea, especially
heavy greek).

[Michael Spivak]

$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

Similar for the distance behind the prime in
$\varepsilon,\varepsilon',\omega$.

What do you mean by "behind". Do you mean to the left or to the right?

I meant to the right, ie, IMO the distance between 'i' and '\omega' or 'H' is a bit to large. Similar for the distance between the prime and the comma.

cheerio
ralf

OK, I will reexamine all the kerns of i with other symbols. You might also want to look at the listing about fine tuning kerns.

[zedler]

I don't think it is necessary to break compatibility. If the hypothetical option rmdefault is not used, the behaviour could be the same as it is now.

How about this one?

\documentclass{book}
\usepackage{times,amsmath}
\usepackage[subscriptcorrection]{mtpro2}
\begin{document}
$a_\text{eff}$
\end{document}

Michael

[Michael Spivak]

Hello,

In expressions like
$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

ralf

I'm sending you a new tfm file; see if it helps!

[stubner]

Hello,

In expressions like
$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

ralf

I'm sending you a new tfm file; see if it helps!

I'm sorry for the late reply. Only this evening I have found time to test this TFM file (and version 0.991).

The good news first: $\tilde{\omega}$ looks really good now. Thanks!

Unfortunately, I don't see much improvement with the above mentioned sequencies. Each indivdual pair looks fine, eg, $-i$, $i\omega$ and $\omega t$ look good. But similar to kerning letter pairs and looking at real words afterwards, the combination might be not optimal.

Does anybody else see a problem with these combinations? If I am the only one who sees a problem here, it might not be worth putting much energy into it.

cheerio
ralf

[Michael Spivak]

Hello,

In expressions like
$-i\omega t$, $e^{i H_{0}t}$, $e^{-i H_{0}t}$
the distance behind the 'i' is a bit large IMO.

ralf

I'm sending you a new tfm file; see if it helps!

I'm sorry for the late reply. Only this evening I have found time to test this TFM file (and version 0.991).

The good news first: $\tilde{\omega}$ looks really good now. Thanks!

Unfortunately, I don't see much improvement with the above mentioned sequencies. Each indivdual pair looks fine, eg, $-i$, $i\omega$ and $\omega t$ look good. But similar to kerning letter pairs and looking at real words afterwards, the combination might be not optimal.

Does anybody else see a problem with these combinations? If I am the only one who sees a problem here, it might not be worth putting much energy into it.

cheerio
ralf

I admit that the triple i\omega t is not optimal, but I strongly suspect that if you look carefully at any mathematical typesetting (as opposed to just reading it as math), then you will find tons of such non-optimal triples, and even non-optimal pairs (for example, i\omega is pretty bad in CM).
The only thing I really dislike is the H_{0}t (the formula $-iH_{0}t$
doesn't look to bad, but in a superscript the t is awfully close to the 0 (although, again, in superscripts it's much less important to worry about the kerning, and much more important to worry about the legibility of
the individual characters). The H_{0}t is actually a rather special case,
reflecting the fact that the subscript 0 is an unslanted characters, and these tend to cause problems when they appear in the midst of slanted ones [see the posting about (\mathrm j ]

I think for now it would be pointless to try to fix every special case that comes up, since who knows how many others could arise in the future.
I would rather leave all this to a future release. I am trying meanwhile
to figure out how to make a program that would do a good job of kerning automatically. (Fontographer has such a feature, but although it allows
more than one way of determing kerning, no choice really leads to very
good results. A long time ago I heard that Compugraphic had a program that did this on their machines, and that they were very proud of this [as
they well might be].)