obsoleto não significa “não mais usado”, mas sim que já está defasado em relação aos demais.

http://br-linux.org/linux/por-que-existem-poucos-drivers-livres

http://en.wikipedia.org/wiki/PostScript#Use_in_printing

mas no MacOSX foi trocado pelo PDF

http://en.wikipedia.org/wiki/PDF#Other_applications_and_functionalities

As impressoras deveriam ter um interpretador de PDF ou um padrão que o superasse

Agora, vi muita gente defendendo o PostScript. Esse padrão já está bem obsoleto com as impressoras modernas e por isso é que vem caindo gradualmente em desuso. Se o Google conseguir revitalizar o padrão, reestruturando ele para a realidade atual ele pode ressurgir com força.

Quanto a ser minimalista, acho que não. Para mim o pessoal deveria definir uma impressora ideal que pudesse fazer tudo que qq outra impressora faça, daí os softwares mais “próximos” do usuário teriam que deixar fácil o usuário ativar/desativar esses recursos (frente-verso, grampeador, várias páginas por folha, etc.) e imprimiriam o que o usuário quer usando uma linguagem universal. Depois os softwares “próximos” das impressoras além de informarem para o nível de cima se a impressora têm ou não tais recursos (o que afetaria as telas/configurações que o usuário teria disponível para ativar ou não), traduziriam a linguagem universal para a linguagem da impressora.

Sendo uma linguagem simples, concisa e royalty-free talvez alguns fabricantes liberassem impressoras que já entendessem essa linguagem universal (me parece que eles licenciam bem caro o PostScript da Adobe, por isso preferem oferecer drivers para o seu próprio formato).

Um problema que vejo no PPD é que ele deixa tudo livre demais, o fabricante escreve o que quiser como quiser. Assim alguém pode definir um recurso Duplex e outro definir como Frente&Verso, sendo que é a mesma coisa, isso complica a vida dos softwares mais próximos do usuário que poderiam padronizar a forma como é apresentado ao usuário tal recurso.

Mas há outras possibilidades para essas winprinters “econômicas”, além do retorno ao modelo baseado em firmware. Um exemplo que vem rapidamente à cabeça é a disponibilização de um subconjunto um pouco maior (indo além da mencionada impressão de texto em P&B) das funcionalidades hoje providas pelos device drivers exclusivos do Windows, na forma de programas que implementassem uma ABI padronizada, em linguagens altamente portáveis (cujo runtime estaria presente no ChromeOS e em quem mais fosse participar disso) e dependendo apenas de um conjunto de bibliotecas também previamente padronizadas, que também estariam presentes no ChromeOS e em quem mais fosse participar disso.

Claro que isso também conduz, de forma ainda mais exacerbada, às já mencionadas penalidades em desempenho e em aproveitamento dos recursos avançados do equipamento, mas isso em si não seria surpresa alguma. Surpresa seria descobrir que o Google fez este anúncio baseado na expectativa de que todas estas empresas lancem drivers nativos para o ChromeOS.

Pra costurar algo assim, só tem um jeito: a oportunidade de ganho tem que interessar aos fornecedores e distribuidores, superando as desvantagens. Se o Google conseguirá ou não, é algo a aguardar para ver – não sabemos o que ele oferecerá, nem dá de somar toda a lista de possíveis desvantagens (de marketing, de segredos industriais, etc.) que precisarão ser vencidas.

Mas eu não desconsideraria assim, a priori, a hipótese de alguns fabricantes expressivos serem convencidos a tentar algo novo, se a oferta for boa.

P: Mas não dá para padronizar um conjunto básico de funcionalidades?
R: Claro que sim. É por isso que seu PC consegue funcionar em modo texto ou VGA básico, mesmo sem ter o driver de sua ultra-mega placa de vídeo.

P: Então porque não fazem o mesmo com as impressoras?
R: O problema é que muitos dispositivos, para reduzir custos, realizam grande parte de suas funcionalidades na CPU do PC. Na maioria das impressoras de baixo custo, por exemplo, todo o processamento para a decomposição das cores é feito pelo device driver (no PC), e não pelo firmware (software embarcado na impressora).

P: Então… para padronizar um conjunto básico de funcionalidades de impressão, as impressoras teriam que implementar essas funcionalidades em seu firmware?
R: Sim. Se você considerar o “básico” como impressão em P&B, não há problemas, mas se seu conjunto “básico” incluir impressão em cores, considerando que as impressoras operam com diferentes tecnologias e pigmentos, então a decomposição das cores é específica para cada modelo (ou família, pelo menos). Isso implica em aumentar o processamento embarcado, e os custos.

P: O Google conseguirá convencer os fabricantes a encarecer seus produtos, em troca dessa compatibilidade?
R: Tecnicamente, é possível… mas eu vejo grandes dificuldades em “costurar” essa ideia entre concorrentes.

P: Por que a Microsoft não conseguiu fazer isso?
R: Porque nunca foi interessante para ela. Contanto que cada fabricante disponibilize o device driver de seu produto para o sistema Windows, tá tudo certo. Se o produto só tiver driver para Windows, e não funcionar nos outros SO, melhor ainda!

Pois é, isso é bastante chato e seria legal se não fosse assim! Por exemplo, minha multifuncional Epson tem um recurso bastante escondido no windows que me permite imprimir em preto usando só tinta preta(!). No linux não tem jeito, tenho que imprimir em preto gastando também os outros 3 cartuchos…

Isso serviria até mesmo para parte considerável das impressoras legadas, mesmo que hoje não haja um PPD disponível para elas. E teria as mesmas restrições usuais – possível perda de desempenho, possível subaproveitamento dos recursos mais avançados de cada impressora, etc. – mas o essencial, que é a impressão básica de textos e de imagens sem grande esforço de configuração, estaria disponível para todo fabricante que colocasse um PPD das suas impressoras no repositório oficial.