Bug#293179: tetex-bin: Bug in font pcrr7tn with dvips: Backticks wrong
Hilmar Preusse <hille42@web.de> wrote:
> Well, I guess what Hans is speaking about is the following:
>
> - create the dvi-file the way he described (pdflatex nfssfont and
> latex nfssfont [input as described in the report])
> - dvips nfssfont
This gives a warning:
dvips: Warning: missing glyph `dotlessj'
> - rename nfssfont.ps to nfssfont1.ps
> - ps2pdf nfssfont1.ps
>
> now compare the dvi with the nfssfont.pdf (the look equally AFAICT).
> Now take the nfssfont1.ps. You'll notice that the char 0x58 will look
> differently.
Don't you mean 0x61, or octal 141, the char below the capital X?
Obviously yes, or I'm counting wrongly.
> You'll see that too at the fourth string of the
> punctuation test. The same difference occur, when I've converted the
> ps into pdf.
Yes, now I see it. And there is one more difference, 0x21, the visible
space, also looks different. Interestingly, when I print them on a
postscript printer, the output is always the same (and correct).
And just to make sure: It looks wrong in the pdf created via dvips,
and right in the pdflatex version.
> Now the pdffonts output:
>
> hille@preusse:~$ pdffonts nfssfont.pdf
> name type emb sub uni object ID
> ------------------------------------ ------------ --- --- --- ---------
> TYDPHE+CMR7 Type 1 yes yes no 6 0
> GSOYPH+CMR10 Type 1 yes yes no 9 0
> ZGXXNR+CMTI10 Type 1 yes yes no 12 0
> EMGJUN+StandardSymL Type 1 yes yes no 15 0
> AGLIQY+CMTT10 Type 1 yes yes no 18 0
> FGPKKH+NimbusMonL-Regu-Extend_850 Type 1 yes yes no 21 0
A little different here:
frank@alhambra:~$ pdffonts nfssfont.pdf
name type emb sub uni object ID
------------------------------------ ------------ --- --- --- ---------
ONBINZ+CMR7 Type 1 yes yes no 6 0
EKJOBF+CMR10 Type 1 yes yes no 9 0
ULLQZH+CMTI10 Type 1 yes yes no 12 0
Symbol Type 1 no no no 14 0
TUHBYB+CMTT10 Type 1 yes yes no 17 0
CVXCXG+NimbusMonL-Regu-Extend_850 Type 1 yes yes no 20 0
I have "Symbol", and neither embedding nor subsetting, where you have an
embedded "StandardSymL". This is the font output of pdftex:
*\bye
[1{/var/lib/texmf/dvips/config/pdftex.map}]{/usr/share/texmf/dvips/psnfss/8r.en
c}</usr/share/texmf/fonts/type1/urw/courier/ucrr8a.pfb>{/usr/share/texmf/dvips/
tetex/09fbbfac.enc}</usr/share/texmf/fonts/type1/bluesky/cm/cmtt10.pfb>{/usr/sh
are/texmf/dvips/tetex/74afc74c.enc}</usr/share/texmf/fonts/type1/bluesky/cm/cmt
i10.pfb>{/usr/share/texmf/dvips/tetex/f7b6d320.enc}</usr/share/texmf/fonts/type
1/bluesky/cm/cmr10.pfb></usr/share/texmf/fonts/type1/bluesky/cm/cmr7.pfb>
Output written on nfssfont.pdf (1 page, 53286 bytes).
Transcript written on nfssfont.log.
> hille@preusse:~$ pdffonts nfssfont1.pdf
> name type emb sub uni object ID
> ------------------------------------ ------------ --- --- --- ---------
> ZMAAAA+Fa Type 1C yes yes no 19 0
> Courier Type 1 no no no 17 0
> Symbol Type 1 no no no 16 0
> GNAAAA+Fd Type 1C yes yes no 15 0
> HNAAAA+Fe Type 1C yes yes no 13 0
> INAAAA+Ff Type 1C yes yes no 11 0
This is exactly the same here.
> Seem to bee completely different fonts used. I've performed my tests
> using teTeX-2.99.10.20050123, but I guess it shouldn't make much
> difference to 3.0.
Okay, my tests were with teTeX-2.0.2, this probably explains the
difference for pdftex. Yes, it does - just tested with 3.0.
> I suggest to forward that to [tex-fonts] (I'm subsribed to that
> list). As jack <at> scriptserver.homeunix.net already mentioned it is
> probably a bug in tetex-base (or extra).
Yes, would you please do it?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Reply to: