Re: [lmi] Replace XSL with wxPdfDocument?

[Vadim Zeitlin]

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 think I spent plenty of time myself working
GC> in the code that generates PDFs, and I don't remember anything PDFish
GC> about it, so I went back and examined it again...and it really is
GC> transparent. It looks like the way we used to draw things on the
GC> screen in msw-1.0 thirty years ago--picking brushes and drawing into
GC> device contexts. I couldn't have written the group-quote code myself,
GC> but I can maintain it easily--it all seems so clear as to be obvious.

 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 finally chose the latter because it's higher level
and so meant I could do the work faster and also because it allowed me to
use the existing wxHTML code to render HTML directly into PDF -- which was
another productivity boost. Finally, a potential, although not currently
realized advantage of using wxPdfDC, is that the same could could be used
to preview the PDF on screen and I thought it could be useful to allow
doing this in the future.

 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
doesn't support many features of modern graphics APIs, such as (but not
limited to)

- Arbitrary affine coordinate system transformations.
- Alpha channel (transparency).
- Non integer coordinates.
- Paths.

All of those happen to be supported by the PDF format and while I am not
sure if we need either of them right now, it might be unwise to restrict
ourselves to a couple of decades old API without any support for them.

 OTOH I still think that the possibility to use the same code to generate
PDFs and show them on screen for previewing is quite nice. Of course, lmi
currently allows to "postview" the generated PDF files which is not that
different but I think previewing them before the generation could be even
nicer. If nothing else, it should be much faster for big PDFs as we
wouldn't have to generate the entire PDF at once but could start previewing
immediately (well, after generating the first page).

 So it's not totally clear to me whether the new PDF generation code should
use wxDC-compatible API or directly work at PDF level. There is also
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...).


GC> Most of our PDFs are created with XSL-FO, which is, in comparison, is
GC> incomprehensible. Can we translate all that old XSL-FO junk to clean
GC> wxPdfDocument code?

 We definitely could, the question is just about how exactly to do it. One
strategic question is whether we want to put everything in the XSL files in
C++ code or if we still want the PDF format/layout to be configurable via
the external files? In principle, the idea of not hard coding all this
seems quite attractive to me, IMHO it's just the awfulness of the XSL
syntax that makes it unappealing in practice and I guess we could come up
with some much simpler and saner external format defining the document to
output. Or do you think this would just lead us to reinvent XSL, poorly (a
truly horrifying thought)?

 Please let me know what do you think about

1. Using wxDC vs wxGraphics vs PDF API directly.
2. Using external PDF templates vs hard coding everything.

 Thanks in advance,
VZ