RE: dvips failing to include cmdunh10 font definition
Ah, many thanks. It's all looking much clearer now. do you have one of those: $ locate cmdunh /usr/share/texmf/fonts/source/jknappen/sauter/b-cmdunh.mf /usr/share/texmf/fonts/source/public/cm/cmdunh10.mf /usr/share/texmf/fonts/tfm/public/cm/cmdunh10.tfm /usr/share/texmf/fonts/tfm/public/vcm/vcmdunh10.tfm /usr/share/texmf/fonts/tfm/public/cm/cmdunh10.tfm $ locate cmdunh locate: /usr/var/locatedb: No such file or directory Hmmm. I'll have to look into this. [EMAIL PROTECTED]:/etc/setup $ zgrep cmdunh * tetex-base.lst.gz:usr/share/texmf/fonts/source/jknappen/sauter/b-cmdunh.mf tetex-base.lst.gz:usr/share/texmf/fonts/source/public/cm/cmdunh10.mf tetex-base.lst.gz:usr/share/texmf/fonts/tfm/public/cm/cmdunh10.tfm tetex-base.lst.gz:usr/share/texmf/fonts/tfm/public/vcm/vcmdunh10.tfm tetex-base.lst.gz:usr/share/texmf/fonts/type1/bluesky/cm/cmdunh10.pfb tetex-base.lst.gz:usr/share/texmf/fonts/vf/public/vcm/vcmdunh10.vf tetex-tiny.lst.gz:usr/share/texmf/fonts/source/public/cm/cmdunh10.mf tetex-tiny.lst.gz:usr/share/texmf/fonts/tfm/public/cm/cmdunh10.tfm This was when it dawned on me. I had tetex-tiny installed (it was a prerequisite for another package) but not any of the other tetex packages. Installing tetex-base fixed the problem, and everything seems to be working fine now. I guess we're left with two questions: 1) I've never properly understood the intended distinction between tetex-tiny and tetex-base. However, if tiny is intended to be a small, self-contained basic distribution, and contains the mf and tfm files for cmdunh10, shouldn't it have whatever else is required to make the font work properly in dvips, or know how to build it from the MetaFont source? 2) When I ran dvips, it presumably couldn't find the cmdunh10 font definition, so it failed to include it. However, I don't recall seeing any error message, or I might have spotted this earlier. I guess I could uninstall tetex-base to examine the dvips output again, to see whether there was anything which I should have noticed, but shouldn't dvips be more vocal? But in any case, it's working now. Many thanks indeed. Tim Reid _ Sign-up for a FREE BT Broadband connection today! http://www.msn.co.uk/specials/btbroadband -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
dvips failing to include cmdunh10 font definition
I believe I have found a problem with dvips. If I run LaTeX against the
following file:
\documentclass[a4paper]{article}
\font\anewfont=cmdunh10
\begin{document}
This is in the normal Computer Modern font.
{\anewfont This is in the vertically expanded Computer Modern font.
It looks fine in the DVI viewer.}
However, when using:
\begin{quote}
\texttt{dvips(k) 5.92b Copyright 2002 Radical Eye Software
(www.radicaleye.com)}
\end{quote}
it gets replaced with a fixed-width font, but using the correct letter
spacings. This means that it looks {\anewfont very odd indeed}.
\end{document}
I get a DVI file which looks just fine, and displays just fine using
MiKTeX's Yap viewer. Furthermore, when I run dvips from the MiKTeX
distribution on it, it produces a PostScript file which looks fine.
However, when I run dvips from the teTeX package in Cygwin on the same
DVI file, the resultant PostScript file displays and prints wrongly,
with the wrong font used for the bit which should be cmdunh10. Looking at
the PostScript messages produced in GSview, it seems to be substituting
Courier, as CMDUNH10 isn't defined. Examining the PostScript file, there
seems to be no definition of the cmdunh10 font, although it looks as if
dvips is trying to include one. The file contains the following extract:
.
.
.
cleartomark
%%EndFont
%%BeginFont: CMDUNH10
%%EndFont
%%BeginFont: CMR10
%!PS-AdobeFont-1.1: CMR10 1.00B
%%CreationDate: 1992 Feb 19 19:54:52
.
.
.
So the cmdunh10 definition is just not there. Is anyone able to reproduce
this problem?
Tim Reid
_
Tired of 56k? Get a FREE BT Broadband connection
http://www.msn.co.uk/specials/btbroadband
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: dvips failing to include cmdunh10 font definition
How does pdflatex look like?
Good question. I've not used pdflatex before, so I can't be sure whether
I'm doing this right:
==
$ pdflatex bug1
This is pdfTeXk, Version 3.14159-1.10b (Web2C 7.4.5)
%-line parsing enabled.
(./bug1.tex{/usr/share/texmf/pdftex/config/pdftex.cfg}
LaTeX2e 2001/06/01
Babel v3.7h and hyphenation patterns for american, french, german,
ngerman, n
ohyphenation, loaded.
(/usr/share/texmf/tex/latex/base/article.cls
Document Class: article 2001/04/21 v1.4e Standard LaTeX document class
(/usr/share/texmf/tex/latex/base/size10.clo)) (./bug1.aux)
Overfull \hbox (77.74681pt too wide) in paragraph at lines 13--14
[]/cmtt10/dvips(k) 5.92b Copyright 2002 Radical Eye Software
(www.radicaleye.co
m)
[1
Warning: pdflatex (file pdftex.map): cannot open font map file
] (./bug1.aux) )
(see the transcript file for additional information)
Warning: pdflatex (file cmtt10): Font cmtt10 at 1200 not found
Warning: pdflatex (file cmdunh10): Font cmdunh10 at 1200 not found
Warning: pdflatex (file cmr10): Font cmr10 at 1200 not found
Output written on bug1.pdf (1 page, 1325 bytes).
Transcript written on bug1.log.
==
It looks as if it's not finding any of the font definitions. Perhaps
unsurprisingly, I just get a PDF file which gives font errors when I
try to load it, and then gives a blank page.
Should I have some environment variables set up?
Tim Reid
_
It's fast, it's easy and it's free. Get MSN Messenger today!
http://www.msn.co.uk/messenger
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
tetex-bin 2.0.2-1: ctangle/cweave fail to read files in current directory
I was very pleased to see cweb binaries included in version 2.0.2-1
of tetex-bin, but it immediately started causing problems in my
development environment. I use make, which uses the built in rule:
# default
CTANGLE = ctangle
%.c: %.w
# commands to execute (built-in):
$(CTANGLE) $ - $@
This works fine for my vanilla version of ctangle, but with the tetex
version, fails thusly:
$ make
ctangle project.w - project.c
This is CTANGLE, Version 3.64 (Web2C 7.4.5)
! Cannot open input file project.w
(That was a fatal error, my friend.)
make: *** [project.c] Error 1
A bit of investigation suggests that the problem is in the comm-w2c.ch
change file, where the normal search mechanism (i.e. look in the
current directory, and then in the directory (if any) specified by
the environment variable CWEBINPUTS) is replaced by the Kpathsea
search mechanism, as follows:
This version uses the Kpathsea mechanism for searching files.
The directories to be searched for come from three sources:
(a) a user-set environment variable CWEBINPUTS
(b) a line in Kpathsea configuration file texmf.cnf
e.g. CWEBINPUTS=.:$TEXMF/texmf/cweb//
(c) compile-time default directories .:$TEXMF/texmf/cweb//
(specified in texmf.in).
The upshot of this change is that unless you have . in one of these
places (it seems I haven't) the current directory isn't searched for
the required input files, and the files you expect ctangle to find
aren't found. This is a fundamental change from vanilla ctangle,
and breaks the built in make rules.
So my question is this: could this please be changed to search
the current directory first, before mechanisms (a), (b) and (c) as
specified above? I imagine that the change shouldn't be too difficult,
something like this for Open input files:
Change the first three lines of the replacement text in change file
comm-w2c.ch:
if ((found_filename=kpse_find_cweb(web_file_name))==NULL ||
(web_file=fopen(found_filename,r))==NULL) {
fatal(! Cannot open input file , web_file_name);
to:
if (((web_file=fopen(web_file_name,r))==NULL)
((found_filename=kpse_find_cweb(web_file_name))==NULL ||
(web_file=fopen(found_filename,r))==NULL)) {
fatal(! Cannot open input file , web_file_name);
with something similar for the change file and any include files.
This change (the suggestion, that is, whether or not I've got the
coding right) should not break anything which is currently using
tetex's ctangle, as far as I can see, except in one case: if a file
is to be read (as a web file, a change file or an include file) which
exists somewhere that Kpathsea can find, and also in the current
directory, with the same name, but different content, currently
the Kpathsea file will be included, whereas with this suggestion,
the file in the current directory will be used. However, I imagine
that this would be unlikely, and, even if it did happen, my suggested
change more closely matches the vanilla ctangle.
[N.b. As these comments focus on common.w, these changes will also
apply to cweave.]
Tim Reid
_
On the move? Get Hotmail on your mobile phone
http://www.msn.co.uk/msnmobile/mobilehotmail
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
