Jules wrote:

We’d need an interface. You might subclass the LowLevelGraphicsRenderer to a PrintingRenderer, which is further specialized to a PDFRenderer and possibly real printing renderers to be added later.

Another possible design is to have Printer and/or PrintJob objects which are factories for renderers that implement the LowLevelGraphicsRenderer interface without further public methods.

I can’t judge what’s best here, it depends on what suits your philosophy.

Whichever design wins, there should be methods for controlling these aspects of printing, and possibly more:
[list][]paper size[/][]orientation[/][]resolution[/][]quality[/][]name[/][]perhaps further options such as duplex.[/][/list]

Paper size can be given in inches or metric, or using enumeration values for standard paper sizes A4, letter, legal… I think you might want to dedicate a small class to specifying paper sizes so these conventions could be dealt with without complicating the interface of the PrintingContext. LibHaru defines an enumeration of standard paper sizes, and it might be wise to adopt these values.

Orientation is Portrait/Landscape and should be settable on page basis - it’s not uncommon for PDF documents to mix Portrait and Landscape pages in the same document. (Just imagine a book about landscape paintings - most of the book would be text pages in portrait orientation, but some pages would have a landscape painting so you would need to turn the book over to see it. In a PDF version, these pages would be marked as Landscape and appear as such so you don’t have to flip your head or monitor.) There are possible extensions of the Orientation, and some printer drivers allow flipping or mirroring but this can be emulated by coordinate transformations and isn’t necessary in the basic interface.

Resolution is obviously a dpi value, I don’t think we’ve gone metric yet here.

It’s possible that you’d want to work with multiple dpi values for various aspects of the printing process. Some DTP apps (Pagemaker, for one) let you specify a target resolution and calculate the text flow using that resolution, so the line breaks don’t change when you switch from your proofreading printer to the final high-res printing. For Juce PDF export, some features such as alpha blends and gradients might need to be emulated in the renderer and output as images, and it’s possible that you’d want to control the resolution of these images to avoid bloat.

For offset printer jobs, you might have to take control of the rasterizing - but I think we should leave that out of here. We’re talking general purpose printing, not print shop jobs.

Quality might control compression of images and perhaps switch on or off the emulation of alpha blends and gradients. For real printers, it might control ink/toner savings.

Name is for naming print jobs. I think the PDF files have embedded print job names, not sure though.

LibHaru deals with many intricacies of the PDF format and is IMO a worthwhile addition, at least to get started. Once we get the thing to work, there is still the possibility of factoring out LibHaru later.

Don’t worry about licensing, see, as far as I recall, you’ve already included zlib and libpng in the source tree.

There are some things that will need some fiddling:

LibHaru seems to have its own Stream implementation and I don’t quite know how to connect this to a Juce stream. For my 2009 efforts, I let LibHaru write the whole thing to a stream of its own which was then rewound and copied to a Juce stream through a buffer. No big deal but direct streaming would be more elegant. I guess I could sort this out by digging into the LibHaru sources.

I don’t quite understand how to transfer fonts and images. I think PDF supports PNG or Jpeg but I haven’t sorted out the details. Maybe the renderer should do PNG-compression of images. Exploiting the Jpeg feature would probably require that they somehow be passed through the renderer and I don’t think that’s compatible with how Juce rendering works. But I suppose I could figure out a usable (if not necessary optimal) image transfer. With fonts, I am at loss. Since PDF is an Adobe thing, I assume it uses Postscript font technology but I don’t understand how to connect to Juce font rendering, and I think you would have to do this part.

Text encoding might need some work. Ideally, we’d just transmit utf-8 but I’m afraid PDF predates the utf thing and the encoding is a bit messy, and I don’t think LibHaru takes care of this - but other open-source PDF-generating apps do, so it’s basically a matter of deciphering and copying their encoding schemes. (If all else fails, I’ll grep the OpenOffice sources for PDF export.)

Then, there’s the issue of emulating alpha/gradient stuff - perhaps by using the software renderer to generate images. This might end getting parked on a to-do list. I’d find PDF generation quite useful even without gradients and alphas, and printing applications that need these still have the option of emulating them. Though this isn’t ideal, it’s better than not having PDF.

Enough for now… I hope you will take the time to pin out the interfaces.

you cannot write a full proper LowLevelGraphicsRenderer for PDF in Juce as LowLevelGraphicsRenderers doesn’t handle text output (i don’t think it will ever be implemented). You will end in a driver that will only draw vector data and raster images but no text (unless you stick your own bitmap text routines but then it will be non-standard routines).

the way to go is to wrap libharu in something like a juceified class, that let us work with Ractangle, PositionedRectange, Image and so on…

This is no longer true, see the topic Has the font rendering code changed in the last few months?

erm… maybe you should have a look at the tip!

my bad, i really need to dig into the graphics refactoring ! complete custom opengl guis are a reality then :slight_smile:

btw, thanx for implementing that !

I’m interested in a PDF back end aswell, what the news on this ?

No hot news, I’m afraid. I took a look on the PDF docs and decided I’d rather wait for the Direct2D stuff and create PDFs using a printer driver. Though I suspect the Direct2D renderer development is stalled 'cause cute little Android has made our Fearless leader forget about big bad MSW.

Even with Direct2D support, a PDF renderer would still be a nice and (hopefully) platform-independent way of creating print-ready layout and I think we should consider creating such a thing.

The PDF document format is slightly complicated but not more than can be dealt with. Its graphic capabilities don’t differ much from those of the Juce renderer but text rendering is a PITA, you have to deal with arcane encodings, font embedding etc. and I’m not sure I have the zeal to educate myself about this stuff.