Incorrect output from demo_text_path.py on mac

It seems that this could be bug in textpath.py that picks up wrong
glyph. Unfortunately, I cannot spend much time on this until the end
of this week.

As a matter of fact, I'm far from an expert on this issue. While I
wrote the textpaht.py, the code is largely based on the code in the
pdf_backend and svg_backend. So, I hope someone who is more
knowledgeable than me step in.

On the other hand, it seems that some glyph-name related bug has
recently fixed in the amsfont. And, this might be related to the
current issue.

http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README

I'm not sure what version of amsfont you're using but, can you try to
update them to newest 3.0.2 version? And see if that makes any change?

I'll try to look into this later this week.
Regards,

-JJ

···

On Tue, Nov 3, 2009 at 10:26 PM, tcb <thecolourblue+m@...149...> wrote:

hi,

i took a quick look at what is going on here- but I have still not quite
found the problem. From tracing things back into the ft2font code, it seems
that the wrong glyph index is getting passed in or used somewhere. I put
this debugging code into ft2font.cpp in "FT2Font::load_glyph"

#define MAX_LEN 1024
unsigned char bf[MAX_LEN];
FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ << " "
<< glyph_index << " "
<< num << " "
<< face->family_name << " "
<< face->style_name << " "
<< FT_Get_Postscript_Name(face) << " "
<< "[ " << bf << " ]"
<< std::endl;

I modified your example demo_text_path2.py to just load the single symbol
'\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' - and
the output I get is this from the command line:

FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium CMMI12
[ xi ]

so, it seems to pick the correct font but the wrong glyph name (xi instead
of pi)- I am not sure what the index should be. What gets displayed is the
'\xi' symbol- you can see from the first output I sent that '\pi' has been
replaced by '\xi' - the indexes of all the symbols are just offset by one, I
think.

If the correct glyph index is being passed to ft2font, then it could very
well be a problem with freetype.

regards

On Tue, Nov 3, 2009 at 6:19 PM, tcb <thecolourblue+m@...149...> wrote:

Hi,

Yes, with the pdfbackend, and using just the plain text code (with
usetex=True), the correct output is produced (for Text but not TextPath). I
modified your demo_text_path2.py to draw with text, and attached the output.

This is the terminal output from running your attached code. I am using
the texlive 2009 distribution- which appears to be working fine, I have not
noticed any problems at all. What is the difference between the bluesky and
amsfonts?

texname, type1name, enc, char_id
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
None CMEX10-34
cmsy10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
None CMSY10-49
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
None CMEX10-88
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
None CMMI12-110
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-61
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-49
cmsy10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMSY10-0
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-101
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-105
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-25
cmr17
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMR17-50
cmmi12
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMMI12-110
cmex10
/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
None CMEX10-35
phvr8r
/usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
/usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
Nimbus%20Sans%20L%20Regular-2

regards,

On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

On Tue, Nov 3, 2009 at 4:23 AM, tcb <thecolourblue+m@...149...> wrote:
> and if I convert the dvi with dvipng, it all seems in order
> (demo_text_path_tex.png). I haven't looked closely into how the
> textpath
> stuff works, but I thought it would read the dvi as a path, and display
> that
> on the screen- if that is correct then I dont know how it ends up
> displaying
> a different symbol from what is in the dvi file.

Well, dvi files only contains the name of the tex font. What textpath
does is to pick up corresponding type I font and convert them to path
using the freetype library (as far as I know, this is what dvipng and
matplotlib pdf backend does). So, my guess is that, textpath is
somehow picking up wrong fonts, or wrong glyphs.

The code works fine at least in my mac os X tiger w/ texlive 2008, and
in ubuntu with texlive 2007.
As I don't have any access to mac os X 10.6, it would be hard to track
down what is wrong. Here are a few more test I wish you to run.

*) Check if pdf backend produces a correct result. Do not use textpath
example, but simply use text command with usetex=True, and see if the
pdf output is okay. FWIW, the textpath code is largely borrowed from
the pdfbackend.

*) Run the attached code, and post the terminal output. The output is
basically the name of the tex font and the name of the substituted
type1 font, etc. For your reference, here is my output.

texname, type1name, enc, char_id
cmex10
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb
None CMEX10-34
cmsy10
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
None CMSY10-49
cmex10
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
None CMEX10-88
cmmi12
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb
None CMMI12-110
cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMR17-61
cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMR17-49
cmsy10
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMSY10-0
cmmi12
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMMI12-101
cmmi12
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMMI12-105
cmmi12
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMMI12-25
cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMR17-50
cmmi12
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMMI12-110
cmex10
/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
None CMEX10-35
pncr8r
/usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb
/usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc
Century%20Schoolbook%20L%20Roman-232

Regards,

-JJ

Hi,

That’s ok- let me know if there’s anything I can help with. I can’t see what textpath.py is doing any different on mac or linux, and it seems to find the right glyph code- but I suspect freetype on the mac is passing back the wrong glyph. So it would seem to point to a freetype problem, or a font problem, and specific to the mac.

I did install the latest amsfonts but the bug was still there.

tcb

···

On Wed, Nov 4, 2009 at 2:32 PM, Jae-Joon Lee <lee.j.joon@…149…> wrote:

It seems that this could be bug in textpath.py that picks up wrong

glyph. Unfortunately, I cannot spend much time on this until the end

of this week.

As a matter of fact, I’m far from an expert on this issue. While I

wrote the textpaht.py, the code is largely based on the code in the

pdf_backend and svg_backend. So, I hope someone who is more

knowledgeable than me step in.

On the other hand, it seems that some glyph-name related bug has

recently fixed in the amsfont. And, this might be related to the

current issue.

http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README

I’m not sure what version of amsfont you’re using but, can you try to

update them to newest 3.0.2 version? And see if that makes any change?

I’ll try to look into this later this week.

Regards,

-JJ

On Tue, Nov 3, 2009 at 10:26 PM, tcb <thecolourblue+m@…149…> wrote:

hi,

i took a quick look at what is going on here- but I have still not quite

found the problem. From tracing things back into the ft2font code, it seems

that the wrong glyph index is getting passed in or used somewhere. I put

this debugging code into ft2font.cpp in “FT2Font::load_glyph”

#define MAX_LEN 1024

unsigned char bf[MAX_LEN];

FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);

std::cout << "FT2Font::load_glyph " << FILE << “:” << LINE << " "

<< glyph_index << " "

  << num << " "
  << face->family_name << " "
  << face->style_name << " "
  << FT_Get_Postscript_Name(face) << " "
  << "[ " << bf << " ]"
  << std::endl;

I modified your example demo_text_path2.py to just load the single symbol

‘\pi’ instead ‘\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]’ - and

the output I get is this from the command line:

FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium CMMI12

[ xi ]

so, it seems to pick the correct font but the wrong glyph name (xi instead

of pi)- I am not sure what the index should be. What gets displayed is the

‘\xi’ symbol- you can see from the first output I sent that ‘\pi’ has been

replaced by ‘\xi’ - the indexes of all the symbols are just offset by one, I

think.

If the correct glyph index is being passed to ft2font, then it could very

well be a problem with freetype.

regards

On Tue, Nov 3, 2009 at 6:19 PM, tcb <thecolourblue+m@…149…> wrote:

Hi,

Yes, with the pdfbackend, and using just the plain text code (with

usetex=True), the correct output is produced (for Text but not TextPath). I

modified your demo_text_path2.py to draw with text, and attached the output.

This is the terminal output from running your attached code. I am using

the texlive 2009 distribution- which appears to be working fine, I have not

noticed any problems at all. What is the difference between the bluesky and

amsfonts?

texname, type1name, enc, char_id

cmex10

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb

None CMEX10-34

cmsy10

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb

None CMSY10-49

cmex10

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb

None CMEX10-88

cmmi12

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb

None CMMI12-110

cmr17

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMR17-61

cmr17

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMR17-49

cmsy10

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMSY10-0

cmmi12

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMMI12-101

cmmi12

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMMI12-105

cmmi12

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMMI12-25

cmr17

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMR17-50

cmmi12

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMMI12-110

cmex10

/usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb

None CMEX10-35

phvr8r

/usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb

/usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc

Nimbus%20Sans%20L%20Regular-2

regards,

On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee.j.joon@…149…> wrote:

On Tue, Nov 3, 2009 at 4:23 AM, tcb <thecolourblue+m@…149…> wrote:

and if I convert the dvi with dvipng, it all seems in order

(demo_text_path_tex.png). I haven’t looked closely into how the

textpath

stuff works, but I thought it would read the dvi as a path, and display

that

on the screen- if that is correct then I dont know how it ends up

displaying

a different symbol from what is in the dvi file.

Well, dvi files only contains the name of the tex font. What textpath

does is to pick up corresponding type I font and convert them to path

using the freetype library (as far as I know, this is what dvipng and

matplotlib pdf backend does). So, my guess is that, textpath is

somehow picking up wrong fonts, or wrong glyphs.

The code works fine at least in my mac os X tiger w/ texlive 2008, and

in ubuntu with texlive 2007.

As I don’t have any access to mac os X 10.6, it would be hard to track

down what is wrong. Here are a few more test I wish you to run.

*) Check if pdf backend produces a correct result. Do not use textpath

example, but simply use text command with usetex=True, and see if the

pdf output is okay. FWIW, the textpath code is largely borrowed from

the pdfbackend.

*) Run the attached code, and post the terminal output. The output is

basically the name of the tex font and the name of the substituted

type1 font, etc. For your reference, here is my output.

texname, type1name, enc, char_id

cmex10

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb

None CMEX10-34

cmsy10

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb

None CMSY10-49

cmex10

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb

None CMEX10-88

cmmi12

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb

None CMMI12-110

cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMR17-61

cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMR17-49

cmsy10

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMSY10-0

cmmi12

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMMI12-101

cmmi12

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMMI12-105

cmmi12

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMMI12-25

cmr17 /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMR17-50

cmmi12

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMMI12-110

cmex10

/usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb

None CMEX10-35

pncr8r

/usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb

/usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc

Century%20Schoolbook%20L%20Roman-232

Regards,

-JJ

Hi,

After a lot of head-scratching, I figured out that I need to set an
appropriate charmap when fonts are loaded. Well, as a matter of fact,
I even didn't know if fonts can have multiple charmaps.

Anyhow, I just committed a patch that I think fix the issue.
Please update your mpl and see if it works.

Regards,

-JJ

···

On Thu, Nov 5, 2009 at 9:18 AM, tcb <thecolourblue+m@...149...> wrote:

Hi,

That's ok- let me know if there's anything I can help with. I can't see what
textpath.py is doing any different on mac or linux, and it seems to find the
right glyph code- but I suspect freetype on the mac is passing back the
wrong glyph. So it would seem to point to a freetype problem, or a font
problem, and specific to the mac.

I did install the latest amsfonts but the bug was still there.

tcb

On Wed, Nov 4, 2009 at 2:32 PM, Jae-Joon Lee <lee.j.joon@...149...> wrote:

It seems that this could be bug in textpath.py that picks up wrong
glyph. Unfortunately, I cannot spend much time on this until the end
of this week.

As a matter of fact, I'm far from an expert on this issue. While I
wrote the textpaht.py, the code is largely based on the code in the
pdf_backend and svg_backend. So, I hope someone who is more
knowledgeable than me step in.

On the other hand, it seems that some glyph-name related bug has
recently fixed in the amsfont. And, this might be related to the
current issue.

http://mirror.math.ku.edu/tex-archive/fonts/amsfonts/doc/README

I'm not sure what version of amsfont you're using but, can you try to
update them to newest 3.0.2 version? And see if that makes any change?

I'll try to look into this later this week.
Regards,

-JJ

On Tue, Nov 3, 2009 at 10:26 PM, tcb <thecolourblue+m@...149...> wrote:
> hi,
>
> i took a quick look at what is going on here- but I have still not quite
> found the problem. From tracing things back into the ft2font code, it
> seems
> that the wrong glyph index is getting passed in or used somewhere. I put
> this debugging code into ft2font.cpp in "FT2Font::load_glyph"
>
> #define MAX_LEN 1024
> unsigned char bf[MAX_LEN];
> FT_Get_Glyph_Name(face, glyph_index, bf, MAX_LEN);
> std::cout << "FT2Font::load_glyph " << __FILE__ << ":" << __LINE__ <<
> " "
> << glyph_index << " "
> << num << " "
> << face->family_name << " "
> << face->style_name << " "
> << FT_Get_Postscript_Name(face) << " "
> << "[ " << bf << " ]"
> << std::endl;
>
> I modified your example demo_text_path2.py to just load the single
> symbol
> '\pi' instead '\left[\sum_{n=1}^\infty\frac{-e^{i\pi}}{2^n}\right]' -
> and
> the output I get is this from the command line:
>
> FT2Font::load_glyph src/ft2font.cpp:1159 25 0 Computer Modern Medium
> CMMI12
> [ xi ]
>
> so, it seems to pick the correct font but the wrong glyph name (xi
> instead
> of pi)- I am not sure what the index should be. What gets displayed is
> the
> '\xi' symbol- you can see from the first output I sent that '\pi' has
> been
> replaced by '\xi' - the indexes of all the symbols are just offset by
> one, I
> think.
>
> If the correct glyph index is being passed to ft2font, then it could
> very
> well be a problem with freetype.
>
> regards
>
>
> On Tue, Nov 3, 2009 at 6:19 PM, tcb <thecolourblue+m@...149...> wrote:
>>
>> Hi,
>>
>> Yes, with the pdfbackend, and using just the plain text code (with
>> usetex=True), the correct output is produced (for Text but not
>> TextPath). I
>> modified your demo_text_path2.py to draw with text, and attached the
>> output.
>>
>> This is the terminal output from running your attached code. I am using
>> the texlive 2009 distribution- which appears to be working fine, I have
>> not
>> noticed any problems at all. What is the difference between the bluesky
>> and
>> amsfonts?
>>
>> texname, type1name, enc, char_id
>> cmex10
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmex10.pfb
>> None CMEX10-34
>> cmsy10
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> None CMSY10-49
>> cmex10
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmsy10.pfb
>> None CMEX10-88
>> cmmi12
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmmi12.pfb
>> None CMMI12-110
>> cmr17
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-61
>> cmr17
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-49
>> cmsy10
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMSY10-0
>> cmmi12
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-101
>> cmmi12
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-105
>> cmmi12
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-25
>> cmr17
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMR17-50
>> cmmi12
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMMI12-110
>> cmex10
>>
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/public/amsfonts/cm/cmr17.pfb
>> None CMEX10-35
>> phvr8r
>> /usr/local/texlive/2009/texmf-dist/fonts/type1/urw/helvetic/uhvr8a.pfb
>> /usr/local/texlive/2009/texmf-dist/fonts/enc/dvips/base/8r.enc
>> Nimbus%20Sans%20L%20Regular-2
>>
>> regards,
>>
>>
>> On Tue, Nov 3, 2009 at 2:50 PM, Jae-Joon Lee <lee.j.joon@...149...> >> >> wrote:
>>>
>>> On Tue, Nov 3, 2009 at 4:23 AM, tcb <thecolourblue+m@...149...> wrote:
>>> > and if I convert the dvi with dvipng, it all seems in order
>>> > (demo_text_path_tex.png). I haven't looked closely into how the
>>> > textpath
>>> > stuff works, but I thought it would read the dvi as a path, and
>>> > display
>>> > that
>>> > on the screen- if that is correct then I dont know how it ends up
>>> > displaying
>>> > a different symbol from what is in the dvi file.
>>>
>>> Well, dvi files only contains the name of the tex font. What textpath
>>> does is to pick up corresponding type I font and convert them to path
>>> using the freetype library (as far as I know, this is what dvipng and
>>> matplotlib pdf backend does). So, my guess is that, textpath is
>>> somehow picking up wrong fonts, or wrong glyphs.
>>>
>>> The code works fine at least in my mac os X tiger w/ texlive 2008, and
>>> in ubuntu with texlive 2007.
>>> As I don't have any access to mac os X 10.6, it would be hard to track
>>> down what is wrong. Here are a few more test I wish you to run.
>>>
>>> *) Check if pdf backend produces a correct result. Do not use textpath
>>> example, but simply use text command with usetex=True, and see if the
>>> pdf output is okay. FWIW, the textpath code is largely borrowed from
>>> the pdfbackend.
>>>
>>> *) Run the attached code, and post the terminal output. The output is
>>> basically the name of the tex font and the name of the substituted
>>> type1 font, etc. For your reference, here is my output.
>>>
>>> texname, type1name, enc, char_id
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmex10.pfb
>>> None CMEX10-34
>>> cmsy10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>>> None CMSY10-49
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmsy10.pfb
>>> None CMEX10-88
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmmi12.pfb
>>> None CMMI12-110
>>> cmr17
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-61
>>> cmr17
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-49
>>> cmsy10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMSY10-0
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-101
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-105
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-25
>>> cmr17
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMR17-50
>>> cmmi12
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMMI12-110
>>> cmex10
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/bluesky/cm/cmr17.pfb
>>> None CMEX10-35
>>> pncr8r
>>> /usr/local/texlive/2008/texmf-dist/fonts/type1/urw/ncntrsbk/uncr8a.pfb
>>> /usr/local/texlive/2008/texmf-dist/fonts/enc/dvips/base/8r.enc
>>> Century%20Schoolbook%20L%20Roman-232
>>>
>>> Regards,
>>>
>>> -JJ
>>
>
>