On 11-7-2010 7:39, luigi scarso wrote:
2010/7/11 Ivo Solnický
: Now (not addressed to Mojca), please don't be a smartarse and tell me (again) that this is all volunteer work and to send in patches, a new Device Independent file definition and implementation for Unicode. I'm full of admiration for you guys with the giant IQs who have created ConTeXt in tea breaks and at night, never taken a second of time from the employer, publishing house or university or hairdressing salon proprietor that pays you. But I don't pretend to be in that class. I'm just a mental midget. And I have other things to do. It ain't my project. Something else is.
Maybe LuaLaTeX should work for you. But even so there is a dvi-to-ps step to do, which is pratically the same of pdf-to-ps in context mkiv.
one of the reasons behind pdf is that it takes the programming language out of ps which means (1) better portability, (2) faster rendering in addition to that pdf provides a couple of goodies irrelevant to printers (annotations and such) dvi as outputformat is fine, but you then need to inject extra code for each (fundamentally) different backend tex + specials -> dvi -> ps -> pdf tex + specials -> dvi -> pdf tex + literals -> pdf (pdftex) now, as ps is seldom needed as final format it makes no sense generate it (and going from pdf -> ps is easy) using specials (inlined code) is no fun but has alway sbeen supported in mkii (spec-* files) using an intermediate layer in mkiv we have tex -> pdf so no specials and hardly any literals at the tex which is much cleaner; of course there can be more backends but a ps one is unlikely although in principle mkiv could be made to provide dvi to be fed in some backend driver i see no advantage in that Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------