On 7/25/07, Michael Droettboom <[EMAIL PROTECTED]> wrote:
> The new mathtext with an underlying TeX-like box model is passing all
> unit tests for all backends. I'm now at a point where I'd like to merge
> this back into the trunk, but I'd like some feedback as to how to best
> deal with the backward-incompatible change wrt font changes.
This is really, really cool stuff. On a mostly unrelated note, do
you thing the TeX box layout algorithms could be used to solve more
general figure layout problems, eg positioning axes and tick labels,
etc?
> (This was discussed in an earlier thread, but I don't believe a
> conclusion was reached, so I'm summarizing again here.) In the existing
> mathtext implementation, font style changes affect the following group.
> For example, in $\cal{R} x$, only the R will be in calligraphic face.
> In TeX, however, font style markers stay in effect until the next font
> style marker or the end of the enclosing group. Therefore, the same
> example would be rendered with both the R and the x in calligraphic
> face. The new mathtext adds LaTeX-style font macros (\mathcal, \mathrm
> etc.) that behave as the old mathtext ones. So the example expression
> could be re-written $\mathcal{R} x$. It's difficult to trap the old
> case and correct for it, since both are still valid.
>
> Becoming more TeX-like is a good thing, but does breaking existing
> matplotlib plots warrant some additional care here? Should this be
> merged into trunk, or onto some other branch where we're going to be
> breaking a lot of things. It is probably feasible to have a
> "compatibility" mode for this, but is that (in this particular case)
> worth the extra maintenance burden?
I think we should strive for TeX correctness and should not support
the incorrect usage in a
compatibility mode. The improvements you've made are sufficiently
important that mathtext users will gladly accept a little breakage.
We can put up a news flash on the main site, and note the changes in
the CHANGELOG and API_CHANGES file, as well as in the mathtext_demo.
I have a few questions about the mathtext_demo.py. A number of these
are probably just related to the bakoma fonts, which are just so
horrific it pains me to look at them (like why is the s in sin so much
lighter?)
* The i in the {i+1} subscript looks too small. It also looks to
small compared to the j in the \Delta_i^j example. Are the i and j
coming from the same file, and do you have any idea why it is small?
* There is a lot of space between the \prod symbol and the rest of
the expression and between the \mathcal{R} and the \prod symbol --
what controls this? It looks like it is being affected by the wide
\prod subscript {i=\alpha_{i+1}} -- is this correct and is this how
TeX handles it? Since the subscript is under the prod, it seems like
it's width should not affect the spacing of the R and the sin
* Have you given any thought to the "cross font" kerning problem.
Eg, if the parens comes from one file, and the 2 from another and the
\pi from a 3rd, how to we kern "( 2 \pi )?
* have you succeeded in get any non bakoma fonts to work, eg with the
UnicodeFont code?
Anyway, this is really great stuff. Thanks!
JDH
-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
