Printers and resolution - a historical perspective.

[Moglex]

A couple of posters have said they find the idea that an application is responsible for interpolating the pixels in an image rather than the printer to be 'illogical' and counter to their 'intuition'.

I thought it might be a good idea to add a little historical perspective as that might make the way the system works a little easier to understand.

The GUI was originally developed by Xerox PARC in the late seventies and early eighties. It was copied by Apple for the original Mac released in 1984.

So when the architechture of the GUI was developed (and the basic architecture has never really changed), a full blown computer had a processor that would not power a modern mobile phone and had to get by with around 1/10,000th of the memory of a modern system.

At this time, the control circuitry for printers was fairly rudimentary and they were certainly not fitted with any significant amount of memory.

The idea of expecting the printer to handle interpolating a bitmap to enlarge it before printing would have seemed laughable to the teams that worked on the design of the architecture.

In those days the printer manufacturers did not supply drivers because there were so many different microprocessor types and operating systems in existance and it was up to each program to interface with the printer directly.

So the architecture was designed in such a way that the unit with the far larger amount of processing power: the PC (as all personal computers were called before IBM 'aquired' the name for their particular style and the IBM architecture became known as the PC wheras other personal computers were known as Macs or whatever), handled everything up to and including producing the bitmap in the correct format for the printer..

All the 'grunt' work is done by the main system leaving the printer to concentrate on doing the actual work of printing. The drivers are merely responsible for converting from the function calls required by the GUI to the command streams recognised by the printers and allowing the user to set and communicate non standard options.

So that is how an architecture that a quarter of a century later may seem 'illogical' to some came to be developed in that way.

Even had the architects considered doing it in any other way the lack of processing power and memory on the printers of the day would have made it quite impossible.

 

[Helen B]

A couple of posters have said they find the idea that an application is responsible for interpolating the pixels in an image rather than the printer to be 'illogical' and counter to their 'intuition'.
...

I interpreted them to mean that the interpolation can be carried out by the printer driver, not necessarily by the printer itself.

So the architecture was designed in such a way that the unit with the far larger amount of processing power: the PC (as all personal computers were called before IBM 'aquired' the name for their particular style and the IBM architecture became known as the PC wheras other personal computers were known as Macs or whatever), handled everything up to and including producing the bitmap in the correct format for the printer.

Just to clarify: The software on the PC can take full control of the printer, not simply send it a bitmap of the pixel values. The PC can do the dithering that specifies what size of dot of which ink is placed where.



Best,
Helen

 

[Bifurcator]

Yup, and although "The PC can do the dithering" in almost every case except Moglex's special program, it doesn't. In almost all cases the printer driver and printer handle it - not the program.

 

[Helen B]

Yes. When I suggested that the PC software could do the dithering, I was referring to the printer driver or RIP, not to the photo editing application (eg Photoshop).

Best,
Helen

 

[Bifurcator]

Ah, ok.. hehehe yeah I guess there's not much doubt that the driver is PC side. My bad...

 

[Moglex]

I interpreted them to mean that the interpolation can be carried out by the printer driver, not necessarily by the printer itself.

Indeed, but as I explained above, when the GUI architecture was designed there really were no such things as 'drivers'. The discussion was about whether the intertpolation was performed by the printer/driver side of the the GUI or the application side.

Just to clarify: The software on the PC can take full control of the printer, not simply send it a bitmap of the pixel values. The PC can do the dithering that specifies what size of dot of which ink is placed where.

That isn't actually clear at all.

Are you saying that the driver can have control of the printer?

If so, that has never been disputed.

It is entirely a matter for the printer designer where s/he places the intelligence. That is because the [Driver -> Printer] is a black box. The GUI neither knows nor cares who does what.

If, on the other hand you are saying that applications such as PSP can can in some way control the actual size and placement of individual ink drops (i.e. control the dots of individula ink colours seperately), then I'm intrigued.

Please provide a link to the source for that information. It goes against all my experience but I have not been a regular visitor to the codeface for some time and, if what you say is correct, there must be some interesting information around.

 

[Moglex]

Yes. When I suggested that the PC software could do the dithering, I was referring to the printer driver or RIP, not to the photo editing application (eg Photoshop).

Oh, OK, that appeared whilst I was composing my reply.

Yes, there was never any doubt that the driver could do whatever the designer decided to make the driver do.

That much has never been in dispute.

 

[Helen B]

I think that you should be more careful about your references to the printer and the printer driver in the PC. You appear to be treating them as one entity.

The whole premise of this thread is that the printer cannot do certain things. It is not about what the printer driver can achieve. It may be laughable for the printer to interpolate, but it isn't laughable for the driver to interpolate. They can interpolate, if they are asked to.

Best,
Helen

 

[Moglex]

Yup, and although "The PC can do the dithering" in almost every case except Moglex's special program, it doesn't. In almost all cases the printer driver and printer handle it - not the program.

That is a statement you have made several times but it is disputed.

I have repeatedly explained why what you assert in not achievable within the GUI API.

You continue to ignore all such explanations although, sadly, rather than point to errors of fact or logic you simply pretend the explanations were never given and continue to blindly assert that you are correct.

I am, however, waiting for some evidence from Helen B concerning a most intriguing assertion she has made about the way applications can print.

Watch this space!

 

[Moglex]

I think that you should be more careful about your references to the printer and the printer driver in the PC. You appear to be treating them as one entity.

From the POV of the system architecture the printer and driver can be considered a black box.

For quite some time I pedantically typed printer/driver, but as time went by it should have been perfectly obvious that 'printer' was sorthand for 'printer/driver' and you would have to be being deliberately obtuse to suggest that I'd suddenly split the two as there is simply no way of telling where the functionality that belongs to the printer/driver coupling lies as it is down to each printer designer to decide that and they are hardly likely to put it in the documentation.

The whole premise of this thread is that the printer cannot do certain things.

I'm sorry, but you are absolutely wrong.

It has beem made very clear that the discussion is about what happens on either side of the GUI (note: 'I' = interface). I.e what the printer/driver does as opposed to what the application does.

It is not about what the printer driver can achieve.

Indeed, it never has been a discussion about the printer or driver as individual units since we do not know where the functionality lies - to the user the pair are a black box.

It may be laughable for the printer to interpolate,

No it isn't.

Indeed, a printer that is designed to take images directly from a camera will almost certainly do it.

but it isn't laughable for the driver to interpolate.

It certainly isn't laughable. There just doesn't seem to be any point to them doing so. The photpackage need to have all that logic in it anyway to resize/resample irrespective of printing. Why duplicate the effort?

They can interpolate, if they are asked to.

Perhaps you would be kind enough to provide a source to back that up?

I'd certainly agree that you could write a driver that interpolated - indeed you could write one to do The BBC's payroll if you so desired.

What is unclear is what point there would be to doing so.

 

[Bifurcator]

That is a statement you have made several times but it is disputed.

Only by you. You don't listen to anyone other than yourself and you don't make sense more than half the time. With those two facts as obvious givens you'll never get it right (except in some special case theory that exists primarily only in your own mind and in your own examples) and it's practically pointless discussing it further with you.

When someone shows you or tells you where you're wrong you just twist things around and reassert your faulted premisses in a different way. And you seem to be particularly fond of double negatives, inverse meanings and stating the opposite of the obvious. Like the sentence here http://www.thephotoforum.com/forum/showpost.php?p=1291442&postcount=8 or writing 20 posts demonstrating how completely dogmatic you are about being correct and then saying after all that "which is why I am not dogmatic about being correct".

This seems to be entertaining for you but it's a waste of time for me. So, I'm out of it. I'm just not patient enough for people who think they know everything already and therefore are unwilling to learn. It's my bad. I accept it.

 

[Helen B]

...

The idea of expecting the printer to handle interpolating a bitmap to enlarge it before printing would have seemed laughable to the teams that worked on the design of the architecture....

I then commented

It may be laughable for the printer to interpolate,

To which you replied

No it isn't.

What's the point in trying to have a discussion with you?

Best,
Helen

 

[Moglex]

Well, you have to consider the matter of tense.

I said: "The idea of expecting the printer to handle interpolating a bitmap to enlarge it before printing would have seemed laughable to the teams that worked on the design of the architecture...."

You then said: "It may be laughable for the printer to interpolate"

To which I replied: "No it isn't"

Notice how I made a statement in the past tense (which was eminently sensible in the context of a thread on historical perspective). That statement applied to the situation over a quarter of a century ago.

You the jumped to using the present tense which made what you had said incorrect simply because times have changed.

And I responded pointing out that some printers now almost certainly do interpolate.

(Almost since now the camera -> printer) in the scenario I mentioned is a black box.

 

[Moglex]

Only by you. You don't listen to anyone other than yourself and you don't make sense more than half the time. With those two facts as obvious givens you'll never get it right (except in some special case theory that exists primarily only in your own mind and in your own examples) and it's practically pointless discussing it further with you.

I've listened very carefully to what has been said.

I've explained why I don't believe it supports your assertion.

I've provided facts and logic about the architecture of a graphical OS to support my view.

The problem is that neither you nor garbz ever came back with any sensible argument either:

1) Showing a fault in my objections to your experiments

or

2) Showing an error of fact or logic in what I said about the GUI

When someone shows you or tells you where you're wrong you just twist things around and reassert your faulted premisses in a different way. And you seem to be particularly fond of double negatives, inverse meanings and stating the opposite of the obvious. Like the sentence here http://www.thephotoforum.com/forum/showpost.php?p=1291442&postcount=8 or writing 20 posts demonstrating how completely dogmatic you are about being correct and then saying after all that "which is why I am not dogmatic about being correct".

And once again you make no attempt whatsoever to come up with any rational argument but just continue with the same ad-hominem rants that you have descended to for the last several posts.

So, I'm out of it.

Probably just as well.

You never know, if Helen B comes up with back up for her statement that there are other ways of printing than using bitmaps in the way I have suggested I may still concede that there is a possibility that things are done in a different way.

 

[Helen B]

Well, you have to consider the matter of tense.

I said: "The idea of expecting the printer to handle interpolating a bitmap to enlarge it before printing would have seemed laughable to the teams that worked on the design of the architecture...."

You then said: "It may be laughable for the printer to interpolate"

To which I replied: "No it isn't"

Notice how I made a statement in the past tense (which was eminently sensible in the context of a thread on historical perspective). That statement applied to the situation over a quarter of a century ago.

You the jumped to using the present tense which made what you had said incorrect simply because times have changed.

And I responded pointing out that some printers now almost certainly do interpolate.

(Almost since now the camera -> printer) in the scenario I mentioned is a black box.

Good. Now we're getting somewhere. We've established three things:

1) Printers can, and do, interpolate.

2) What happened a quarter of a century ago is no longer relevant.

3) Things change.

Changes happen, such as device dependent journal files (that are resolution dependent) being replaced by EMF and EMF+ files that are not device dependent, and that carry more information than a simple bitmap.

By the way, I wrote 'may be laughable'. The point of the sentence was to suggest that printer drivers can interpolate.

Best,
Helen