Laser Printers

[wseyller]

Reasoning for my question:

Using VB6 (the programming language I'm familiar with), I want to use a print function to send a page of text to various monochrome laser printers on 8.5 x 11 paper. The amount of text to be printed on the page needs to be 5% coverage + or - 0.5% tolerance in a 8 x 10 print area. The text also will basically be a page full of the letter "E" and the E's need to space throughout the print area equally distanced as possible and each line staggered.

Problem:

With all the common laser printers, HP and lexmark mainly it takes a different amount of E's to produce my desired 5% page coverage. Some E pages may be the same for more than one model it seems.


My question:

What attribute(s) of these laser printers cause this difference? Is it soley the drivers? Would it be different on the same model whether using a PCL or Postscript Driver? Is there a way to calculate how many "E's" would be needed for a particular printer or its driver?

If I can figure a way then I can have in my program an option to select different models even maybe ask the user if a PCL or Postscript driver is being used and then the appropriate E page will be printed. I actually own most of the monochrome laser printers in existance especially the HP and Lexmark ones.

 

[rivan]

I'll preface this with a disclaimer that I'm not an expert on how data is rendered once it's sent to a printer. On the other hand, I'm very experienced with specific types of printers - some of which are similar to the way mono lasers print.

There are several variables that can affect print coverage on this scale - many of which you're not going to be able to plan for or affect.

Your concerns can be divided into two types, I'd think - physical and virtual.

First, physical issues you're likely not going to have any control over and the average user's not going to have a clue about.

Paper can have a huge impact on print coverage in a variety of ways; the weight, calendering (smoothness), finish, and humidity content of the paper can all impact coverage in different amounts from printer to printer. Some printers may love 20#, others love 28#. Calendering and finish issues show up as the printer's charge transfer mechanism ages (I believe most -maybe all- mono lasers replace this mechanism as part of the toner cartridge. Paper humidity too high or too low can also affect the paper's ability to take a charge, resulting in a change of coverage.

Toner quality also can have a significant impact - as with inkjet refills, aftermarket toner's very often low quality, which directly affects print coverage and quality.

Printer age could presumably impact print quality and coverage as well; as grippers and gears become worn, the page may no longer be kept perfectly flat, tight and moving with the imaging drum. Aging electronics might also play a role, as the charge may get weaker or less consistent, though this is not an area of expertise for me.

As for the virtual half, I'm much more in the dark about the specifics of how a print is processed, but I'll make a somewhat educated guess about how to go about handling it. I'm very familiar with what goes in, very familiar with what goes out, just ignorant of what exactly happens inside the RIP.

I know PS and PCL render type very differently - and I believe they both can have printer specifc settings on variations for that rendering, and I think removing actual type from the equation would be a good first step. Using an already rasterized image would eliminate any font issues that might get in your way, from printers wanting to use embedded fonts to the OS trying to be smart & sharpen, or a driver trying to antialias any given way. I'd think using a high resolution, 1-bit (black and white - not greyscale) image would be your best bet. In terms of resolution, I'd suggest a minimum of 1200, maybe as high as 2400 dpi, to far exceed the highest resolution printer you plan to target (unless you're also thinking of including imagesetters, in which case you might want to have a tiered approach - perhaps attempt to detect the device's resolution and double it).

Some of this might change if your user is highly print savvy - but that depends on your target user.

I hope this helps - I often lurk in HT but haven't seen a post since wrap-the-moon-in-tinfoil that I thought I could contribute to.

 

[wseyller]

Originally posted by: rivan
I'll preface this with a disclaimer that I'm not an expert on how data is rendered once it's sent to a printer. On the other hand, I'm very experienced with specific types of printers - some of which are similar to the way mono lasers print.

There are several variables that can affect print coverage on this scale - many of which you're not going to be able to plan for or affect.

Your concerns can be divided into two types, I'd think - physical and virtual.

First, physical issues you're likely not going to have any control over and the average user's not going to have a clue about.

Paper can have a huge impact on print coverage in a variety of ways; the weight, calendering (smoothness), finish, and humidity content of the paper can all impact coverage in different amounts from printer to printer. Some printers may love 20#, others love 28#. Calendering and finish issues show up as the printer's charge transfer mechanism ages (I believe most -maybe all- mono lasers replace this mechanism as part of the toner cartridge. Paper humidity too high or too low can also affect the paper's ability to take a charge, resulting in a change of coverage.

Toner quality also can have a significant impact - as with inkjet refills, aftermarket toner's very often low quality, which directly affects print coverage and quality.

Printer age could presumably impact print quality and coverage as well; as grippers and gears become worn, the page may no longer be kept perfectly flat, tight and moving with the imaging drum. Aging electronics might also play a role, as the charge may get weaker or less consistent, though this is not an area of expertise for me.

As for the virtual half, I'm much more in the dark about the specifics of how a print is processed, but I'll make a somewhat educated guess about how to go about handling it. I'm very familiar with what goes in, very familiar with what goes out, just ignorant of what exactly happens inside the RIP.

I know PS and PCL render type very differently - and I believe they both can have printer specifc settings on variations for that rendering, and I think removing actual type from the equation would be a good first step. Using an already rasterized image would eliminate any font issues that might get in your way, from printers wanting to use embedded fonts to the OS trying to be smart & sharpen, or a driver trying to antialias any given way. I'd think using a high resolution, 1-bit (black and white - not greyscale) image would be your best bet. In terms of resolution, I'd suggest a minimum of 1200, maybe as high as 2400 dpi, to far exceed the highest resolution printer you plan to target (unless you're also thinking of including imagesetters, in which case you might want to have a tiered approach - perhaps attempt to detect the device's resolution and double it).

Some of this might change if your user is highly print savvy - but that depends on your target user.

I hope this helps - I often lurk in HT but haven't seen a post since wrap-the-moon-in-tinfoil that I thought I could contribute to.

Ok I guess I may need to explain more. This will not be for the typical user. I am an engineer of laser cartridge components. I develop aftermarket components for laser cartridge. So I have a very deep knowledge of this. I just don't know about went it goes from the computer the printers formatter.

My use for the program I want to make will be develop around a standard already in place that removes all the variables you mention that I already knew of. I am using this to make life test on laser cartridges and to qualify components. This will be also for comparison between cartridge with different variations of aftermarket components and oem cartridges as a benchmark.

Also paper is the hardiest variable for us to standardize since there are many brands but we have come close. Every test uses the exact paper specifications noted in the ASTM guidelines. Humidy is recorded multiple times during the test. In fact all test equipment including printers, scales, densitometers and such are left in a conditioned room 24 hrs before testing. Printers are required to be maintained constantly. Though no two printers are alike we use the same printer for every test when comparing. Also stated in the guidelines is that the printer settings must be at factory default on every test.

I want to calculate a 5% print coverage with the 0.5% tolerance. This is excluding the fact that desity may be higher. Even if density is higher is doesn't mean the text is printed larger. I just may give that illusion because of the backgrounding or blasting. Really this is something we test for any with densitometer measurements. The 5% is needed because for one HP using this and two it is the most ideal percentage to use for evaulating toner usage per ASTM F 1856. The character "E" is used because it is one of the better characters to use to exploit any kind of problems such as blasting. I could write 100 more pages with many other variables that exist but believe me 5% is 5% before the laser from the scanner assembly gets anywhere near the opc drum.

 

[rivan]

Further explanation helped, but I'd be somewhat surprised if my suggestion of a 5% coverage *rastered* 1-bit file would end up outside your tolerance. I believe the less you leave for the rip to process the better - no fonts, nothing to screen or AA and it shouldn't do much, if anything, to the file but print it.

Thinking on it further, I'd think matching the raster image resolution to the printer resolution might be your best bet. 600 dpi printers get a 600 dpi file, 300 dpi printers get a 300 dpi file, etc. You should be able to pull the default printer res from the print driver or .ppd in the case of PS printers. Doing it this way also has the side benefit of making your program much simpler, only needing to determine the printer res and batch the appropriate image to the printer X times.

As for creating this file, pick a font and point size, render an E (a serif face will be better for detail, as you know), figure the ratio of black to white in the space used by the E, find how many Es fit to a page, and distribute Es however it suits you.

8.5x11 @600 DPI = 33,660,000 pixels x 5% coverage = 1,683,000 black pixels
I just rendered in Photoshop a 14 point Adobe Jenson Pro E with no AA at 600 ppi, cropped it to the bounds of the E and it's 64 px wide by 77 px tall. To find the number of black pixels, I used an ugly but accurate method inside Illustrator and found that of the 4928 pixels in the image area, 1364 were black. Repeat the E 1233 times within your 8x10" bounds, and add another 1188 pixels (not quite another full E) somwhere to get your exact coverage. If you have photoshop and illustrator I can go more in depth on the method I used for finding pixel counts.

Rinse and repeat for other resolutions/typefaces/etc.

Do you have an accurate means by which to measure your coverage on a printed page to verify that nothing in the RIP throws this off?

 

[Bassyhead]

Via software you're not going to get consistently 5% page coverage on any printer, even the same model printers. At work, I believe we use a scanner operating in 1-bit mode (a pixel is either black or white in this case) and use a histogram to determine the page coverage before beginning a test. We add or subtract "E"'s until the coverage is within tolerance with 5%.

 

[wseyller]

Thanks, some helpful info there. I have photoshop and illustrator. How do you find the pixel count? With special software and a scanner you can measure coverage but it would work very good for my purpose. I'm not trying to print a page that has a perfect 5%. It's not the print page I need that for, I need the printer to attempt to print @ 5% If the image even after it goes through the formatter then gets to the laser scanner just before it outputs the image to the opc drum is 5% exactly (this is what I'm hoping for by the way) the image on the paper may not be 5% which could be expected. The cartridges including other things will vary. In fact with all cartridges, pages that are printed will have backgrounding in the blank areas. This is actually something we can measure accurately. To describe it, it is like a very light mist of toner on the entire page. If it is a good cartridge it would be nearly impossible to see it with the human eye but I would think that a scanner would see it and count the backgrounding for part of the percentage. Not sure but maybe it wouldn't even be enough to break past the tolerance on my 5% requirement. One thing that happens is that not all toner particles charge properly. Toner particles are never exactly the same size. This is one reason why this some toner waste in laser cartridges because 100% transfer efficiency is very difficult to achieve.

 

[sdifox]

Have you tried forcing the printer to use system font instead of substituting? how about PDF the file first and then print it as image. Problem with printing is that no 2 companies times new roman look the same or even space the same. Also, definition of the margins and number of lines might not be the same across different printers. graphics is your best bet.

 

[wseyller]

Originally posted by: sdifox
Have you tried forcing the printer to use system font instead of substituting? how about PDF the file first and then print it as image. Problem with printing is that no 2 companies times new roman look the same or even space the same. Also, definition of the margins and number of lines might not be the same across different printers. graphics is your best bet.

That's what I was thinking. Maybe photoshop an image. I hoping the image would not be altered like a font might. Also this might make it easier to figure out page coverage as well.

 

[sdifox]

Originally posted by: wseyller

Originally posted by: sdifox
Have you tried forcing the printer to use system font instead of substituting? how about PDF the file first and then print it as image. Problem with printing is that no 2 companies times new roman look the same or even space the same. Also, definition of the margins and number of lines might not be the same across different printers. graphics is your best bet.

That's what I was thinking. Maybe photoshop an image. I hoping the image would not be altered like a font might. Also this might make it easier to figure out page coverage as well.

I hope any printer you test will print an image file the same

Only thing you would have to worry about would be margin setting.

 

[rivan]

Originally posted by: sdifox

Originally posted by: wseyller

Originally posted by: sdifox
Have you tried forcing the printer to use system font instead of substituting? how about PDF the file first and then print it as image. Problem with printing is that no 2 companies times new roman look the same or even space the same. Also, definition of the margins and number of lines might not be the same across different printers. graphics is your best bet.

That's what I was thinking. Maybe photoshop an image. I hoping the image would not be altered like a font might. Also this might make it easier to figure out page coverage as well.

I hope any printer you test will print an image file the same

Only thing you would have to worry about would be margin setting.

The margins he's working within should work for most any printer (8x10), though I think there might be some old ones with more than a half inch gripper on the trailing edge of the sheet.

To find pixel coverage, I:

-rendered the letter in photoshop as greyscale with NO anti-aliasing (my example was at 600 dpi)
-change color mode to bitmap (use the same resolution out as going in, and use the 50% Threshold method to reduce color depth)
-crop image near/exactly to rendered letter
-take note of *pixel dimensions*
-reduced the resolution to 100 DPI, to increase the placement size (important for the Illustrator filter - DO NOT RESAMPLE)
-take note of the
-save as TIF
-place TIF in Illustrator
-using the links palette, embed image
-Filter->Create->Object Mosaic: leave settings at default except for: Number of Tiles - input pixel dimensions here and set "Result" to gray.

This filter will generate a square block for each pixel of the rastered image. It can take quite some time to run and will only be accurate on lower resolution pieces - thus you should take your rendered item to ~100 DPI or so, but DONT resample, giving you the same number of pixels covering a larger area. Get yourself a cup of coffee while this runs. I'd not recommend doing it on an image larger than 100k or so (your TIF should be quite a bit smaller than this) unless you have plenty of time and lots of RAM.

-using direct select tool (empty arrow or hotkey A) select one of the white boxes that represent a white pixel.
-Select->Same->Fill & Stroke to select all the white boxes
-Delete all the white boxes
-Delete the placed TIF
-Select all
-In the Document Info palette, it will tell you how many paths you have - there should now be a single path remaining for each black pixel. Ignore the number of points - there will be 4 points per path, but each path represents one pixel from your rendered E.

The rest of the figures I showed above. Once you know how many pixels make up that E at a given resolution, you can figure the total pixels to cover a page and from that determine how many Es you'll need to make 5% coverage.