That would be one way. Whereby you would not have to cache the properties, since PDFGraphics is a subclass of Graphics. You can set g.DrawingColor etc. directly as usual.
Why would you need to make updates every time?
Of course you can. You only need to filter the pages you want and then you can simply draw them with a For...Next loop. Or do I understand you wrong?
I know it’s not LibHaru … from what they have said, I think it is totally home grown .
BTW because I needed table support for my current project, I added (as well as page numbering) minimal Table functionality that includes support for cell text styles for the Einhugur PDF plugin…
When I am done with this project I am thinking of fleshing it out and doing a few more things to make it easier to use.
Yes I am “closefisted” 
As I don’t make money with Xojo and there is a significant possibility I may be involuntarily retired fairly soon, the Einhugur plugin set is more financially attractive!
I would rather not need plugins at all… but Xojo is missing too much of what I consider basic functionality in PDF and other things as well (heck they don’t even include Zip functionality!)
-Karen
since 2020r2 it is very lowres before if was ok
I know it has to do with a bug fix they did, because before it was impossible to scale pictures with the DrawPicture Method. They are aware of it.
This is something I was talking to Geoff about recently. They don’t see a need for it yet, but would implement it if a sponsor could be found. Do we want to start a Kickstarter campaign? 
Because one needs more features. Implementation right now is very minimal IMO
If I was to do what you propose, I would want it to be reusable in future projects and
as I said there is a significant amount of coding needed to get to the point one could do that.
As the Xojo PDFGraphic class feature set currently is IMO minimal I would want to update it to support any new features Xojo adds…
What i think Xojo Inc should do is add a PDF.Page class and GetPage(PgNo) and PageCount method to the PDFDocument class.
The PDFPage class would have all the PDF specific features of PDFGraphics EXCEPT PDFGraphics.Nextpage. (it could be the superclass of PDFGraphics)/.
PDFGraphics.NextPage would just create the page and add it to the PFDDoc
Th pages the would not actually get "rendered "until the doc is saved. That way they can keep the existing printing like API using the PDFGraphics class, but still allow access to and updating of the pages after initial rendering.
But then they could also add an PDFDoc.AddPage method that allows setting variable page sizes and be a more object oriented API for PDF creation…
And of course one could mix the 2 either way as pages would be saved sequentially in the PDFDoc class either way.
IMO the current design as is, is just too inherently limiting because it was ONLY designed to mimic old fashioned IMMEDIATE printing to paper… It really does not need to be to maintain compatibility with that…
LibHaru is abandonware. The current one active, and very complete, is PoDoFo. https://sourceforge.net/projects/podofo/
active and no modification since 2 years ?
Last patch accepted is dated 2020-10-10, you mean 2 month?
Here is the tarball: https://sourceforge.net/p/podofo/code/2016/tarball?path=/podofo/trunk
Can we please get back to the topic of this thread? We all know that there are alternative and more feature rich PDF libraries. This is about what features you would like to see from Xojo in the future for PDFDocument and PDFGraphics to be productive for you.
Thank you.
I just listed one solution for the thread.
So I’m on topic and collaborating for the solution.
It includes all the main requested features that could enable Xojo to deliver them.
Thank you.
Am so confused…I just downloaded their repo probably for the 100th time…
And first thing that faces me is GNU license. (I thought from memory it had been at least something a little better ?)
But as GNU then I am not sure how Xojo or anyone should be able to use it ?
I want what I thought we were getting when this feature was first announced: Print to a PDF the same objects, with all of the same attributes, using the same methods, that you can print in a Graphics instance. Anything and everything, on whatever page or graphics size that can be provided by the OS. Things like DrawString, StringShape, whatever - with .StringWidth working the same. So that means embedded fonts, too. I don’t need encryption, or comments or table of contents - though they would be nice. Having the resulting PDF searchable would be high on my list, too.
PoDoFo is LGPL, it means “can be used commercially without changes to its code, if changed, if you fixed something or added features, you must provide the source of SUCH CHANGES”. Just don’t statically link it to your app, dynamically load it as a separated .DLL, .so, or .dylib and you are legally covered that your code is not mixed with the LGPL lib code. Just provide a link to the online repository of PoDoFo for those interested in downloading the code too.
You must be confused by the fact that THE TEST codes and TOOLS included, are GPL. You wont deliver this part with your app.
This is what I get inside the COPYING file:
GNU GENERAL PUBLIC LICENSE
Version 2, June 1991
Copyright © 1989, 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Read my post above yours.
The Copying is for Tools and Tests, Copying.Lib is for the lib.
Sadly the LGPL wont help we cannot deploy libraries with the plugins. Though Xojo technically could from their framework I would think since they of course control the whole build process.
Yes. They can load libs as needed by their framework, (the App Libs folder) and the discussion here is about their PDF support for the language. For such case, it is ok.