Old feature request: Printing wanted


#1

I’ve brought this up before but I think it needs reconsideration.

For me, printing is a much wanted feature. Without going into too much detail, one of the reasons I want it is note typesetting.

A while ago I did some fiddling with PDF export but I gave it up for several reasons: the only really free C code I could find was rather old and didn’t cover gradients, transparency and other features very relevant to Juce rendering that have been added to the PDF format later, the PDF format in itself is rather complex, I didn’t know how to embed fonts and images, etc. etc., and on top of that, the graphics rendering system of Juce was undergoing changes so it seemed I was aiming at a moving target.

Now that the rendering seems to have found its new form, I figure it might be easier to add printing. I haven’t studied the new rendering system in detail but as I understand, the refactoring was driven by a need to support accelerated drawing by allowing renderers to work on top of platform-specific accelerated apis like Direct2D.

Now, if Juce can do its rendering via Direct2D, or OSX or Linux equivalents, printing might be a matter of directing the platform-specific api to the printing system.

You would still need printer dialogs etc. Perhaps the native dialogs could be used, they may not look perfect in a juce app but this would still IMO be a lot better than not being able to print.

I know it’s not your highest priority but OTOH, it might come easier now, with rendering code on your fingers.


#2

Yes indeed - the new rendering engines are exactly what’s needed for printing, it’d be pretty easy to add printing for the mac now; for win32 it’ll have to wait until the Direct2D stuff is finished. Not sure about linux though, that’s more of a problem.


#3

Is the Direct2D renderer in alpha, beta or RC stage?

Given the current state of the Direct2D renderer, would it be possible for me to print paths and text? (No gradients or images or blends would be needed, just black on white. Text should preferably be printed as such - not as paths - to avoid bloat when creating PDF via the CutePDF printer driver.)

Can I use the stable renderer for the GUI in general and at the same time use the experimental Direct2D renderer for printing?

Have you any plans for adding printer classes to Juce?

BTW vocal scores (which is what I’m going to print) are extremely sensitive to text placement inaccuracies. With my old GDI code, a score may look neat on screen but when printed, the words of the song collide, because of cumulative effects of placement roundoffs of the letters of a word. With GDI, this can be remedied by pre-calculating the letter spacing at printing resolution (600 dpi or so) and then applying it to letters at screen resolution. I wonder if this will be a problem with Juce display/printing? Will sub-pixel accuracy letter placement eliminate the problem? Alternatively, will Juce let me pre-calculate the spacing at high-res and use it for screen display?


#4

The Direct2D stuff’s only alpha, really, I don’t think you’d be able to use it yet.

Well you’ll be very relieved that juce doesn’t use hinting then! Maybe post your comments on the other thread where a bunch of crazy people are asking me to ADD hinting!


#5

I asked for the option of having hinting as a CHOICE when rendering fonts! Believe it or not, not every application that uses Juce requires smoothly scaling user interfaces, or displays carefully laid-out musical scores!

Some of us just want text to appear clear at small sizes, call us CRAZY!


#6

Damn, I should have known it was a bad idea to mention the ‘H’ word again…! :stuck_out_tongue: