2006/4/17, John Hawkinson <address@hidden>:
How does it crash the printer? Well, various ways. Most clearly is
that sometimes it produces a 79.00FE crash on the front panel, and
other times it simply hangs the printer such that it does not respond
to input over the network or on the front panel. I haven't pursued it
with HP, but they do have a history of having a myriad of such
problems with strange binary encodings. The printer in question is an
HP8150DN (of which we have a whole slew around here) running the most
recent firmware (20041013
MB7.119).
One workaround I tried was to convert the fonts to hex, and wrap their
encoding in:
currentfile /ASCIIHexDecode filter cvx exec
%...hex of the font here...
>
This does not work. It seems to work for Aybabtu, but not for
Emmentaler, which causes an error even with ghostscript. (Error:
/invalidfont in --.type42execchar--) I'm not sure why...
I'd gladly have a patch for ascii-wrapping the OTF binary, because inserting binary data in PS doesn't give me good vibes. If this is valid PS, we should take the issue up with ghostscript development.
So anyhow:
. Can LilyPond go back to Type 1 fonts in the interest of
broader compatibility? Or perhaps this could be an option (but
they would have to be generated at build time, anyhow). On the
other hand, is there anything to be gained by OTF fonts?
having the PS files a bit smaller probably doesn't matter for
the ghostscript ps->pdf conversion, and doesn't seem a big price
to pay for better compatibility.
. Why do the different encodings (Type1 PFA, OTF) produce
differing-named fonts (PFAAybabtu-Regular vs. Aybabtu-Regular)?
[hence the necessity for munge-lily-font-name].
The problem is that FontConfig will see different versions of the same font, and it can get confused and pick the wrong font. Also, the whole machinery for creating the PFAFoo fonts, detecting when to substitute them and finding them on disk is ugly and rather fragile. We've had a lot of bugs relating to it. We're using an OTF font iso. a Type1 font because we have to store various extra parameters inside the font. OTF/TTF has a neat mechanism for that, which Type1 lacks.
Of course, if we can make our PS more conforming, I'm all for it, but I'm opposed to (re)installing hacks for being compatible with broken hardware.
It seems like this has potentially been a problem before.
Revs 1.84 through 1.86 of scm/framework-ps.scm share this log message
tidbit:
* scm/framework-ps.scm (munge-lily-font-name): new function
(write-preamble): hack: insert PFA equivalent of CFF into
.PS. This makes LilyPond output printable on normal PS printers
again.
Could very well be; I also have an HP printer (LJ2100 with a PS dimm). However, the reason for installing the hack was related to a Ghostscript bug. We reverted the hack because the bug has been fixed now.
I suppose that I could attempt to take up this issue with HP,
and perhaps get it fixed in a new firmware version half a year
from now (not that they've released any in the past 2 years),
but I must say I'm not enthusiastic.