Please Cc: me on replies...

I recently installed PHP 4.1.0 + PDF 4.0.1 on my development box.

I can't seem to get the PDF fonts to work properly at all...

Here are a lot of details about things I understand, and a lot of 
remarks about what I half-understand.

Note that, as a rule, font technology seems to be such a morass that 
I don't really understand it as a whole, even after reading all the 
HowTos and explanations.  There are just too many players, and too 
many variables involved for my poor little brain...  I grok all the 
little pieces and even some of the big-picture stuff okay, but when 
it comes time to actually use them all, I feel like I need eight 
brains to track it all...

At any rate, I'm afraid this post goes on quit a bit to explain all 
the things I've tried, and it would be a lot shorter if I was 
smarter, but I'm not. :-v

To paraphrase Blaise Pascal:
"I'm sorry this post is so long, I didn't have the brains to make it 
short." :-)

Okay, enough apologies:

I'm using
pdf_set_parameter($pdf, "resourcefile", "/home/www/pdffonts/pdflib.upr");
and I can muck with that pdflib.upr file and screw it up to cause 
different error messages, so I'm reasonably certain it's getting 
read. :-)

However, my choices for seem to be using 
"host" fonts, not "checked" (0) -- so they get rendered by the client 
at the time of drawing (more on *that* later), or using "winansi" and 
"checked" (1) or "host" and "checked" (1) in which case I get my 
choice of error messages like:

Can't find Outline Font data for "Helvetica"
Can't find Font Metrics for "Helvetica"

Those are paraphrases, but I could get the precise messages if you 
really need 'em...  And I can't remember which message goes with 
which combination of host/winansi, checked/unchecked, but does it 
really matter?  It can't find the damn Helvetica.afm file, as near as 
I can figure.

And I've tried some of the other 14 built-in fonts, even ones that 
would be unacceptable in the end, just to see.  No joy in Mudville. 
Oh, and using "builtin" instead of "host" or "winansi" didn't work. 
Not sure I even understand the difference between "builtin" and 
"host" anyway...  I forget exactly which of the not-working states it 
generated, but it was the same as one of the ones described herein, 
so let's just skip that for now, okay?

I get these differences based on my inputs to http://pdf_findfont and 
by altering the pdflib.upr file as noted in the comments within that. 
I've tried so *many* things, none of which work, so I can't be sure, 
but I don't think the "path entry" in pdflib.upr has any effect 

Actually, I think I can break it badly enough to get a different 
error message about an invalid pdflib.pdr file (something about not 
finding the FontAFM section, which comes right after the "path 
entry"), but any parse-able pathname at all seems to be just as good, 
or should I say just as bad, as the actual path to my fonts 
directory.  Currently, it's set at:


which is, indeed a valid directory with all my fonts and the 
pdflib.upr file in it, which, as noted above, seems to be getting 
read in.

NOTE:  The docs in pdflib.upr say that the "extra" leading "/" for 
"path entry" is required by PDF, and that there should be no trailing 
"/"   Honest.  If you're on a Mac, you'd be using ":" instead of "/" 
for all but the first "/".

So, of course, I already tried it without either or both extra front 
and trailing "/" and it doesn't work.  Doesn't make it any worse, but 
it didn't help either.  :-)  Point is, I'm pretty sure that that 
entry is correct syntactically.

I've also tried everything up to, and including, chmod 777 on the 
font files and their enclosing directory.  Naturally, after that 
failed, I set them back to something sensible like 664 and owned by 
www:www, the PHP User in httpd.conf who should be the user attempting 
to read these files, right?

Or does PDFlib actually do chroot or whatever that's called?...  This 
is behind a firewall, not a real web-server, so I could live with 
making these files even root executable and world writable it if 
would just make the darn thing work.  No, it didn't help to make them 
root-owned and chmod 777.  Yes, I was desperate enough to try.  Yes, 
I put them back to something sensible.

I've even tried swapping in the font files from a PHP-4.2.0-dev + PDF 
3.x server where it works just fine 
( for my font files, since there 
are minor differences -- CR/LF line endings, extra encodings, sample 
Outline/Metric entries in pdflib.upr (but no actual corresponding 
font files to got with them).  The code for that working PDF uses 
"host" and "checked" (1), which I should probably change to "winansi" 
and "checked" to avoid compatibility problems, but I'm not touching 
nothing, for now, on the one that actually *WORKS*!

Actually, I even have this all working on *ANOTHER* (albeit very 
similar) box at -- Perhaps I should 
say Hostbaby (a really *great* PHP host) has it 
working, since they set up the PDF stuff for me.

Anyway, trying to "fix" the Helvetica.afm (and all the other) files 
so they match the line-ending of a working model didn't help.

Any wild guess yet as to what went wrong?...

Neither server seems to have any Helvetica Metric nor Outline data 
files, or, at least, no files with "Helvetica" and endings like .pfa 
or, well, anything *other* than .afm...  Hmmmm. I guess an .afm file 
*IS* FontMetrics, but it's different from PFM which is also a Font 
Metrics file.  Sigh.  I guess there's lotsa different kinds of Font 
Metrics files?  Whatever.  Mine's broken, and the error message is 
about no "Font Metrics" (or "Font Outline", take your pick) and yet 
the same damn Helvetica.afm file works just fine on the other box.

Unfortunately, the "host" and not "checked" rendering (IE, relying on 
the client to draw the characters) works, for some sense of the word 

If you don't mind having output with *EVERY* instance of 'G' and 'H' 
replaced by a perfectly-spaced *BLANK* space!!!  Makes for 
interesting reading, I guess, but it probably won't fly too well...

Nice rendering, guys, but I kinda wanted all my letters to be 
visible, okay?  The 'G' and 'H' characters are getting sucked in from 
a dozen different web-sites, so I think I can safely rule out that 
they aren't non-ASCII or anything like that...

I have no idea why my Mac and/or PDF don't like those 'G' and 'H' 
letters.  Maybe they didn't watch Sesame Street on the days those 
letters were featured.  :-)  Seriously, though, is it too much to ask 
that the font-rendering engine produce something remotely *LIKE* a 
'G' or 'H'?  I'm not asking it for something perfectly attractive 
that a font-designer can cheese over.  Just a damn letter than I can 
read, okay?

I'd be perfectly content if the Mac version, or the Windows version 
used their ugly/pretty/whatever version of the Helvetica font and 
maybe crowded my design a little to let the letters all fit, or even 
chopped off a little bit of a last character here or there, as I 
understand that that's the price for using "host" and not "checked". 
But simply not drawing every 'G' and every 'H' (and leaving "room" 
for them) is just not making any sense to me at all...

I'm using the "host" and not "checked" for now on the assumption that 
y'all can help me, and I can focus on getting the application to do 
what I want before this silly font thing becomes a crisis...

I can't go to PHP 4.1.1 (yet) and play with Zend Studio Server 2.0, 
so would just as soon not try the "upgrade PHP" route unless somebody 
is sure that's the problem.

I will try to down-grade to PDF 3.x next, I guess, but I'm focusing 
on the application for now, so information that down-grade to PDF 3.x 
would fix or not fix my problems (or, at least, *this* problem) would 
be nifty -- Even if it's "I use PDF 4.0.1 and it works fine for me" 
would be helpful.

I am not wedded to "Helvetica" per se -- If somebody could point me 
to a URL of a similar-looking *FREE* font where I can download the 
.afm and .pfa and .ps and .enc and .cpg and whatever *other* TLA's 
[sheesh!] these font geeks can come up with, I'm down with that too. 
I'll settle for "decent-looking and reliable" over "gorgeous and 
unreliable" font technology any day of the week.  Something really 
ugly like Times or mono-spaced like Courier...  Not so much.

All I know is, every time I try and figure out this font crapola, I 
get a major headache.  I'm a low-brow kinda guy, and while I want a 
decent-looking font, I'm not going to whine over the curve of the 
serif on the letter Q at 73-point-size or anything.  I'd sure 
appreciate it if somebody "out there" in "font land" could take pity 
on us mere mortals and provide a simple alternative to this morass of 
design-quibbling (as I see it).  I'm not looking for gorgeous, I just 
want a decent-looking font where all the letters actually show up. :-)

Got Music?

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to