Re: listings.sty is missing?
On Sat, 15 Mar 2003, Atsuhito Kohda wrote: I noticed that listings package was back in tetex 2.0.2 but listings.sty itself seemed missing at present. ... But, curiously, listings.sty was in texmfsrc. civic:~/misc/pack/teTeX/ORIG$ tar ztvf tetex-texmfsrc-2.0.2.tar.gz | grep listings.sty -rw-r--r-- root/root 66101 2003-02-20 05:48:13 source/latex/listings/listings.sty Is this some mistake? Sadly, if you're reading that mailing list and you are also Debian developer, I wrote about it yesterday. Just move listings.sty to the proper location. One bad Thomas' keystroke should be no more mentioned. -- Staszek Wawrykiewicz [EMAIL PROTECTED]
Re: ANN: teTeX-2.0.2
As for tetex-2.0.2 * remove g-brief: it is not free software it would be also wise to remove from texmf/texdoctk/texdoctk.dat: g-brief;Alternative german letter style (g-brief);latex/g-brief/g-brief.dvi; (2 occurences), thought German friends could be unhappy... -- Staszek Wawrykiewicz [EMAIL PROTECTED]
Re: europs.sty in 2.0(.1)
George White [EMAIL PROTECTED] wrote on 21 Feb 2003 Larger organizations (government, big companies) require that certain documents conform to standards, which may well include a particular font for the euro. Times-Roman, etc, aren't distributed with teTeX, but they (or some facsimile) are commonly found on many popular systems, so it makes sense that TeX support them. Please take a look and find that Times-Roman *is* already supported in TeX in various ways: 1. dvips and pdftex can use Times-Roman available for the devices (printers, typesetters, Acrobat Reader); 2. teTeX, fpTeX, TeX Live, MiKTeX distributions already contain Times-Roman like fonts thanks to URW++ (they are GPL licensed, and used when embeding of the font in the output is demanded); 3. As for now the euro sign is not included in the Adobe standard encoding, nor in the Adobe's standard fonts set. I'm not in a position to know how organizations across the pond support the euro, but if there is a Type 1 font that is commonly installed beside Times-Roman, then it makes sense for a new TeX to make it easy to use them. The other consideration is whether it is easier to make europs just work for systems that have the font or to explain why it doesn't work. Well, I don't like to burden the latex oriented community, but we have in the all above distributions qfonts package which contains the euro glyph in 128 dec for times, helvetica, courier, bookman like fonts, compatible for those provided by URW++. As those fonts are also GPL licensed, anybody can feel free to adapt them to make just work as you would like. -- Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: Quick question regarding -src-specials
David Kastrup wrote: Are there any specific releases of teTeX-beta and/or TeXlive that one could recommend as not being afflicted in that particular manner? Thomas Esser replied: I think that only the first versions of TeX Live 7 are affected. The programs identify themself with a web2c-version that ends up with x, 7.3.7x I think. As concerned TL7, it is still: This is TeX, Version 3.14159 (Web2C 7.3.7x) I think it is intentionally, so we have the same binaries for all (GUST, TUG, DANTE, TUG2002, CSTUG CD TeX Live 7 releases). -- Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: Font problem or not?
26 Nov 2002 Reinhard Kotucha [EMAIL PROTECTED] wrote: Staszek Wawrykiewicz [EMAIL PROTECTED] writes: It seems somehow strange. Why both map files differ? As I understand the whole mechanism, different map files for dvips and pdftex are only needed when we use fonts from the standard set for PostScript devices (35 Laser Writer fonts) or for .pdf files (Acrobat Reader has 14 builtin fonts, a subset of 35LW). For all other fonts the map files should be the same: In pdftex.map the internal PS /FontName should be omitted. If you include an external PDF file which, say, uses the font /Palatino-Roman, the current version of pdfTeX tries to substitute the font. It looks in pdftex.map for Palatino-Roman, but it does not check whether the font is transformed and might fetch the wrong one. The primary thread was about nonstandard (vendor's) font installed by the user, so my reply as above. [by the way, I sent it on 31 Oct, but it was published on Nov 25 ?]. Your message is however interesting: do you mean that pdftex.map should contain for future pdftex, say: ptmr8r TeXBase1Encoding ReEncodeFont 8r.enc (internal PS /FontName omitted)? As for now only transformed constructs can work, e.g.: ptmbo8r .167 SlantFont TeXBase1Encoding ReEncodeFont 8r.enc utmb8a.pfb but they need explicite information which font program is to be transformed (utmb8a.pfb), so cannot be applied to the builtin fonts. Am I wrong? The whole mess about fonts, maps, etc. is still waiting for a good explanation/road map. As I've observed, the users always cannot understand it (not counting that mailing-list members ;-) -- Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: Font problem or not?
On Tue, 29 Oct 2002, Richard Sperling wrote: ... I'm using the 10/13/02 teTeX beta and I've got purchased type1 fonts that I wish to use with latex and pdf(la)tex. The vendor supplied two map files that (obviously?) differ slightly: one for dvips and one for pdftex. It seems somehow strange. Why both map files differ? As I understand the whole mechanism, different map files for dvips and pdftex are only needed when we use fonts from the standard set for PostScript devices (35 Laser Writer fonts) or for .pdf files (Acrobat Reader has 14 builtin fonts, a subset of 35LW). For all other fonts the map files should be the same: both PS and PDF output should have font programs (pfb) downloaded, so map files should contain, e.g. tfmname Internal-PS-name [encoding-eventually] file.pfb = Can you send me the diff of those vendor's map files? George N. White III [EMAIL PROTECTED] writes: I find the current map file mechanism problematic, especially when using non-std fonts, because you can't tell from the TeX source what fonts are really being used. It is not TeX problem but final output/device dependent. For TeX we use only .tfm files. If (for some reason) we have two different map files, we can always declare them in config.ps and pdftex.cfg, respectively (p +mymap.map). -- Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: [OffTopic] Curious to know whether latex2html is current?
On Wed, 25 Jul 2001, Walter Tautz wrote: I was wondering if latex2html is still the way to go about converting latex to html? Is latex2html still being actively maintained, if so, where? If not where is the most recent version? Is there a mail list where one can post problems? I have only observed that latex2html (the same version!) is still mirrored on CTAN everyday ;-} -- Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: ec - fonts
Helmut Jarausch asked:
BH No, you did not. ecrm is not a font file, but just a parameter file
BH shared by different fonts.
...
So, the ec-fonts are not installed on teTeX-beta-2807 ?
They _are_ installed, but you have to know more what would you like to do.
(teTeX-beta-2807 is mostly for testing purposes, not a complete
distribution for everybody -- see readme-2804).
If you want to generate, e.g., ecrm1000, please run:
mf '\mode=hplaser; input ecrm1000.mf'
(this is example mode for 300dpi, default is hpfour for 600dpi; ecrm1000.mf
will be made on-the-fly from _parameter_ file ecrm.mf).
You would better running latex file to make EC fonts automagically:
\documentclass{article}
\usepackage[T1]{fontenc} % switch to EC fonts
\begin{document}
some text \em{some more} {\bf etc.}
\end{document}
Staszek Wawrykiewicz
email: [EMAIL PROTECTED]
Re: teTeX 1.0 vs. 0.4
Thomas Esser wrote: $ kpsewhich colordvi.sty /usr/local/Text/teTeX-1.0/share/texmf/tex/plain/dvips/colordvi.tex In my opinion would be better /texmf/tex/generic/dvips/colordvi.tex etc. since those macros are really generic. LaTeX can find it fast along TEXINPUTS.latex from texmf.cnf. Joao Palhoto Matos wrote: Please read the documentation for graphicx. This matter is unrelated to teTeX proper. This matter *is related* to teTeX proper. ;-) Somehow more then reading the documentation for graphicx. Staszek Wawrykiewicz email: [EMAIL PROTECTED]
Re: teTeX 1.0 vs. 0.4
... Now that the distribution has been upgraded to v1.0 I see problems that epsf.sty and colordvi.sty are no longer part of the distribution. Both epsf.sty and colordvi.sty are included in every *standard* TeX distribution, so something went wrong with your upgrade. Please check your ./texmf/tex/generic/dvips/ It should be there... or you forgot to rebuild ls-R databases: run texhash Staszek Wawrykiewicz email: [EMAIL PROTECTED]
texmf.cnf for BLU
It is still not clear what can be changed in the local/user
configuration. For example, teTeX 1.0.7 texconfig do not make a copy of
texmf.cnf to the $VARTEXMF (if it was set, and as it was in previous
versions).
I can understand the idea of having some optimization or not allowing
somebody to mess such important file and making all needed local
changes by running only texconfig, but I'd like suggest to leave some
freedom to many experienced users (in many cases, they know better
what should be done with TeX stuff configuration than their admins ;-)
There are several reasons for having local|user|$VARTEXMF texmf.cnf:
1. the user can have his own format file, so, e.g., TEXINPUTS should be
modified (preferably) in the texmf.cnf local copy.
As it can be seen from many mails:
2. TEXEDIT can be set by the the user to the prefered editor. Some prefer
vi, some emacs, etc. Again, local texmf.cnf is the best place.
3. The user can add another variant of pdf(*)tex in texmf/web2c/fmtutil.cnf
Please have a look at the actual fragment of texmf.cnf from
TeX Live5 alpha:
% PostScript headers, prologues (.pro), encodings (.enc) and fonts;
% this is also where pdftex finds included figures files!
TEXPSHEADERS.pdflatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfelatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftexinfo = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfcslatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfcsplain = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfetex= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfjadetex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdfmex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.pdftexinfo = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-de= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-en= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.cont-nl= .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS.context= .;$TEXMF/{etex,tex,pdftex,dvips,fonts/type1}//
TEXPSHEADERS = .;$TEXMF/{dvips,fonts/type1,pdftex}//
---
For each variant of pdf(*)tex we have exactly the same value (??!).
If the user add (in fmtutil.cnf) some other variant (say: pdfplatex),
he has to introduce also at least 2 lines in texmf.cnf:
TEXINPUTS.pdfplatex = .;$TEXMF/{pdftex,tex}/{platex,latex,generic,}//
(it is really needed for some optimization)
...
TEXPSHEADERS.pdfplatex = .;$TEXMF/{tex,pdftex,dvips,fonts/type1}//
(it is _not_ really needed, but I do not know how to change it
for all pdf* variants)
The last one variable is rather not for ``where pdftex finds included
figures files!'', I'm rather sure that nobody put his figures here ;-),
but is _very important for finding first_ texmf/pdftex/config/psfonts.map
(which, in turn, can be different from texmf/dvips/config/psfonts.map).
The last question: if pdf* do not use psfonts.map from the dvips/config/
(or it use it as the last resort) why it use the same file name?
Some time ago it used pdftex.map and it was enought clear...
I remember Thomas' work with updmap. Perhaps old ideas are not so bad...
Staszek Wawrykiewicz
email: [EMAIL PROTECTED]
