[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments on 0.56
- To: firstname.lastname@example.org
- Subject: Re: Comments on 0.56
- From: Matthias Clasen <email@example.com>
- Date: Tue, 13 Jan 1998 16:22:17 +0100
- Cc: firstname.lastname@example.org
> Following the new release, I've just updated the links on the working
> group homepage at www.tug.org.
> Now for some observations concerning the new release.
> 1. The new markers:
> Although, the new markes are potentially nice idea if you insist on
> coveying the meaning unambiguosly, I personally find them a little
> too distracting to work with, especially if there are several rows of
> missing glyph markers, e.g. if the lowercase upright Greek is missing.
> An additional problem is that you add a dependency of scalable fonts
> on a size-dependant MF font which provides the markers, while the
> black boxes were generated by glyph rules at the DVI level.
Yes this was also my concern, but I think I'm following Thierrys
argumentation here: If they show up in print, they *should* be distracting,
because something is wrong. Also I'm only using one design size for the
markers: All fonts use markers10. For font (not encoding) tables, it
would probably be best to leave the places empty, but I don't think there
is a way to achieve that from within TeX.
> I might be prepared to use the new markers for the EuroTeX paper for
> clarification, but I would prefer to return to black boxes otherwise
> (and preferably a bigger box for the few control glyphs and a smaller
> one for those many missing glyphs.)
> 2. The new filenames:
> Using lowercase filenames for everything is apparently the politically
> correct solution for the current LaTeX, but now I'm finding myself
> getting lost in the etx and mtx directories, if the old msam, msbm
> is sorted between the new MS1, MS2, and MSP. I'd suggest introducing
> some subdirectoires below etx and mtx, along the lines
> etx/generic (8r, ot1, t1, oml, oms, omx)
> etx/ams (msam, msbm, lasy)
> etx/euler (eufrak, euscr, euex)
> etx/symbol (psy, psyupright, psyitalic)
> etx/mma (math1, ..., math5)
> etx/mathime (my1mtmi, my2mtsy, my3mtex, ...)
> etx/lucida ...
> etx/newmath (mc, mcraw, mcin, msp, mspraw, mxp, mpxraw, mxpvar)
> mtx/sizes (size1000, size0900, ...)
> mtx/generic (8rto8ritalic, ot1toot1upright omstomsam, ...)
> An alternative arrangement would be mtx/newmath, mtx/symbol, mtx/mma,
> mtx/mathime, mtx/lucida, etc. It remains to be seen what is easier
> to manage.
Yes, we should try something like that.
> 3. The distribution:
> - The lasy subdirectory contains files called blasy5, ... blasy10.
> Could these be renamed to lasyb5, ... lasyb10, so that they will
> get installed under pk/<device>/public/latex rather than udner
> pk/<device>/bitstream/unknown by MakeTeXPK?
That should be easy.
> - The bex and bams subdirectories both contain msamb10, msbmb10?
> Which version is the correct one? (bams contains sizes 5..10,
> but bex is newer)
Don't know, I'll have to check.
> 4. The documentation:
> There is a still a problem with the gray area in the font tables in
> bigdoc.dvi. I've resent the patch for bigdoc.tex and fontchart.tex
> to Matthias which I've posted here shortly after the last release.
> Anyway, I've installed a modified version of bigdoc.tex at ww.tug.org.
> Given the new layout-<whatever>.dvi files, I wonder if the font tables
> in bigdoc.dvi are needed at all, or whether each of the layout.dvi
> files now represents a chapter of bigdoc.dvi.
One line in my todo list actually reads: `Update bigdoc'.
Currently we have more or less
- newmath.dtx/.fdd: Dokumentation of the LaTeX interface
- layout-<whatever>: Font charts for each layout
- bigdoc: Dokumentation on the Encodings and
Design goals, decisions and more
While newmath.dtx/.fdd is OK (I guess), layout-<whatever> is just
a half-an-hour hack to get font tables for each layout in this release.
bigdoc has been neglected for some time and will need an update.
> Yet another problem is that the layout.dvi files are generated
> automatically for all font tables, including those that are
> non-existent in a given math layout. I suppose a better solution
> would be to modify the LaTeX interface, so that the unavailable
> versions of e.g. MS1, MS2 and MX1 in mathptm or concrete/bold
> would be mapped to a dummy font rather than having the CM layout
> silently substituted. Why not use the AMS "dummy.tfm" for this?
>From a usability standpoint, wouldn't it sometimes be better to have a symbol
from cm (even if it isn't a perfect match) than no symbol at all ?
And would using dummy.tfm solve the table-generation problem ?
I guess you would just get empty tables, no ?
I'll have to think about that.
PS I didn't look at the new Mathematica package yet. Does it have
an extensible font? If so, a comparison to xsb would be interesting.
Institut fuer Mathematik, Albert-Ludwigs-Universitaet Freiburg