From: Michael S. <m-s...@us...> - 2008-03-11 13:11:05
Attachments:
pyx.pdf
pdftex.pdf
|
Hello André and Jörg, I am not quite sure whether the following issue should already be solved by the new fontmap-system. Unfortunately, it still occurs in the current SVN version: The ligature "ff" in the following example comes out as the wrong character: -------------- code ------------------------- from pyx import * text.set(mode="latex") text.preamble(r"\usepackage{times}") c = canvas.canvas() c.text(0, 0, r"Diffusion") c.writeEPSfile("times") c.writePDFfile("times") ---------------------------------------------- The outcome is the same both in EPS and PDF. The font which is internally used is "ptmr7t", a virtual font which consists of "ptmr8r". When run pdflatex with the same example, it tells me that is uses utmr8a.pfb, which is correct, as I have the map entry ptmr8r NimbusRomNo9L-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <utmr8a.pfb (both in psfonts.map and pdftex.map). However, the outcome from PyX and from pdfTeX are different: see the attachments. Michael |
From: Joerg L. <jo...@us...> - 2008-03-11 21:39:50
|
Hello Michael, On 11.03.08, Michael SCHINDLER wrote: > I am not quite sure whether the following issue should already be > solved by the new fontmap-system. Unfortunately, it still occurs in > the current SVN version: So it also occurs with PyX 0.10? > The ligature "ff" in the following example comes out as the wrong > character: > > -------------- code ------------------------- > from pyx import * > > text.set(mode="latex") > text.preamble(r"\usepackage{times}") > > c = canvas.canvas() > c.text(0, 0, r"Diffusion") > c.writeEPSfile("times") > c.writePDFfile("times") > ---------------------------------------------- > > The outcome is the same both in EPS and PDF. The font which is > internally used is "ptmr7t", a virtual font which consists of > "ptmr8r". When run pdflatex with the same example, it tells me that is > uses utmr8a.pfb, which is correct, as I have the map entry > > ptmr8r NimbusRomNo9L-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <utmr8a.pfb > > (both in psfonts.map and pdftex.map). However, the outcome from PyX > and from pdfTeX are different: see the attachments. Hmm, on the dvifile and vffile side, everything looks fine: The ptm8r font is selected for the actual output and the same character as the one given by dvitype is used. Maybe the encoding is the problem, but right now I don't see how this could happen. Maybe André sees more... Unfortunately, I can only check the PDF output - my psfonts.map file does not work properly. Ciao, Jörg |
From: Michael S. <m-s...@us...> - 2008-03-11 22:27:15
|
Salut Jörg, On 11.03.08, Joerg Lehmann wrote: > On 11.03.08, Michael SCHINDLER wrote: > > I am not quite sure whether the following issue should already be > > solved by the new fontmap-system. Unfortunately, it still occurs in > > the current SVN version: > > So it also occurs with PyX 0.10? Yes, it does. > > The ligature "ff" in the following example comes out as the wrong > > character: > > > > -------------- code ------------------------- > > from pyx import * > > > > text.set(mode="latex") > > text.preamble(r"\usepackage{times}") > > > > c = canvas.canvas() > > c.text(0, 0, r"Diffusion") > > c.writeEPSfile("times") > > c.writePDFfile("times") > > ---------------------------------------------- > > > > The outcome is the same both in EPS and PDF. The font which is > > internally used is "ptmr7t", a virtual font which consists of > > "ptmr8r". When run pdflatex with the same example, it tells me that is > > uses utmr8a.pfb, which is correct, as I have the map entry > > > > ptmr8r NimbusRomNo9L-Regu "TeXBase1Encoding ReEncodeFont" <8r.enc <utmr8a.pfb > > > > (both in psfonts.map and pdftex.map). However, the outcome from PyX > > and from pdfTeX are different: see the attachments. > > Hmm, on the dvifile and vffile side, everything looks fine: The ptm8r > font is selected for the actual output and the same character as the one > given by dvitype is used. > > Maybe the encoding is the problem, but right now I don't see how this > could happen. Maybe André sees more... ... if he has time ... > Unfortunately, I can only check the PDF output - my psfonts.map file > does not work properly. With pdffonts you can check whether the font is embedded into the pdf file. I use the options LW35 URWkb dvipsDownloadBase35 true pdftexDownloadBase14 true in updmap.cfg in order to embed the fonts which come from URW (available on Debian etch or lenny). Michael |
From: Gert I. <ger...@ph...> - 2008-03-12 06:54:12
|
Hello Michael, > The ligature "ff" in the following example comes out as the wrong > character: to me it does not look like a wrong character but to a wrong kerning. utmr8a only contains the fi and fl ligatures but not the ff ligature. Does PyX somewhere try to produce a fake ligature? Best regards, Gert -- Gert-Ludwig Ingold email: Gert.Ingold@Physik.Uni-Augsburg.DE Institut für Physik Phone: +49-821-598-3234 Universität Augsburg Fax : +49-821-598-3222 D-86135 Augsburg WWW : www.physik.uni-augsburg.de/theo1/ingold Germany PGP : 86FF5A93, key available from homepage |
From: Joerg L. <jo...@us...> - 2008-03-12 17:48:13
|
Hello Gert and Michael, On 12.03.08, Gert Ingold wrote: > to me it does not look like a wrong character but to a wrong kerning. You're right, thanks for the hint! > utmr8a only contains the fi and fl ligatures but not the ff ligature. > Does PyX somewhere try to produce a fake ligature? Yes, indeed. The following is the relevant part of the output of PyX's debug mode - when I manually enable the debugging output for the VF's dvi chunks, as well: 110: fntnum14 current font is ptmr7t 111: setchar11 h:=0+420080=420080, hh:=??? 0: fntnum0 current font is ptmr8r 0: setchar102 h:=0+218232=218232, hh:=??? [f] 1: w2 -26214 h:=218232-26214=192018, hh:=??? 4: setchar102 h:=192018+218232=410250, hh:=??? [f] Note the line "1: w2..." which does the kerning. While it seems to be impossible to get this detailed output via dvitype, one can replace the VF code via dvicopy and then use dvitype. This yields: 134: fntnum0 current font is ptmr8r 135: setchar102 h:=0+218232=218232, hh:=14 136: w2 -16384 h:=218232-16384=201848, hh:=13 139: setchar102 h:=201848+218232=420080, hh:=27 [ff] Note how the kerning is different by a factor of 1.6, which is exactly the rescale factor between the new (in the VF's dvi chunk) and originial DVI units. In fact, that's all not too surprising, because the handling of the various scaling factors in PyX's dvi-file code is a mess. I think I didn't make it worse by the changes I just checked in, which more or less heuristically solve this issue. We really have to cleanup this code at some point... Michael: Maybe you could add a test case for this ligature to test_font.py. Best, Joerg |
From: Michael S. <m-s...@us...> - 2008-03-12 18:19:53
|
Salut Jörg, thanks for the fix. On 12.03.08, Joerg Lehmann wrote: > Note how the kerning is different by a factor of 1.6, which is exactly > the rescale factor between the new (in the VF's dvi chunk) and originial > DVI units. > > In fact, that's all not too surprising, because the handling of the > various scaling factors in PyX's dvi-file code is a mess. I think I > didn't make it worse by the changes I just checked in, which more or > less heuristically solve this issue. We really have to cleanup this code > at some point... > Michael: Maybe you could add a test case for this ligature to > test_font.py. done. Michael |