From: Michael S. <m-s...@us...> - 2008-03-17 13:45:46
|
Salut Jörg and André, I have found yet another problem in the new font system. It appears with the combination Utopia fonts (fourier package) -- several pages in a document here is a small example script: -------------------------------------- from pyx import * text.set(mode="latex") text.preamble(r"\usepackage{fourier}") d = document.document(pages=[]) if 1: s = canvas.canvas() s.text(0, 0, r"a") d.append(document.page(s)) if 1: s = canvas.canvas() s.text(0, 0, r"th") d.append(document.page(s)) d.writePDFfile("minimal") -------------------------------------- It fails at line 200 in pyx/font/font.py somewhere in the font encoding. When commenting out the preamble line or when dealing with one page only, the script works. The corresponding line in the pdftex.map is putr8r Utopia-Regular "TeXBase1Encoding ReEncodeFont" <8r.enc <putr8a.pfb Any ideas? Michael |
From: Joerg L. <jo...@us...> - 2008-03-18 08:23:38
|
Hi Michael, On 17.03.08, Michael SCHINDLER wrote: > I have found yet another problem in the new font system. It appears > with the combination > > Utopia fonts (fourier package) -- several pages in a document I didn't have time to have a closer look but I checked whether it works with the PS writer - and it does so. So my first guess would be that there is a problem with the resource merging in the PDF writer. Maybe you can locate the bug by comparing the PS and PDF logic in pyx/font/encoding.py and/or pyx/font/font.py. Otherwise, I'll have a look during the Easter holidays. Cheers, Jörg |
From: Michael S. <m-s...@us...> - 2008-03-18 09:52:22
|
Salut Jörg, On 18.03.08, Joerg Lehmann wrote: > On 17.03.08, Michael SCHINDLER wrote: > > I have found yet another problem in the new font system. It appears > > with the combination > > > > Utopia fonts (fourier package) -- several pages in a document > > I didn't have time to have a closer look but I checked whether > it works with the PS writer - and it does so. It appears to work with PS -- but it does not. The python run does not fail with an error message such as in PDF, but the resulting file does not display properly. A look into the file shows that also the wrong symbols are printed: a --> "\000" t, h --> "\000", "\001" This clearly shows that the problem is similar. The failure is, I think a design problem in the handling of the characters which are collected in the font. The font knows precisely about its characters, but when the encoding is generated, this is done in the "context" of the processPDF methods. The context, however, is not inter-pagial and therefore does not know about the glyphs which came on other pages. I therefore think, that the context is wrong place to put the encodings. It might be more apt in the TeXfont. > So my first guess would be that there is a problem with the resource > merging in the PDF writer. Maybe you can locate the bug by comparing the > PS and PDF logic in pyx/font/encoding.py and/or pyx/font/font.py. > > Otherwise, I'll have a look during the Easter holidays. holidays?? how nice :-( Michael |
From: Joerg L. <jo...@us...> - 2008-03-18 10:26:40
|
Hi Michael, On 18.03.08, Michael SCHINDLER wrote: > On 18.03.08, Joerg Lehmann wrote: > > On 17.03.08, Michael SCHINDLER wrote: > > > I have found yet another problem in the new font system. It appears > > > with the combination > > > > > > Utopia fonts (fourier package) -- several pages in a document > > > > I didn't have time to have a closer look but I checked whether > > it works with the PS writer - and it does so. > > It appears to work with PS -- but it does not. The python run does not > fail with an error message such as in PDF, but the resulting file does > not display properly. A look into the file shows that also the wrong > symbols are printed: > > a --> "\000" > t, h --> "\000", "\001" > > This clearly shows that the problem is similar. Thanks, I didn't check that. > The failure is, I think a design problem in the handling of the > characters which are collected in the font. The font knows precisely > about its characters, but when the encoding is generated, this is done > in the "context" of the processPDF methods. The context, however, is > not inter-pagial and therefore does not know about the glyphs which > came on other pages. Yes that seems to be the problem. We didn't think about that when writing the code. Hmmm.... > I therefore think, that the context is wrong place to put the > encodings. It might be more apt in the TeXfont. I guess not, the TeXfont should be unaware of the encoding. But somewhere else... > > So my first guess would be that there is a problem with the resource > > merging in the PDF writer. Maybe you can locate the bug by comparing the > > PS and PDF logic in pyx/font/encoding.py and/or pyx/font/font.py. > > > > Otherwise, I'll have a look during the Easter holidays. > > holidays?? how nice :-( Yes, although I have to prepare my lecture ;-) But anyway, this issue is more involved than I originally thought and I would not like to change things like this without André. Cheers, Jörg |
From: André W. <wo...@us...> - 2008-03-26 06:54:02
|
Hi, Am 18.03.2008 um 10:52 schrieb Michael SCHINDLER: > I therefore think, that the context is wrong place to put the > encodings. It might be more apt in the TeXfont. Encodings obviously are a feature for the whole file. This is what writer attributes are for. We just did it wrong in putting the encodings into the (graphics) context. While the bug was indeed embarrassing, the fix is quite trivial. See changeset 2974. André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael S. <m-s...@us...> - 2008-03-26 10:31:45
|
Salut André, Many thanks for the fix. On 26.03.08, André Wobst wrote: > Am 18.03.2008 um 10:52 schrieb Michael SCHINDLER: > > I therefore think, that the context is wrong place to put the > > encodings. It might be more apt in the TeXfont. > Encodings obviously are a feature for the whole file. This is what > writer attributes are for. We just did it wrong in putting the > encodings into the (graphics) context. What about renaming the "context" in order to make clear that it is restricted to one page? Such a renaming is always dangerous, I know -- but it would help people like me to understand the links in the ps/pdfwriter, the document, canvas, ... > While the bug was indeed embarrassing, the fix is quite trivial. See > changeset 2974. Michael -- Michael Schindler Laboratoire de Physico-Chimie Théorique. ESPCI. 10 rue Vauquelin, 75231 Paris cedex 05, France. Tel: +33 (0)1 40 79 45 97 Fax: +33 (0)1 40 79 47 31 http: www.pct.espci.fr/~michael |
From: Michael S. <m-s...@us...> - 2008-03-26 12:50:46
|
On 26.03.08, André Wobst wrote: > Maybe we should think about moving the encoding handling into the > registry somehow. I think this could work out quite well, but this is > just a wild guess at the moment. I have to look into the details and I > have to think about it. > > Anyway, for the moment I don't have any real > problem with the code in it's current state. Hm, I have been preparing a talk with pyx the last days, and I am using non-standard fonts for it. This is always a delicate issue as it brings together the complications in LaTeX and the ones in PyX. In a way, I am testing the limits of the current implementation. I do have a new problem with the code, which is probably related to another issue in the font handling. I encounter a glyphname "None" at some part in the encoding which breaks the afm width information. (The very same code worked with 0.10) It seems to be necessary to catch the glyphname None at some point. The code runs to the end if I insert the catch in afmfile.py around line 1358, but I am not convinced that this is the best choice for the catch. def width_ds(self, glyphname): if glyphname is None: return 0 return self.charmetricsdict[glyphname].widths[0][0] ------- traceback ------- File "/home/michael/python/PyX-0.10+/pyx/document.py", line 171, in writePDFfile pdfwriter.PDFwriter(self, _outputstream(file, "pdf"), **kwargs) File "/home/michael/python/PyX-0.10+/pyx/pdfwriter.py", line 318, in __init__ registry.write(file, self, catalog) File "/home/michael/python/PyX-0.10+/pyx/pdfwriter.py", line 77, in write object.write(file, writer, self) File "/home/michael/python/PyX-0.10+/pyx/font/font.py", line 201, in write file.write("%i" % self.metric.width_ds(encoding[i])) File "/home/michael/python/PyX-0.10+/pyx/font/afmfile.py", line 1361, in width_ds return self.charmetricsdict[glyphname].widths[0][0] KeyError --------end traceback ----------- It may be important to note that I have not managed to use the afm files in my installation. Therefore, I obtain warnings such as We are about to extract font information for the Type 1 font 'SFSX1440' from its pfb file. This is bad practice (and it's slow). You should use an afm file instead. Michael |
From: André W. <wo...@us...> - 2008-03-26 14:10:01
|
Michael, Am 26.03.2008 um 13:50 schrieb Michael SCHINDLER: > ... and I am > using non-standard fonts for it. This is always a delicate issue as it > brings together the complications in LaTeX and the ones in PyX. In a > way, I am testing the limits of the current implementation. Great! > I do have a new problem with the code, which is probably related to > another > issue in the font handling. I encounter a glyphname "None" at some > part in the > encoding which breaks the afm width information. (The very same code > worked > with 0.10) It seems to be necessary to catch the glyphname None at > some point. > The code runs to the end if I insert the catch in afmfile.py around > line 1358, > but I am not convinced that this is the best choice for the catch. > > > def width_ds(self, glyphname): > if glyphname is None: > return 0 > return self.charmetricsdict[glyphname].widths[0][0] > > > > ------- traceback ------- > File "/home/michael/python/PyX-0.10+/pyx/document.py", line 171, in > writePDFfile > pdfwriter.PDFwriter(self, _outputstream(file, "pdf"), **kwargs) > File "/home/michael/python/PyX-0.10+/pyx/pdfwriter.py", line 318, in > __init__ > registry.write(file, self, catalog) > File "/home/michael/python/PyX-0.10+/pyx/pdfwriter.py", line 77, in > write > object.write(file, writer, self) > File "/home/michael/python/PyX-0.10+/pyx/font/font.py", line 201, in > write > file.write("%i" % self.metric.width_ds(encoding[i])) > File "/home/michael/python/PyX-0.10+/pyx/font/afmfile.py", line > 1361, in width_ds > return self.charmetricsdict[glyphname].widths[0][0] > KeyError > --------end traceback ----------- I don't like None as glyphname to have a special meaning for metric information. There is no glyph None. Thus it's better to to fix the lookup itself. What happens here is that you use a font with encoding vector items being None and you try to use this font in the PDF file within the firstchar-lastchar range where you need to output a character width. Better to output a zero right there. See changeset 2976. BTW: IIRC pdfLaTeX sets the width information to 0 for glyphs not used to reduce the file size as we did too (do I remember correctly?). We might want to restore this behaviour and the issue should be gone as well ... > It may be important to note that I have not managed to use the afm > files in my installation. Therefore, I obtain warnings such as > > We are about to extract font information for the Type 1 font > 'SFSX1440' from its pfb file. This is bad practice (and it's slow). > You should use an afm file instead. That's fine. The message does exactly tell you the truth. André -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |
From: Michael S. <m-s...@us...> - 2008-03-26 14:27:02
|
Salut André, On 26.03.08, André Wobst wrote: > I don't like None as glyphname to have a special meaning for metric > information. There is no glyph None. Thus it's better to to fix the > lookup itself. What happens here is that you use a font with encoding > vector items being None and you try to use this font in the PDF file > within the firstchar-lastchar range where you need to output a > character width. Better to output a zero right there. See changeset > 2976. Yes. Thank you for the fix, it works for my example. > BTW: IIRC pdfLaTeX sets the width information to 0 for glyphs not used > to reduce the file size as we did too (do I remember correctly?). We > might want to restore this behaviour and the issue should be gone as > well ... I have no preference here. File size is normally not the constraint to me. Michael |
From: Joerg L. <jo...@us...> - 2008-03-26 14:20:56
|
Hi André, On 26.03.08, André Wobst wrote: > BTW: IIRC pdfLaTeX sets the width information to 0 for glyphs not used > to reduce the file size as we did too (do I remember correctly?). We > might want to restore this behaviour and the issue should be gone as > well ... Sounds like a good idea to me. Jörg |
From: André W. <wo...@us...> - 2008-03-26 17:10:08
|
For the moment (and for the records) I created the following minimal example: from pyx import * text.set(mode="latex") text.preamble(r"\usepackage{fourier}") c = canvas.canvas() c.text(0, 0, r"$\downarrow\leftarrow$") c.writePDFfile("minimal") André Am 26.03.2008 um 15:20 schrieb Joerg Lehmann: > Hi André, > > On 26.03.08, André Wobst wrote: >> BTW: IIRC pdfLaTeX sets the width information to 0 for glyphs not >> used >> to reduce the file size as we did too (do I remember correctly?). We >> might want to restore this behaviour and the issue should be gone as >> well ... > > Sounds like a good idea to me. > > Jörg > -- by _ _ _ Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim / \ \ / ) wo...@us..., http://www.wobsta.de/ / _ \ \/\/ / PyX - High quality PostScript and PDF figures (_/ \_)_/\_/ with Python & TeX: visit http://pyx.sourceforge.net/ |