Graphics and Picture as Vector in PDF…

I am adding a “Print…” feature to a shaded example and found…

If I build the data directly to the PDF, I get Vector data:

g = p.ShowPrinterDialog
If g <> Nil Then
  g.DrawText("My nice Text", 20,20)

but, if I use (print) a Picture, I get bitmap data:

g = p.ShowPrinterDialog
If g <> Nil Then
  g.DrawPicture OffScreen,0,0

In that project, I build in a Function a Picture that holds the TABLEs list, and in a different Function, the Pictures that displays all TABLEs Structure.

Unless I am wrong, I have to duplicate these to create a Vector PDF…

Ideas ?

To avoid misunderstanding, here’s a copy of the image that is generated from a sqlite data base (with a different background for Ian: no yellow in the TABLEs descriptions - cmy(0.10,0.00,0.10) - ):

It’s what I have been doing for the last 20 years.
Two separate rendering routines.
Arguably, if you write for PDF, all you really need is a ‘print my PDF’ function, and ditch the print version.
Ive never gotten round to doing that, I probably should.

OK, thank you Jeff.

I may not be clear on what I’ve done in the shared picture.

I have two Functions who returns Pictures:
a. A Picture with the list of TABLEs (at left)
b. A set of Pictures with the list of Columns in each TABLE.

I print these Pictures into an Offscreen Picture and display the result to screen OR / AND save the result to disk.

So, I will create a monolithic Method that print the data to PDF (or to Printer… depends of the user) as I do on other projects.

I thought the idea was that you could have a common rendering method and pass in either a graphics context for a picture, a printer page or a PDF document page.

This is precisely what the original poster needs to do. His rendering function needs to accept a Graphics object and draw into it; the surrounding code needs to worry about creating the object that supplies the Graphics object.

Fortunately this should be a very easy change to make.

To clarify, the PDFGraphics object is a subclass of the Graphics object. Which means you can pass it to a method that accepts a Graphics object. Put all the drawing code into a method that takes a Graphics object and draw away. Call it with what ever graphics context you want to create the scalable vector version of your printout, PDF file or even a picture object.

Who talked about that ? Not me.

Care to expand your explanation, please ?

That’s normal. Listen to what everyone else is saying.

No. That’s what everyone is saying. You can have a single method and pass it a graphics object from anywhere - printer, picture, pdf, whatever.

Create a new method that takes a graphics object as a parameter. Place all your drawing code in that method. Keep all the code that decides if you are printing or generating a pdf outside of that method.

Now when you want to make a pdf do what you do now but call your new method to perform the drawing, passing it the PDF graphics object.

When you want to print open the printer object and call the new method passing in the printers graphics object.

You can even create a picture and pass the graphics object to the new method. Or even call it in a paint event passing in that graphics object.

The results hires vector graphics.