Looking for developers: processing of Windows EMF files for CUPS, NX, Samba and Freedesktop.org printing

Michael B Allen mba2000 at ioplex.com
Sat Jun 12 03:41:58 GMT 2004

On Fri, 11 Jun 2004 01:29:06 +0200
Fabian Franz <FabianFranz at gmx.de> wrote:
> Spooling EMF to Windows ()instead of raw) to allow usage of the native
> printer driver ...
> Either implement OpenOffice PS-import (We'll need it anyway sooner or
> later) 

I don't think that's possible. PostScript has no logical structure
(e.g. you could have footnotes that are encoded at the beginning of the
file stream). Thus there would be no way to reconstitute the logical
structure of the document. If there are no implementations of something
that would be obviously useful you should probably consider that there
might be a technical limitation that makes the problem intractible.

If you are trying to convert PostScript to EMF there are two issues. The
EMF format is trivial. It's just a recording of GDI commands in 4 byte
aligned records. The problems are fonts and quality of implementation.

Fonts on the client may not be adequate on the host converting to
PostScript. Unless you stick to the 12 base Latin1 and Symbols fonts
you could get a big mess. You will not be able to print Marquee or
Dingbats, etc.

The really hard part is pure programming baby. Some hobbiest type will be
successful but the output would probably be pretty bad. Consider Mozilla
has always had poor PostScript output and that no one had the forethought
to permit swapping display devices to intercept and generate PostScript
from the existing gecko code. Instead they have separate code that
generates PostScript from the document tree. Now we have xprint but that's
not adequite for a variety of other reasons. It's a big flippin mess.

The point is a *good* EMF to PostScript converter requires some serious
forethought and a very good understanding of GDI and PostScript and
where the drawing primatives intersect. It's a little like writing a
compiler actually.

> Even one step further would be to integrate and experiment with that 
> technology in Samba smbspool some more. 
> (Jerry Carter from the Samba Team mentioned it could be interesting to
> change to RPC instead of SMB for that).
> One could also try to enhance libEMF to allow the whole EMF-"standard". 
> (Well, WINE GDI libs and OpenOffice.org source could help)

Yes. WINE GDI code is highly informative for understanding EMF.


Greedo shoots first? Not in my Star Wars.

More information about the samba-technical mailing list