I use the pslatex package to print Linux Seminar courseware. This is heavily dependent on the correct rendering of backticks. The backticks are rendered correctly if viewed in xdvi or PDF generated by pdflatex, whereas they are rendered incorrectly when using dvips. Alas, I cant switch to pslatex because I would have to convert 2000+ pages and hundreds of images to pdflatex. This bug concerns font pcrr7tn which is used in the pslatex-Style. The bold-face variant works fine. This bug is reproducable: # cd /usr/share/texmf/tex/latex/base This is e-TeX, Version 3.14159-2.1 (Web2C 7.4.5) entering extended mode (./nfssfont.tex LaTeX2e <2001/06/01> Babel <v3.7h> and hyphenation patterns for american, german, ngerman, nohyphena tion, loaded. (./article.cls Document Class: article 2001/04/21 v1.4e Standard LaTeX document class (./size10.clo)) No auxiliary output files. ********************************************** * NFSS font test program version <v2.0e> * * Follow the instructions ********************************************** Name of the font to test = pcrr7tn Now type a test command (\help for help):) *\table *\punct *\bye [1] Output written on nfssfont.dvi (1 page, 7240 bytes). Transcript written on nfssfont.log. # dvips nfssfont.dvi # gv nfssfont.ps ----> WRONG!
Hans baier <hansbaier@web.de> schrieb: I followed the procedure you gave, and I cannot see a significant difference between the xdvi and gv display. The little difference I see is probably due to different rendering. When I compare the result of latex nfssfont; dvips nfssfont.dvi; gv nfssfont.ps & to pdflatex nfssfont; gv nfssfont.pdf & I see no difference at all. The three files are at http://people.debian.org/~frank/nfssfont.dvi http://people.debian.org/~frank/nfssfont.ps http://people.debian.org/~frank/nfssfont.pdf if you want to have a look. Can you send us an example where the backticks are incorrect? Regards, Frank
Hans Baier <mail@hans-baier.de> schrieb: Are the versions of tetex-bin and its dependencies that same on the intel machine? Ideally, just use "reportbug tetex-bin" on the intel machine, and when it asks you whether the bug is in the list above, say yes (no need to scroll through the whole list) and enter the bug number, 293179. Then it will generate a bug report with all the version information included and send it to the existing bug. Ah, it's with -Ppdf. I'll try that, but of course in the Postscript files you provided I can see the difference. Gruß, Frank
i use the courier font a lot to typeset linux shellcode, but in the debian testing the backticks appear wrongly in the output. pdflatex got it all right, but dvips messed them up. So I compared the strace of both and found that the line concerning pcrr8 fonts is slightly different: diff /var/lib/texmf/dvips/config/pdftex.map /var/lib/texmf/dvips/base/psfonts.map | grep pcrr So I patched the psfonts.map file and changed the line: ---- pcrr8rn Courier " .85 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc ---- to --- pcrr8rn " .85 ExtendFont TeXBase1Encoding ReEncodeFont " <8r.enc <ucrr8a.pfb --- And it worked !!!!!!!!!!!!!!!!!!!! Well............... At least half of it. ******************************************** As of now, I tried it on the intel machine: dvips worked this time, but ps2pdf had the same problem as before. I don't figure out the difference between the two versions, (I use sarge on powerpc and the production system is sarge on i386), whereas on the powerpc machine both work. NOTE: This Report is a duplicat of the mail sent to the maintainer, but it contains the info from the intel machine, which does not work
Dear Hans, please keep the bugnumber address in the Cc, so that the mail gets properly archived, and the other maintainers also see it. Hans Baier <hansbaier@web.de> schrieb: line of the punctuation stuff reads: min, min: min; `min' ¿min? ¡min! (min) [min] min* min. (I hope the inverted ? and ! are encoded and displayed correctly in the e-mail). In the file out_powerpc.ps you sent me, I see instead min,min:min;`min'?`min?!`min!(min)[min]min*min. That is: The spaces are missing, the inverted "?" is replaced by "?`", the inverteed "!" by "!`". I'm not sure whether you already said this: If you generate a pdf file from the buggy ps file, using ps2pdf, is the pdf file also buggy? If yes, please send us the output of pdffonts $filename.pdf (the command is from xpdf-utils). Regards, Frank
jack@scriptserver.homeunix.net schrieb: Thank you - there is only one small difference in the involved packages: tetex-bin and libkpathsea3 are 2.0.2-26 on i386 and 2.0.2-25 on powerpc. But this shouldn't make any difference, there were no changes with respect to fonts. Regards, Frank
Hi all, 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 - 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. 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. 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 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 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. 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). Kind Regards, Hilmar
On 01.02.05 jack@scriptserver.homeunix.net (jack@scriptserver.homeunix.net) wrote: Hi, "Multiple exclamation marks are a clear sign of an insane mind." (Terry Prattched). SCNR!! As these files are generated it is not a good idea to patch them. Rather use the source files for them, which should be misc/pcrr8rn.map. Regards, Hilmar
Hi all, 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 - 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. 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. 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 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 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. 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). Kind Regards, Hilmar
On 01.02.05 jack@scriptserver.homeunix.net (jack@scriptserver.homeunix.net) wrote: Hi, "Multiple exclamation marks are a clear sign of an insane mind." (Terry Prattched). SCNR!! As these files are generated it is not a good idea to patch them. Rather use the source files for them, which should be misc/pcrr8rn.map. Regards, Hilmar
Hilmar Preusse <hille42@web.de> wrote:
This gives a warning:
dvips: Warning: missing glyph `dotlessj'
Don't you mean 0x61, or octal 141, the char below the capital X?
Obviously yes, or I'm counting wrongly.
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.
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.
This is exactly the same here.
Okay, my tests were with teTeX-2.0.2, this probably explains the
difference for pdftex. Yes, it does - just tested with 3.0.
Yes, would you please do it?
Regards, Frank
Hilmar Preusse <hille42@web.de> wrote:
This gives a warning:
dvips: Warning: missing glyph `dotlessj'
Don't you mean 0x61, or octal 141, the char below the capital X?
Obviously yes, or I'm counting wrongly.
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.
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.
This is exactly the same here.
Okay, my tests were with teTeX-2.0.2, this probably explains the
difference for pdftex. Yes, it does - just tested with 3.0.
Yes, would you please do it?
Regards, Frank
Hilmar Preusse <hille42@web.de> wrote: Thank you very much, Hilmar, for your great work! Do you think we should apply such a patch in our packages? TIA, Frank
forwarded 293179 http://bugs.ghostscript.com/show_bug.cgi?id=688022 reassign 293179 gsfonts stop On 01.02.05 Hans baier (hansbaier@web.de) wrote: Hi all, After a private discussion we came to the conclusion, that this is a bug in the gsfonts package. xdvi uses the font ucrr8a.pfb to display the char and gs uses the font n022003l.pfb to do that. These fonts claim both to be NimbusMonL-Regu but that character (quoteleft) differs significatly in both fonts. I've forwarded that bug to upstream: http://bugs.ghostscript.com/show_bug.cgi?id=688022 and now I'm reassigning to the related Debian package. Notes: - One may use t1diff[1] to show differences of the fonts - I tried to use that tool and got a ps file unfortunately gs was not able to process it. Regards, Hilmar [1] http://www.kammer.uni-hannover.de/~reinhard/texps/t1diff/t1diff.html
On 08.04.05 Hilmar Preusse (hille42@web.de) wrote: Hi all, Ralf Stubner was so kind to send me a patch to be applied to t1diff. After doing it, I should be possible to generate viewable Postscript files. Regards, Hilmar
This message had an attachment which were found to contain the following virus(es):
File 'Attachment' was infected with virus 'W32.Swen.A@mm' (ID 34162)
The infected file(s) were cleaned or removed from the attachment
----------------------------------------------------------------------
On 01.02.05 Hans baier (hansbaier@web.de) wrote: Hi all, Last remark about that bug. As pointed out by Ralf Stubner and as already said by TE there is a quick workaround for that bug: simply embedding that font (even if it is standard) into the ps file. This can be done either by: - feeding the option -Pdownload35 to dvips, or - edit /etc/texmf/updmap.d/00*, change the line "dvipsDownloadBase35 false" to "dvipsDownloadBase35 true", run update-updmap and updmap. According to TE this workaround can have some negative side effects, but in the moment I don't know, which. Regards, Hilmar
On 01.02.05 Hans baier (hansbaier@web.de) wrote: Hi all, Last remark about that bug. As pointed out by Ralf Stubner and as already said by TE there is a quick workaround for that bug: simply embedding that font (even if it is standard) into the ps file. This can be done either by: - feeding the option -Pdownload35 to dvips, or - edit /etc/texmf/updmap.d/00*, change the line "dvipsDownloadBase35 false" to "dvipsDownloadBase35 true", run update-updmap and updmap. According to TE this workaround can have some negative side effects, but in the moment I don't know, which. Regards, Hilmar
Hilmar Preusse schrieb: I tried it, but when I used embedden PS-graphics, the fonts in the figures completely disappear, which makes the workaround quite unusable. Fortunately, I discovered that most of our customers use the Windows-Acrobat-Reader which seems to come with the commercial fonts which don't have the problem whatsoever. The problem only shows up under the free UNIXes. So I disabled the workaround and advised our customers so far to use the Windows Acrobat Reader. To my opinion the wisest thing to do is to fix the font. Besides I installed Debian Woody which still comes with an old version of the font, which is o.k... Kind regards, Hans Baier
On 01.02.05 Hans baier (hansbaier@web.de) wrote: Hi, I just got the information, that the issue is solved in the latest release of the URW fonts: http://bugs.ghostscript.com/show_bug.cgi?id=688022 <snip> Chris Liddell 2011-12-15 16:21:08 UTC I believe this is fixed with the latest URW font release: http://git.ghostscript.com/?p=ghostpdl.git;a=commit;h=ea9a9517 <snip> No, I don't have the chance to test it. H.
Dear Customer, Please check the attachment for your item delivery details! FedEx-----BEGIN PGP PUBLIC KEY BLOCK----- n7ZJFfah6WRzQz9Xu69AMg2kNAKP6AHs+K6QhfSnMj+tzrCYKliQfvVyZkSVckmPC5XqI89EqQ4o qv6gEb7o21UaY1ehoEkZteLXhL7Eb6+yyagMaqoQ1BXkD/nl4buvnGzo0BrC+rpdLv5ytbuBAvk3 Ng+DJ0pwgfa2ebjvYshNmBoTHqhcGHD7fkzA7uywpooYoz/aARSPz0XXJ8nOoovGD2RAuTWCKGxB EAhSG2tUtSruaOrgD2Ff1Y+iLdwIjmW7vUoaEAEQKfPMUxu2GfyKLTKM9nlqqs9oDGk73UzgC5L0 Z1JIKYyNSLkAte58v0BeMHFVoNC9cxKkdAyx6jUZY6L9HxVNmLgu7368rlPVSxbTuEnAChJ+j5Nz cgj8/U8rI0udGR5c6QSnYsTLfDJ/zcjgInFZVfX0JlLtuKXEKawG35s0jZUorqawwvTdUxFi1geG G7kr/mxOvf4P+IoD/VJT6DKa8D/eJ1we+NIs9xFQ9RL/IXvPm1P3PubQMZer4FMgEIGi43z2OlrA VRecCLSYTjtlpehwxxPsrhHDmJtd8xCLHVLVnVn6GWsRssJhh/LChHydDZpFLOTA/Sc8zqEE09fo rkpnrBNP7qL5ps4HFcV3KOBS0gI2SdXLnyuAxK0VQ58R3pi52L2o74x4BiNTv0sIRJySJVc4Dt+X 3bx7k4maXrka9P9XHUxWn8y7C/CBBPoEPMgprYURYhofRYnw9l2H5omxF666Y3y6CAeqeLzx6hJw rWfUG/j9p/TKI5/XOCAhHzv0Pw2l7O3pH6rzLL18pJBujSIb/cR12KdI6safqekwPKpYNh6SuALJ T/yaZVoClFCcYqZNoPJVlxzWB3820nmxXADbxfveEMX++rNQnGhwoOm5mj4erd65NgJuVU0GeOVw MFIlvFn5ESwrI42Cvpwoc+55c5rdYWhtmLYdZy4NoYjR1VVWkNpi1WbJ9v0uYMUBlvNeO/jmn4mz S0E25fD7zDXRq13qkpST7CAHHyeWR4i1Cy9dyTni+lUXKd0RiKpe+6wh3fTtj8Z8oYnMu8CQJv7l 29HQKcXu89gH2UQHpUWSG8F71wk0Kort7L2MWInYSxK47L73AeUBwzXels0FMhRt7AZ1wsdrvSF1 4rCZq3B+jJNk9KO2pqa5Ltxi0mP4IYoHjH+2dngS9QfgKgcmXIeAb5BBuzJNlXYAUIAkIK19Bw80 etq8WEWMb1imOwjN4BfO1YoFjtKhFT4ezGVzeRpRBSGkJvIpR1lTSgbuvvbFSdTxNi0mJ6DclLWi /o7mM4Tr5w7RaMS5aWm0TJymhqH4Lds/q3p3aM77zg==-----END PGP PUBLIC KEY BLOCK-----