Re: 20021225 pretest
TE == Thomas Esser writes: TE * explicit encoding for Knuth's 75 fonts in map files; this helps TE dvipdfm that will make dvips-generated PS files a bit bigger (if the explicit encoding is used in dvips map file too) - so just a thought: maybe it's possible to have sriver-sprcific source map files (from which driver-specific final map files are generated)? e.g. there may be a map file inside texmf/dvipdfm/* for CM fonts with explicit encoding, and a map file for CM fonts (with the same name) without explicit encoding in texmf/dvips/*, and updmap can get the proper file to take into account such things? Best, v.
Re: 20021223 pretest
Hi Thomas, TE == Thomas Esser writes: TE Hi, I just have uploaded a new teTeX-beta release which will soon TE appear on ctan, e.g. the xdelta files for teTeX-texmf-beta and teTeX-texmfsrc-beta seem to be wrong: $ xdelta info teTeX-texmf-beta-20021216-20021223.xdelta xdelta: version 1.1.1 found patch version 1.1 in teTeX-texmf-beta-20021216-20021223.xdelta (compressed) xdelta: generated with a gzipped FROM file xdelta: generated with a gzipped TO file xdelta: output name: teTeX-texmf-beta-20021222.tar.gz xdelta: output length: 133140480 xdelta: output md5:805f25fbd6c143b7ef323b3e59cbb1d4 xdelta: patch from segments: 2 xdelta: MD5 Length Copies UsedSeq?Name xdelta: d711140cb8dd9e7f7a88bb7e006489fb 353111 10689 353111 yes (patch data) xdelta: 07312dcddfafafe51276d4fdd0e59d3b 132915200 18684 132787369 no teTeX-texmf-beta-20021216.tar.gz note that the output name is teTeX-texmf-beta-20021222.tar.gz instead of teTeX-texmf-beta-20021223.tar.gz are the xdelta files wrong, or they are correct, and you just renamed the texms and texmfsrc tarballs after making xdeltas? Best, v.
Re: Mathfrak-bug?
Hi,
Debugging shows that this bug is in amslatex, and more specifically,
in the files amsmath.sty and amsgen.sty, where they mess around redefining
the \@ifnextchar command (i don't know why they want to do that).
if you insert this into the document (e.g. just after the \begin{document}):
\makeatletter
\let\new@ifnextchar\@ifnextchar
\let\new@ifnch\@ifnch
\makeatother
then error will disappear...
Please report this to LaTeX bug tracking system (as an AMSLaTeX bug),
so they can fix the bug.
Best,
v.
On Mon, 04 Nov 2002 10:59:35 +0100
Harald Hanche-Olsen [EMAIL PROTECTED] wrote:
+ Erik Frisk [EMAIL PROTECTED]:
| below is a document that fails with teTeX-beta 20020530 (unfortunately I
| have no possibility to try the latest beta). There seem to be some
| problems with \mathfrak and AMSfonts since the text
| [2002/01/19v2.2gAMSfontdefinitions] appears in the middle of the matrix.
That seems to be a genuine AMSfonts bug, and as such has nothing to do
with teTeX. FWIW, I see the same problem with teTeX beta-20021029.
The first occurence of \mathfrak triggers the loading of a font
description file. This happens within a matrix environment, and
that environment (like so many AMSmath environments) is quite
complex. I guess it reads its contents and tries to expand macros
along the way, and that plays havoc with the file inclusion.
A workaround is to use \mathfrak before you get to the matrix
environment. For example, use it in a throwaway box:
\setbox0\hbox{$\mathfrak{a}$}
(before \begin{document} is fine). Then the problem goes away.
But you might wish to report this to the AMSfonts maintainers as well.
- Harald
CM-Super font package v0.3.0 released
Hi, the new version of the CM-Super package is finally available at CTAN:fonts/ps-type1/cm-super (currently at least the dante CTAN node contains the package installed) It contains Type 1 fonts which cover entirely EC, TC and LH fonts (see the README for more information). Compared to the similar package Tt2001 which was recently installed on CTAN:fonts/ps-type1/ec, this package * covers much bigger set of fonts (all cyrillic encodings are added, and eventually also other encodings like greek and vietnamese) * has the fonts optimized and hinted * has more exact (non-integer) glyph widths and more correct parameters like ItalicAngle, Weight, isFixedPitch, etc. * has more correct (AGL-compliant) glyph names (esp. for non-EC fonts), which makes the fonts usable in non-TeX applications, too * is more compact (contains all glyphs from one font shape combined in one PFB file -- superfont). if one will use the approach with separate files for all supported encodings, the package will be 6 times bigger in size (and in number of font files). while supporting much bigger number of glyphs than Tt2001 package, the CM-Super package is even smaller! (partially because of font optimization) * contains some additional glyph variants like german sharp s which looks like in CM fonts * includes AFM files (useful for non-TeX applications) [but Tt2001 package contains some additional non-EC and non-TC fonts which are not and will not be covered by CM-Super package] Changes from previous version: 2001-10-11 Vladimir Volovich [EMAIL PROTECTED] * Version 0.3.0 released and uploaded to CTAN. * Generated AFM metric files. * Changed lenIV to 0 to reduce font sizes (requires non-outdated Postscript interpreters). 2001-10-10 Vladimir Volovich [EMAIL PROTECTED] * Generated precise (non-integer) widths for all glyphs in PFB files to match TFM widths (using continuous fraction approximation). Corrected width of space glyph to match default TeX font space width. 2001-09-29 Vladimir Volovich [EMAIL PROTECTED] * Added glyph variants guillemotleft.cyr, guillemotright.cyr from LH fonts (french guillemets are curly, but the cyrillic ones are straight). Best, v.
Re: CM-Super font package v0.3.0 released
BKPH == Berthold K P Horn writes: * Generated precise (non-integer) widths for all glyphs in PFB files to match TFM widths (using continuous fraction approximation). Corrected width of space glyph to match default TeX font space width. BKPH It's nice to see this rather subtle and unappreciated bit of BKPH cleverness from the original BSR/YY CM fonts replicated :-) thank you. :-) BKPH Using continued fractions you can get about n + m bits worth of BKPH accuracy when the numerator and denominator have n and m bits BKPH respectively. Much better then the obvious way of dividing by BKPH some fixed quantity like 1000, where you only get about n bits BKPH worth... And of course much better than the junk fonts that BKPH just round to the nearest integer. i've added the following paragraph into the README file: It should also be noted that the fonts use precise (non-integer) glyph widths which better match the TFM widths. These widths are generated using the best approximation (based on continuous fractions) with the denominator not exceeding 107 to fit in 1 byte in CharString. Apparently, such subtle technique was used first in BSR/YY CM fonts. Best, v.
Re: CM-Super font package v0.2.0
GG == Giuseppe Ghibò writes: GG BTW. Since you used TeXtrace, and FontLab, I would like to point GG out about MF - Type1 conversion. There is another tool (although GG it has several restrictions) called mf2pt1 (on CTAN:support) GG allowing such kind conversion (resulting is more precise than GG tracing [although has overlaps] because has fewer nodes, and thus GG files shorter), yes, i know about mf2pt1, and it could not convert arbitrary METAFONT fonts, because it uses METAPOST (which does not support some features of METAFONT). GG and there is also a freeware font editor, called PfaEdit, at GG http://pfaedit.sourceforge.net, which has TWO interesting GG features: GG - 'Simplify': simplify the fonts reducing the number of GG unneeded nodes, make PFB file shorter. GG - 'Remove Overlap': remove overlaps in font paths. i used FontLab to simplify (optimize), remove overlaps, and autohint the fonts. i'm not sure that PfaEdit will give better results than FontLab. The current fonts are already quite short, e.g. they are about the same size as commercial Type 1 EC fonts provided by Micropress, Inc. This comparison was made on fonts which contain only glyphs from EC fonts, because CM-Super fonts contain much more glyphs than fonts from Micropress. And there are possibilities to make the fonts even more short, which will be used in next versions: move definitions of glyphs with the same shape into subrs, and construct accented glyphs from non-accented and accents via subrs. GG The second question is. Is there a table about choosing the GG UniqueID to be used for each of the Metafont fonts converted to GG PFB? If not how about to write one? I'll add such a table. Best, v.
Re: CM-Super package released
MS == Martin Schröder writes:
MS GPL? So anybody can distribute changed versions? LPPL please.
GPL insists that any modified versions must be distributed under GPL
(freely). Does LPPL enforce this too? (i did not find this in the text
of LPPL).
Which version of the ß did you use? The one from cm or the new
one from ec? Or both? :-)
the one from EC :)
MS :-{
MS Well, that can be fixed with virtual fonts.
the decision to use EC version is obvious: the fonts are to be a type1
version of EC/TC and LH fonts, with equivalent metrics.
if ß in CM has the same metric values, i could replace it in the
CM-Super fonts.
Best,
v.
BTW, while working on these fonts, i found a number of bugs in EC
fonts (either technical, or style, like this one with the shape of ß).
i would like to summarize these bugs and perhaps propose the changes
to the EC fonts. Could you (and others) send me all what you consider
to be wrong in EC fonts?
some examples:
* replace Tcedilla with Tcommaaccent (the former is not used)
* replace the shape of:
Euro (take from Marvosym or China2e fonts)
guillemets, numero (take from LH fonts)
ß (take from CM)
* some metrics in typewriter TC fonts are wrong
Best,
v.
