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 http://php.net/pdf_findfont 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 whatsoever... 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: //home/www/pdffonts 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 (http://uncommonground.com/events.pdf) 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 http://chatmusic.com/calendar.pdf -- Perhaps I should say Hostbaby http://hostbably.com (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 "work"... 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. :-) THANKS!!! -- Got Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
