Re: [lmi] Replace XSL with wxPdfDocument?

[Greg Chicares]

On 2015-11-03 23:12, Vadim Zeitlin wrote:
> On Tue, 03 Nov 2015 19:51:46 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> Our experimental use of wxPdfDocument for group quotes seems to have
> GC> been a great success.
[...]
>  I have to say that I hesitated for quite some time between using
> wxPdfDocument API directly and using wxPdfDC, which implements wxDC API on
> top of wxPdfDocument.

I must try to state some definitions, to make sure I understand clearly.

When we say wxPdfDoc, we mean the library whose canonical home is here:
  http://wxcode.sourceforge.net/components/wxpdfdoc/
which provides the wxPdfDC and wxPdfDocument classes.

wxPdfDC is the name of a class that the wxPdfDoc library provides. The
library's documentation says it's a "drawing context"; I take it that
this is the same as what ms calls a "device context".

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

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

>  But there are drawbacks in using wxDC-compatible API instead of native PDF
> one as well. Mainly they're due to the fact that wxDC API is ancient and

I'm still not sure why you used the word "ancient" to describe the wxPdfDC
approach. The wxPdfDoc library is only ten years old. I thought that maybe
wxPdfDC depended on wxDC, which might be old; but wxDC is used only in
wxPdfDC::DoBlit(), so it looks like I may have guessed incorrectly.

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

> doesn't support many features of modern graphics APIs
[...]
> another possibility: implement a wxGraphics backend using the low-level PDF
> API. This would retain the advantage of allowing to use the same code for
> PDF generation and previewing while giving us access to all the features
> above as they're support by wxGraphics. This would, however, require extra
> work as such wxPdfGraphics doesn't exist (although wxPdfDocument
> documentation says it's planned...).

http://wxcode.sourceforge.net/components/wxpdfdoc/
| Enhancements planned for the next versions:
|   Version 0.9.5: wxWidgets printing support via wxPdfGraphicsContext
|   based on wxPdfDocument.

Is that exactly what you mean when you say "wxPdfGraphics"? I'm not
sure because the cited passage seems limited to printing, whereas I
think you're talking about something more general.

Would you say that wxGraphics provides a modern API, while wxDC
provides an ancient one? That would explain why the wxPdfDC code for
group quotes seemed so familiar to me, because the msw programming
books on my shelf are all for msw-3.x .

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