🚀 go-pugleaf

The PPD is a set of guidelines. There isn't really any obligation on
any developer to do anything in particular; I doubt any implementor
includes support for everything in the PPD specification. And there is
no body devoted to checking "conformance", and if there was, Microsoft
haven't signed up to it.

In particular, the job of a printer driver is to print, so far as
Microsoft see it, so unless you have an actual printer with media
sizes less than 1 inch I doubt you will be able to interest Microsoft.

Aandi Inston

In article <45a2355f.1034705107@adobeforums.com>,  wrote:
> In particular, the job of a printer driver is to print, so far as
> Microsoft see it, so unless you have an actual printer with media
> sizes less than 1 inch I doubt you will be able to interest Microsoft.
>
       Such as (just an example) those label printers from a number of 
sources which take 1cm (~0.4 inch, if you're in a non-metric country) 
wide/ tall self-adhesive tape to print on. I think the one in our 
workshop is from "Brother", but I'm not going into the office to find 
out.
       
-- 
 Aidan Karley, FGS
 Aberdeen, Scotland
 Written at Tue, 09 Jan 2007 14:37 GMT, but posted later.

Are you able to print to a PostScript file and see that the page size that the driver produced is letter sized with your 1 inch centered at the top? And if so, can you edit the PostScript file for the page size you want, then download the file to your printer and get what you want?

I'm just curious if there is a manual way around the PSCRIPT5.DLL. If so, if you know what PSCRIPT5.DLL writes, and you know what you need, you could whip up a simple Find-and-Replace to get what you need.

Also, does your printer support Custom Page Size? (search for "custompagesize" in the PPD.) If so, you can check the min/max page sizes, and if it permits pages with sizes of 1 inch or less, you could potentially get around your problem using custom page size. When I tested the printer drivers at Adobe, I routinely tested bizarrely small and large custom page sizes to assure that they worked correctly, and 1-inch pages were no problem. (At least in the postscript code. Getting a printer to feed 1-inch squares of paper is another matter entirely.)

Mark, thanks for the reply. Let me give a little more info about what I'm trying to achieve here.

What I *really* need are EPS files. But of course, I have to go through the postscript driver first. The EPS files will be of classified liner ads that people place in newspapers. The majority of them are less than 1 inch in depth/height. So, another twist in this is that the page size is dynamic. Under XP, this involves some creation/modification of custom paper sizes on the fly, but I've solved that one.

What I found was that I could create smaller and smaller page sizes (mostly height values), until I got less than 1 inch. Then, my custom paper size disappears from the list of available page sizes.

I finally contacted Microsoft and inquired about the problem. One of their driver development engineers looked into the code and verified that, indeed, there is a minimum constant for height and width and it is set at...1 inch.

My original question here was whether they *should have* followed the PPD spec and allowed smaller values (although perhaps not zero), and *only* insert their heavy hand and apply the 1 inch minimum if no, or invalid, values were in the PPD.

All this worked under Win98. The process currently runs in that environment. We're trying to move into the 21st century, but Microsoft won't allow it. *My* guess is, a bad design decision was made when this was written for Win2000 (or perhaps from NT). A page has to consist of at least one line of type, right? And if you allow minimum line sizes of 0.7 pts(!), then why not page sizes less than 1 inch?? At this point, they're concerned about what they'd break by changing the constant value and re-compiling (I've been told it was that simple). Of course, then there's regression testing...and there's the rub.

I've tried testing several virtual printer drivers that will produce smaller page sizes, but we're also implementing color capability, which requires RGB -> CMYK color space conversion. We've got the color space conversion tackled as well. The virtual printer drivers I've tested so far won't work with the color conversion tool...yet...working on that still.

So, we can change custom paper sizes on the fly, and convert color spaces, but we can't get a constant changed with a recompile! lol In fairness, when they rejected the change request, Microsoft did tell me I could always write my own postscript driver. <8^o

If you have any other ideas/thoughts, I'd be most appreciative.

-Chris

Chris, I suppose I should have asked what application you're using.
Since MS has this somewhat arbitrary 1" limitation, I think you should use a better tool for the job. From the needs you describe, I think you should try Adobe Illustrator. It will save to EPS format, will accept very small page sizes that you define, and can be in RGB or CMYK. I think it is the perfect solution to fit your needs. If you can, check it out.

In article <3bc2c6fb.2@webcrossing.la2eafNXanI>,  wrote:
> All this worked under Win98. The process currently runs 
> in that environment. We're trying to move into the 21st 
> century, but Microsoft won't allow it. *My* guess is, a 
> bad design decision was made when this was written for 
> Win2000 (or perhaps from NT).
>
       I would suspect that your best chance of getting a 
(silent) fix from MS would be by stressing this (any) 
backwards compatibility issue rather than compliance with 
"rules" (whoever defines the rules).
-- 
 Aidan Karley, FGS
 Aberdeen, Scotland
 Written at Fri, 12 Jan 2007 21:54 GMT, but posted later.