RE: [XaraXtreme-dev] EPS export

["Gerry Iles" <GerryI@xxxxxxxx>]

Errr, what is full of virtuals?  I presume you mean wxDC.  Well, under
MFC, CDC is the class that simply wraps a Win32 HDC so there are no
virtuals involved.  Unfortunately, in wxWidgets, there is a class
hierarchy of DCs (similar to our CCDC hierarchy) but to link the two
hierarchies together is not really possible.  This is why CCPaintDC was
changed to derive from wxPaintDC rather than CCDC (as it requires the
functionality in wxPaintDC).  You may have to make similar changes for
the printing and/or export DCs if this is compatible with how the DCs
get created during printing or export (e.g. derive ExportDC from one of
the derived wxDC classes if it is possible for the app to create its own
DC for the print job).  However, I suspect that wx will actually create
the relevant type of DC and the just has to use it so it might be
necessary to reorganise things a bit (e.g. make CCDC contain a wxDC*
rather than be derived from it).  I think this will be a large amount of
work.

The plugin filter stuff doesn't export in the same way.  The "rendering"
that it does is either simple rendering into bitmaps or uses a
specialised render region that does not output anything to a "device"
and hence does not need a DC (of any sort) to render into.

Gerry

-----Original Message-----
From: owner-dev@xxxxxxxxxxxxxxxx [mailto:owner-dev@xxxxxxxxxxxxxxxx] On
Behalf Of Alex Bligh
Sent: 12 June 2006 16:20
To: dev@xxxxxxxxxxxxxx
Cc: Alex Bligh
Subject: Re: [XaraXtreme-dev] EPS export

Gerry Iles wrote:
> Well, it shouldn't interfere with anything really.  The various
internal
> filters shouldn't interfere at all with the plugin ones.

OK

> I suspect that the largest issue with the postscript related code will
> be that it does some bad things with char/TCHARs (e.g. it uses ascii
> strings for most things but then calls stuff that takes a TCHAR*
passing
> a char*).  On our Unicode builds this is going to fall over in a
pretty
> big heap...  These problems may be due in part to strangeness in the
> tokenisation handling in CCLexFile...

Yeah. I am converting it to use TCHAR everywhere except for the file
header checking. Seems the easiest way.

> Yes, PS printing will also need lots of the kernel-y PS stuff to be
> working.

Indeed.

My current problem is that EPSExportDC is derived from CCDC which
in turn is derived from wxDC. This has so many pure virtuals
(many tens of them) that I can't see how this is ever meant to
work. In the windows build it seems to be derived from CDC,
which I am guessing is somehow not full of pure virtuals.

How are you handling this with your filter code?

Alex