PyX

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

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

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

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-devel@...
> https://lists.sourceforge.net/lists/listinfo/pyx-devel

-- 
by  _ _      _    Dr. André Wobst, Amselweg 22, 85716 Unterschleißheim
   / \ \    / )   wobsta@..., http://www.wobsta.de/
  / _ \ \/\/ /    PyX - High quality PostScript and PDF figures
 (_/ \_)_/\_/     with Python & TeX: visit http://pyx.sourceforge.net/