[cairo] EMF output?

[Jan Struyf]

Dear Vladimir and Others,

>> I would like to use the Cairo library save graphs, diagrams and 
>> technical drawings in EMF format. I was wondering if the Win32 surface 
>> is useful for this. Is this a bitmap surface or is it really a vector 
>> surface?
>
> Are you sure?  Saving in EMF/PDF isn't all that useful, because it's 
> very hard to modify the data afterwards.  Unless you're talking about 
> just saving for output only, in which case PDF would be far superior 
> than EMF for that purpose.  The only thing that you'd lose is the 
> ability to move EMF/vector data using the clipboard; I'm honestly not 
> aware of too many apps that can do something useful with that, other 
> than, say, pasting an EMF into a word processing document.

Yes, I meant for saving the output only, that is, to export graphics from 
my application to other applications such as word processing applications. 
On Linux I indeed use .eps/.pdf for this, but on Windows, many users are 
using, e.g., Microsoft Word, where this does not work so well. Recent 
versions do have .eps support, but this tends to look bad on screen and 
possibly also on non-PostScript printers.

>> I found a thread about a patch contributed by Hans Breuer and it 
>> appears that this patch is related to my question because it defines 
>> vector operations for EMF output:
>> 
>> <http://lists.freedesktop.org/archives/cairo/2005-February/002936.html>
>> 
>> Has this patch or similar functionality been integrated into Cairo? Or 
>> is this still a difficult matter?
>
> To support EMF rendering, you'd pretty much need a completely new win32 
> surface that's expressly for EMF rendering; it would need to hook into a 
> different layer of the cairo stack to be able to do it. A GDI+ surface 
> might be useful for this, since (I believe?) you can render to a 
> metafile using GDI+ but I'm not positive.

Yes, this is what I figured after looking at the code. And Hans's patch 
provided some of this functionality. But I guess the main problem was the 
plain old GDI not supporting alpha blending and gradient brushes (not that 
I need these often). GDI+ does support these.

GDI+ can also record the drawing operations to an EMF or EMF+ file (EMF+ 
seems to be an extension of EMF to better support GDI+). So, I think that 
a GDI+ surface would solve my problem. Are there any plans for supporting 
such a surface? (One difficulty might be that GDI+ is C++.)

If so, then I would be interested to help with that.

> I'm not sure about that patch from 2005; there is a current win32 
> surface which is GDI only, renders to bitmaps, and accelerates what it 
> can using GDI functions and hands the rest to fallback code.

It indeed produces mainly bitmaps. I think it only uses vector operations 
to render text.

There appears to be this trade-off between perfectly obtaining the 
intended output with bitmaps or to approximate the output by the vector 
operations supported by the target format. Rush Ta also brought this issue 
up in an e-mail yesterday in the context of the PDF format. I was 
wondering if there are any plans to support an option to choose between 
these two: (1) perfect output, possibly including bitmaps and (2) 
inperfect output, but no bitmaps. Option (2) would be useful for programs 
that mainly do graphs and diagrams, such as Dia. Would such an approach be 
considered (at least for some surfaces) or would this clutter the code too 
much?

With kind regards,

Jan.

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm