[wx-dev] Re: Needing infos and test/sample application(s) for wxWidgets printing framework

[Stefan Csomor]

Hi Ulrich
 
> > For the wxGraphics backends that offer good PDF support, I think it
> > is advisable to go through that route.
> 
> You're probably right. But which backends do already offer good PDF
> support? How do you define 'good' PDF support? (I took a look at the
> sources of the PDF backend of Cairo. For example output of text is
> currently definitely not very efficient, since every single glyph is
> output including metric information instead of complete text
> strings.)

Quartz PDF output is great :-)
 
> > For all other systems, I think a wxPdfDC is needed, otherwise the
> > feature won't be used.
> 
> The availability of a wxPdfDC would probably increase the number of
> users of wxPdfDocument, but wxPdfDocument has features which wxDC has
> not, for example internal and external templates. So I guess for some
> people it will be useful even without a wxPdfDC. At least it is for
> me. :-)

Sure, what I meant is that wxPdfDC is needed, and that on some platforms
this might be implemented using a native backend and on all others using
wxPdfDocument

> > Of course it would be great if you could implement it as a
> > wxGraphicsContext subclass.
> 
> Most methods of wxGraphicsContext could be mapped to wxPdfDocument
> without too much effort, I guess. Some would require minor
> modifications
> or extensions.

> What would be the best approach to test the implementation of wxPdfDC
> and/or wxPdfGraphicsContext? If there is a test application for DCs
> somewhere available I would certainly prefer to use that one instead
> of
> creating a new test application.

One idea would be to use the graphics test application, switch the DC it
is generating its output on to a wxPDF and dump that file
 
> > IMHO fonts must be embedded, any truetype or postscript font that
> is
> > allowed for embedding and exists on the users system must be usable
> > without any preparation, or command line utility.
> 
> Well, that's a really hard requirement. As every component using
> fonts
> wxPdfDocument needs information especially about the font metrics.
> Currently a command line tool is used to create font description
> files
> for wxPdfDocument (fulfilling a similar purpose as AFM files for
> PostScript printing). Certainly it would be possible to create the
> internal font data structure used by wxPdfDocument on the fly, but I
> fear that's a bit beyond my capabilities. It would probably mean to
> use
> the FreeType library and/or OS specific methods.
> 
> Do you have any suggestions how to approach the font handling
> problem?

Libharu already does support reading in font files, so I just had to
write the code to find a font's file on the system. I think truetype
fonts should be easy enough to read in at runtime, using freetype might
be an option as well. But unfortunately most scripts on OSX are
postscript fonts in opentype format, which libharu doesn't understand
yet. So I had to use Quartz PDF 

Best,

Stefan