alan@comp.lancs.ac.uk (Alan Phillips) (02/11/91)
I'm having a problem using EnumFonts. What I want to do is to present the user with a list of _device_ fonts, so he can choose something that will send text to the printer as text rather than graphics. Without ATM, the font_type argument that the font enumeration proc gets has a valid DEVICE_FONT bit, and I can distinguish GDI fonts from device fonts (we'll leave aside the question of why HP chose not to support device fonts in the DJ500 driver - but that shows 'courier' as a device font even though it isn't; and the question of why the Epson 24pin driver claims to have no device fonts even though it does). With ATM, the DEVICE_FONT bit seems to be _set_ for _all_ fonts. So unless you know what font names map to fonts in the printer, you're stuck. ATM does this even if 'use resident fonts' is selected. Anyone seen this? Better, anyone got a workround?
robertt@hp-vcd.HP.COM (Bob Taylor) (02/16/91)
> (we'll leave aside the question of why HP chose not to support device fonts in> the DJ500 driver - but that shows 'courier' as a device font even though it > isn't; ..... The DJ500 driver doesn't support device fonts because it provides scalable fontsthat approximate all of the internal "device" fonts (and provide all of the benefits of scalable fonts). The DJ500, with this driver and a decently configured host, can print text as graphics just as fast as it can print "device" fonts. The driver marks all of its scalable fonts as device fonts so it can tell whether a font request given to the driver is for one of the driver's fonts or a screen font - therefore, the driver's Courier scalable font is marked as a device font. For all intents and purposes, applications should consider it as if it was really in the printer. bob taylor HP Vancouver