Re: [NTG-context] Re: texfont and type-tmf.dat

[George White]

On Thu, 9 Oct 2003, Patrick Gundlach wrote:

 [...]
 According to to the statements from Walter Schmidt, a TeX font expert
 (perhaps I should say *the* TeX font expert?) in
 http://tug.daimi.au.dk/archives/tex-fonts/msg01328.html
 
 \quote{% 
 Note, however, that embedding of URW's fonts, while using the 
 (PSNFSS) Adobe Base35 metrics, will _not_ lead to any bugs!  
 The character metrics are matching!  Differences in the 
 character bounding boxes are irrelevant for the advance widths!  
 The only drawback is, that you cannot access those glyphs that 
 are in the URW fonts, but not in the Adobe fonts.  Indeed, this 
 could be overcome by providing particular metrics and VFs for 
 the URW fonts -- see below. }

Hans has demonstated that even the Adobe fonts don't have the same
metrics.  It should also be noted that in practice, if you don't embed
fonts, you will often get font substitutions in the PS rasterizer (e.g.,
ghostscript defaults will use URW fonts where the file requests a Base35
font, current acrobat reader will use Arial where the file requests
Helvetica, some printers with clone interpreters (many recent HP models)
use clone fonts. 

There are several versions of the URW fonts in use now: two ghostscript
versions, and a number of versions with additional glyphs distributed
with linux (and I am told that the software used to create the recent
versions may have tampered with the metrics for glyphs that were not
changed).

If you embed the URW fonts using the original URW names it is clear which
fonts are to be used.  This discourages people from optimizing your
files by stripping out the fonts.  For archival EPS figures it makes sense
to go further and replace fonts with outline paths.  In this way the
figures should remain useful even after the fonts are no longer supported
by the available rasterizers. 

--
George White [EMAIL PROTECTED] [EMAIL PROTECTED]
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia  B3Z 2G6

___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context

[NTG-context] problems with embedded spaces in file paths (Win32)

[George White]

I don't normally use Win32, but I want to convert our 4AllTeX addicts to
TeX Live 2003.  In testing release candidates, I encountered a few
problems with context and texexec.  The most recent tests were with the
Sept. 5 release candidate (using the install CD). 

1.  on Win32, kpsewhich often fails to find texexec.ini.  I created a
texexec.ini in texmf-var/context/config and verified that it is listed in
the ls-R. My conjecture is that this failure occurs if and only if the
final component of the nme of the current working directory contains an
embedded space, e.g., C:\My Documents.  Texexec takes a very long time
to run (searching the texmf trees on an unloved and unwanted PIII 300mhz),
so I haven't done a lot of testing/debugging.  I haven't encountered any
other kpathsea failures.  I can work around this by tweaking texexec.pl,
but it would be comforting to have an explanation.

2.  ConTeXt texexec uses $ENV{HOME} to set a value in filename.tmp, 
e.g., on unix:

$ cat try.tex 
\starttext 
\input story 
\stoptext 
$ texexec try 
$ cat try.tmp 
% try.top 
\unprotect 
\setupsystem[\c!gebied={/user/gwhite/}]  % set from $ENV{HOME}
\setupsystem[\c!n=1] 
\setupsystem[inputfile=try.tex] 
\protect

If, e.g. HOME=/x y, the formatted document gets an extra page containing
y//cont-err. 

On Win32, it seems common to have spaces in %HOME%.  In particular, for
WinXP, a value appears to be constructed by the texexec.ini binary
(created using irun) if %HOME% is not set.  I can work around this by
asking users to explicitly set HOME to something safe.

--
George White [EMAIL PROTECTED] [EMAIL PROTECTED]
189 Parklea Dr., Head of St. Margarets Bay, Nova Scotia  B3Z 2G6




___
ntg-context mailing list
[EMAIL PROTECTED]
http://www.ntg.nl/mailman/listinfo/ntg-context