From: Michael S. <m-s...@us...> - 2011-05-30 09:12:06
Attachments:
works_not.pdf
|
Hello, Here is some additional info to changeset 3162: The minimal example: ----- from pyx import * text.set(mode="latex") text.preamble(r"\usepackage{mathptmx}") c = canvas.canvas() c.text(0, 0, r"$\delta$") d = document.document([document.page(c)]) d.writePDFfile("minimal", compress=False) ----- The character $\delta$ does not show up if displayed using xpdf, evince, or okular (acroread and Skim do not have problems). The problematic PDF is attached. The problem can be boiled down to the encoding of the partially included font: In the non-working file the font encoding is given as /Encoding 256 array 0 1 255 {1 index exch /.notdef put} for dup 100 /delta put readonly def If I change it manually to /Encoding 256 array 0 1 255 {1 index exch /.notdef put} for dup 100 /delta put readonly def then it works. Michael P.S: The font is usyr.pfb from the URW fonts in Debian squeeze. |
From: Joerg L. <jo...@us...> - 2011-05-30 09:21:57
|
Hello Michael, On 30.05.11, Michael SCHINDLER wrote: > Here is some additional info to changeset 3162: > > The minimal example: > > ----- > from pyx import * > text.set(mode="latex") > text.preamble(r"\usepackage{mathptmx}") > c = canvas.canvas() > c.text(0, 0, r"$\delta$") > d = document.document([document.page(c)]) > d.writePDFfile("minimal", compress=False) > ----- > > The character $\delta$ does not show up if displayed using xpdf, evince, or > okular (acroread and Skim do not have problems). The problematic PDF is > attached. > > The problem can be boiled down to the encoding of the partially included font: > In the non-working file the font encoding is given as > > /Encoding 256 array > 0 1 255 {1 index exch /.notdef put} for dup 100 /delta put > readonly def > > If I change it manually to > > /Encoding 256 array > 0 1 255 {1 index exch /.notdef put} for > dup 100 /delta put > readonly def > > then it works. Interesting! This looks like a limitation in the PDF engine(s) of xpdf & Co. A brief look through Adobe's Type-1-font documentation did not reveal the significance of whitespace in the defintion of the encoding array. Cheers, Jörg |
From: Michael S. <m-s...@us...> - 2011-05-30 10:20:24
|
Hello Jörg, On 30/05/11, Joerg Lehmann wrote: > Interesting! This looks like a limitation in the PDF engine(s) of > xpdf & Co. A brief look through Adobe's Type-1-font documentation > did not reveal the significance of whitespace in the defintion > of the encoding array. Yes, you are totally right. I was about to send the bug report to the xpdf developers, but then I realized that in the original pfb file, the "dup"s come one per line. So, even if we are not strictly breaking the functionality according to the rules of PDF, I thought it would be reasonable to add the newline. Michael |
From: Joerg L. <jo...@us...> - 2011-05-30 11:56:55
|
Hello Michael, On 30.05.11, Michael SCHINDLER wrote: > On 30/05/11, Joerg Lehmann wrote: > > Interesting! This looks like a limitation in the PDF engine(s) of > > xpdf & Co. A brief look through Adobe's Type-1-font documentation > > did not reveal the significance of whitespace in the defintion > > of the encoding array. > > Yes, you are totally right. I was about to send the bug report to the > xpdf developers, but then I realized that in the original pfb file, > the "dup"s come one per line. So, even if we are not strictly breaking > the functionality according to the rules of PDF, I thought it would be > reasonable to add the newline. Probably there is some kind of unwritten convention to structure the Type 1 font like is in order to simplify its parsing. Anyway, it does not make sense to just point to the standard here. The main point is that files produced with PyX work on as many output devices as possible, so your change is definitely the right thing to do. Cheers, Jörg |
From: André W. <wo...@us...> - 2011-06-01 15:40:38
Attachments:
smime.p7s
|
Hi, there is some written convention on that! It is about making Type1 fonts readable for software which does not include a full PostScript interpreter. This whole issue is discussed in the Type1 Spec (seehttp://partners.adobe.com/public/developer/en/font/T1_SPEC.PDF) in chapter 10. However, from that document it is not clear that the "dup <index> <charactername> put" command sequence is required to be started at a new line each. Still, it is probably a good idea (and PyX just missed to do so for the very first item). Michael, your fix in changeset 3162 is perfectly fine to resolve this issue you observed using certain programs. As Jörg suggested already it is perfectly fine to adjust the PyX output to make it most compatible. Best, André Am 30.05.2011 um 13:56 schrieb Joerg Lehmann: > Hello Michael, > > On 30.05.11, Michael SCHINDLER wrote: >> On 30/05/11, Joerg Lehmann wrote: >>> Interesting! This looks like a limitation in the PDF engine(s) of >>> xpdf & Co. A brief look through Adobe's Type-1-font documentation >>> did not reveal the significance of whitespace in the defintion >>> of the encoding array. >> >> Yes, you are totally right. I was about to send the bug report to the >> xpdf developers, but then I realized that in the original pfb file, >> the "dup"s come one per line. So, even if we are not strictly breaking >> the functionality according to the rules of PDF, I thought it would be >> reasonable to add the newline. > > Probably there is some kind of unwritten convention to structure the > Type 1 font like is in order to simplify its parsing. Anyway, it does > not make sense to just point to the standard here. The main point is > that files produced with PyX work on as many output devices as possible, > so your change is definitely the right thing to do. > > Cheers, > > Jörg > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > PyX-devel mailing list > PyX...@li... > https://lists.sourceforge.net/lists/listinfo/pyx-devel -- 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/ |