Re: [lmi] Replace XSL with wxPdfDocument?

[Vadim Zeitlin]

On Wed, 04 Nov 2015 14:47:48 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2015-11-03 23:12, Vadim Zeitlin wrote:
GC> > On Tue, 03 Nov 2015 19:51:46 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> Our experimental use of wxPdfDocument for group quotes seems to have
GC> > GC> been a great success.
GC> [...]
GC> >  I have to say that I hesitated for quite some time between using
GC> > wxPdfDocument API directly and using wxPdfDC, which implements wxDC API on
GC> > top of wxPdfDocument.
GC> 
GC> I must try to state some definitions, to make sure I understand clearly.
GC> 
GC> When we say wxPdfDoc, we mean the library whose canonical home is here:
GC>   http://wxcode.sourceforge.net/components/wxpdfdoc/
GC> which provides the wxPdfDC and wxPdfDocument classes.
GC> 
GC> wxPdfDC is the name of a class that the wxPdfDoc library provides. The
GC> library's documentation says it's a "drawing context"; I take it that
GC> this is the same as what ms calls a "device context".

 Yes, everything above is absolutely correct.

GC> wxPdfDocument is unfortunately ambiguous: it's the official name of the
GC> library I've casually though unambiguously referred to as "wxPdfDoc",
GC> and it's also the name of a class in that library. Maybe I should start
GC> saying simply "the PDF library", or "wxPDF" (by analogy with "wxHTML").

 Good idea, let's use wxPDF for the library.

GC> I gather that the wxPdfDC and wxPdfDocument classes both satisfy our
GC> needs, in different ways, and that we can choose whichever we prefer.

 Yes.

GC> >  But there are drawbacks in using wxDC-compatible API instead of native 
PDF
GC> > one as well. Mainly they're due to the fact that wxDC API is ancient and
GC> 
GC> I'm still not sure why you used the word "ancient" to describe the wxPdfDC
GC> approach. The wxPdfDoc library is only ten years old. I thought that maybe
GC> wxPdfDC depended on wxDC, which might be old;

 Yes, it does, and yes, it is. wxPdfDC implements wxDC API which definitely
means that it tightly depends on it. There is an extra complication here:
instead of wxPdfDC deriving from wxDC, as you could image it would be done,
we actually have wxPdfDCImpl implementing wxDCImpl pure virtual methods
where wxDCImpl is used/contained by wxDC, but this is irrelevant to our
discussion.

 What counts is that logically, if not actually at C++ level, wxPdfDC
"IS A" wxDC, i.e. a kind of a device context. This means that any code
using wxPdfDC must, necessarily, use wxDC API and hence use other wxDC
subclasses, such as wxPaintDC, to draw the preview.

GC> Is it the wxDC API that is an ancient underpinning of wxPdfDC? If so,
GC> would you say that the wxDC API is in need of modernization? Or, rather,
GC> that any API based on device contexts is presumptively archaic and should
GC> be replaced by a completely different kind of API? I'm guessing it's the
GC> latter, because you go on to say that the wxDC API...

 Yes, you're guessing correctly. While wxDC API is not going anywhere
(compatibility and all that), it's a bad match for modern graphics APIs it
actually uses and, as I wrote, on non-MSW systems wxDC API is actually
emulated in terms of newer wxGC ("graphics context") API already. I think
it's wiser to write any new graphics code using wxGC API rather than wxDC
API.

GC> http://wxcode.sourceforge.net/components/wxpdfdoc/
GC> | Enhancements planned for the next versions:
GC> |   Version 0.9.5: wxWidgets printing support via wxPdfGraphicsContext
GC> |   based on wxPdfDocument.
GC> 
GC> Is that exactly what you mean when you say "wxPdfGraphics"?

 Yes, but...

GC> I'm not sure because the cited passage seems limited to printing,
GC> whereas I think you're talking about something more general.

... I'm not sure what's the story with printing neither.
wxPdfGraphicsContext would basically be the same thing to wxGraphicsContext
as the existing wxPdfDC is to wxDC and I _think_ that this would work
better with printing under Linux and Mac OS X. Under MSW it isn't really
going to change much with respect to printing AFAICS.

GC> Would you say that wxGraphics provides a modern API, while wxDC
GC> provides an ancient one?

 Yes, absolutely.

GC> group quotes seemed so familiar to me, because the msw programming
GC> books on my shelf are all for msw-3.x .

 I.e. GDI, which is contemporary to Xlib and QuickDraw. While wxGC
corresponds to the model used by GDI+ and Direct2D under MSW or Cairo in
the Unix world -- and also PostScript, PDF and SVG, just to give more
examples.

GC> If I've understood all of that correctly, then it would seem that
GC> a modern PDF library using the wxGraphics API would be the best
GC> replacement for XSL. Group quotes were a peripheral task, but
GC> illustrations (formatted by XSL at present) are at the heart of
GC> what lmi does, and we want to lay the best foundation. Have I
GC> understood all of this correctly now?

 You understood absolutely correctly what I was saying and I definitely
agree that wxGC API is a better choice for important new graphics-producing
code nowadays than the "classic" wxDC API.

 Please let me know if you have any other questions,
VZ