[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Postscript & Win32 API/True Type
Valeriy E. Ushakov
Re: Postscript & Win32 API/True Type
Mon, 24 Aug 1998 13:50:18 +0400
On Sun, Aug 23, 1998 at 03:26:46PM -0500, Blake McBride wrote:
> It seems to me that there was a time when many thought
> that postscript would take over the world. Postscript is pretty good
> and has many nice features so perhaps it would have been great if
> it did. However, as time progresses, it really doesn't seem like
> postscript is, in fact, taking over the world.
I don't care if PostScript is actually taking over the world or not,
but it's a widely available, rock solid, platform independent, fully
programmable PDL and I completely agree with Jeff that PS is
technically the best target. Besides, as others already pointed out,
several Lout packages rely on (escape to) PS programmability to
implement advanced features like diagrams. Personally, I think this
is a very fine grained compromise that relieves Lout from implementing
fully fledged programming language and yet allow for a fairly advanced
stuff to be done in a clean way.
My only wish for a PS backend is a direct pdfmark support.
> On the other hand, there is an interface which seems to be more
> widely available and much more widely used, that being the
> Win 32 API with its True Type fonts. Not only is it available on
> all Windows platforms but its also available for free under Unix/linux
> (a package called Willows http://www.willows.com).
> Please, no flames. I am no fan of Microsoft either. I'm in no
> way attempting to compare one to the other or say that
> any system or API is better than any other. I'm simply stating
> what appears to me to be facts (that its widely available and
Ok, no flames. Win32 API is Win32 API - which is a tautology, but
what I would like to emphasize here is that Win32 is not platform
independent by definition. I am (and noone is) in no position to say
to someone "you should not develop Win32 API backend" - after all GNU
is about freedom to modify and redistribute, so if you think it's
worth doing you're welcome to. However Win32 is no substitute to PS,
is inferior to PS and the fact that Win32 API is widely used is not
very relevant, IMHO, in this particular context.
And what's even more important is that GDI is not a PDL, it's
immediate and mostly screen-centric by origin.
> Now back to Lout. I don't have a postscript printer and never have.
> (Either short sighted or short money on my part.) Whenever I
> want to use Lout I have to evoke ghostscript. This is kind of a hassle
> because I end up with two steps to run and two systems to maintain.
Is maintaining GhostScript really so much a trouble that it's easier to
write a Win32 backend instead? What about previews? Also, don't
forget that Lout needs several runs on any nontrivial document to
resolve all references. Win32 backend will short-circuit Lout engine
to the output device which seems like an inferior solution to me.
Also, I believe that GhostScript can utilize TTF (via freetype) [does
anyone know something definite about that?]. So the only problem than
is to obtain an AFM metrics for the TTF fonts you need.
There're several solutions for printing PostScript on non-PS printers
available including Windows PostScript driver from Adobe. For a free
solution based on GhostScript check
(though I have no experience with it).
> Would it be possible to have lout write directly to the Win32 API
> and use true type fonts? If there is any interest in this I'd be willing
> to help in building a back end for lout.
May be it's worth to help prospective backend writers by defining the
interface from engine to backend more strictly and switching from
switches to tables of backend entry points a la Unix device drivers.
PDF backend is already written that way and every switch case just
invokes a backend method. Also, some of casing on BackEnd really
checks only if backend is not a plain text, e.g. if you scale, rotate
address@hidden | Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen