RE: [XaraXtreme-dev] EPS export

["Charles Moir" <CharlesM@xxxxxxxx>]

To be honest, going forward, the EPS filter should be done using the new
filter mechanism. This would be a lot more maintainable, much easier to
develop and understand (you wouldn't have to know anything at all about
any render region stuff, or indeed any Camelot internals at all) and
because of this would be much more likely to be maintained by people in
the open source world I would suspect. The new filter mechanism is a
plug-in and so just a lot, lot better.

But I've no idea how easy or how much of the existing EPS filter code
could be used a filter done the new way.

Charles


> -----Original Message-----
> From: owner-dev@xxxxxxxxxxxxxxxx 
> [mailto:owner-dev@xxxxxxxxxxxxxxxx] On Behalf Of Gerry Iles
> Sent: 12 June 2006 17:07
> To: dev@xxxxxxxxxxxxxx
> Subject: RE: [XaraXtreme-dev] EPS export
> 
> 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
>