Re: Font problem or not?

2002-11-28 Thread Reinhard Kotucha
 Staszek == Staszek Wawrykiewicz [EMAIL PROTECTED] writes:

 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)?

No, this is needed by the current pdfTeX.  A future version could
either ignore the /FontName entry (and does not replace the font in
included files) or, which would be better, it looks for SlantFont and
ExtendFont in the map file and substitutes the appropriate font.

Maybe at the moment it is best to leave the /FontName in the map file
for fonts that are not transformed (i.e. no SlantFont or ExtendFont).
Then fonts in included files can be substituted.  This might save a
lot of space.

 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?

To transform a font, it's /FontMatrix must be changed, thus, it must be
embedded.  Builtin fonts are inaccessable when creating a pdf file.

 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 ;-)

The dvips and pdftex manuals provide a lot of information, especially
about map files.  You find more information about fonts in the LaTeX
Graphics Companion and there are a lot of Adobe Tech Notes on the
Adobe server.  But I agree, it's a mess.

Regards,
  Reinhard

-- 

Reinhard Kotucha Phone: +49-511-27060390
Marschnerstr. 25
D-30167 Hannover  mailto:[EMAIL PROTECTED]

Microsoft isn't the answer. Microsoft is the question, and the answer is NO.





Re: Font problem or not?

2002-11-26 Thread Reinhard Kotucha
 Staszek == 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:
 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

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.

Maybe this will be fixed in the future.

dvips neeeds the PS /FontName.  It doesnt need it to find or load the
font but to tell the PS interpreter to use it.

So, at the moment we need two different map files.

Reinhard 

-- 

Reinhard Kotucha Phone: +49-511-27060390
Marschnerstr. 25
D-30167 Hannover  mailto:[EMAIL PROTECTED]

Microsoft isn't the answer. Microsoft is the question, and the answer is NO.






Re: Font problem or not?

2002-11-26 Thread Staszek Wawrykiewicz
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?

2002-10-31 Thread George White
On Thu, 31 Oct 2002, Staszek Wawrykiewicz wrote:
 
 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.

So you can have dvips fail to find the font that corresponds to the 
.tfm file (missing entry) or end up with different fonts being used
on different systems (e.g., Adobe vs URW, MathTime vs Belleek, etc).

 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).

You can, but if you take the file to another system or mail it to someone
else, will you remember to change the .map files?  If you use pdftex's
ability to load map files specified in the .tex file, it is at least clear
which fonts you intended to use, and it will be obvious if the required
map files aren't present.

--
George White [EMAIL PROTECTED] 
Head of St. Margarets Bay, Nova Scotia




Re: Font problem or not?

2002-10-30 Thread Staszek Wawrykiewicz
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: font problem

2000-05-19 Thread Verwalter Dr.Betz


dvips -G0 works, thanks a lot ...
Option -G seems undocumented in man or info dvips ...
- so what would I do without your list ?

Yours
H.Betz

 Sounds like some option tells dvips to enable the "character shifting"
 feature which is incompatible with the fonts you are using.
 
  dvips $dvipsflag -Ptype1 -o $tempfile $infile
 
 Add -G0 (before -o) to the commandline of dvips.
 
 Thomas