Printing (again)

I know this is a sea snake, but so far, how to print with Juce ?

AFAIK, there is the “paint on a sized image based graphic” approach.

However, if I want to use a PDFCreator based printer, all the text will not be searchable (because we will have a “big” picture, not a “content” based page) (and on usual printer, the transmitted stream is very large).

It is possible to map the graphic primitives to system based primitives ?
If yes, how ? (I know about antialiasing and such, but, for now, I don’t care).

My eventual plan is to have a LowLevelGraphicsContext class that sends its output to a printer, but I’ve not had chance to look at doing it yet…

I’ve seen this class, but I don’t see anything related to text output in it.
So, it will still prevent text searching in the “printed” output as text will be “printed” as path.

Yes, it’d need a few tweaks, like moving the text routines from the Graphics class into the low level context.

I would have prefered “it’ll need”… :wink:
Anyway, will you accept a patch to move drawText from Graphics to Low…Context ?

If you want to have a go at a patch, then please do, I’d be happy to take a look at it if you want.

…in fact, thinking about this, it’s not that difficult. All you’d need to add is a method Graphics::isVectorDevice() to indicate whether it’s a printer context or not. Then you’d just tweak the glyph renderer code:

void PositionedGlyph::draw (Graphics& g) const
if (fontHeight < 100.0f && fontHeight > 0.1f && ! g.isVectorDevice())

…so that it always draws glyphs as vectors, and that’d work fine. LowLevelGraphicsContext would also need an isVectorDevice() method for Graphics to call.

I’ll add these tweaks to the next release anyway, though won’t have time to do any more about printing.

I’ve sent it to your email.

The idea is to have a “solid colour” renderer for text as it covers 99% of needs (at least it cover my needs). When other brush are selected, it defaults to the path renderer which is fine in that case.

Tell me what you think about it…

So you’re faster than me… dammed…

I don’t understand your solution.
You need to add some drawText method to the LowLevelContext if we want to be able to print the text as text (ie using DrawText(HDC…) under Windows).
Okay, using a isVectorDevice allow us to discriminate against non vector devices, but it doesn’t do the job…

Or I’m missing something.

You wouldn’t need to do any text drawing via the printer because this would render all the glyphs as outlines, which would look at least as good as the printer’s output.

The only downside would be the extra data to send all the shapes to the printer, but I don’t suppose that makes much difference these days.

I think I wasn’t clear enough.

I want to write a LowLevelContext that override drawText methods so that in the specialized LowLevelPrinter I put "DrawText(HDC hdcOfPrinter, text)" so that text rendering is done in Windows. I am not interested in text rendering. What I want interested about is that it use common functions hence when using a PDF printer like PDFCreator, the text get printed as text and not as outline so it is searchable in the output PDF.

That’s the deal. I prefer to have PDF with text than with outline.

Ah - I see what you’re getting at now, sorry. Yes, obviously to do that, there’d be a fair bit of stuff to rearrange. Maybe it’d be wise to get your context working without the text stuff, and then add that afterwards?

I’ve been needing to do some printing via juce, eventually figured it would take too much time and went the cheap route; I made a completely complient and correct xml/html tree, filled it out, save it out (css and all), and open it with the default internet app (although I do complain to the moron, er, person if they use IE as it ROYALLY butchers the layout, even though it looks perfect and identical in Firefox, KDExplore, and Opera). Works fine that way, plus it let’s me apply different stylesheets through the browser to change coloring and such, easy to do with Firefox.