realbasic-nug
[Top] [All Lists]

Re: [ANN] PDF Classes 2.0

To: REALbasic NUG <realbasic-nug at lists dot realsoftware dot com>
Subject: Re: [ANN] PDF Classes 2.0
From: Adam Ernst <adam1234 at athenet dot net>
Date: Wed, 30 Nov 2005 16:42:26 -0600
Delivered-to: realbasic-nug at lists dot realsoftware dot com
References: <BFB28333 dot 5B60%Roph at kc dot rr dot com> <054f3771b6b8e991331d1e1900410907 at fireyesoftware dot com> <525A634E-46F3-4BDA-843A-4A7A4FBFC662 at mobleybros dot com>
On Nov 30, 2005, at 2:55 PM, Phil M wrote:

I was planning on doing something like this... basically I was planning to write a GraphicsWrapper Class which manually duplicated all of the public methods of the Graphic class, except instead of accepting Integer values for position, I would take Doubles and also add a scale factor.

I thinking about adding a stack of drawing commands so that if the scale changes the current stack could be redrawn automatically. The only issue I have with a stack are Picture objects since the same Picture object could look entirely different 5 minutes later... which means keeping a copy of every Picture drawn to the stack and that could get memory intensive.

My goal (like so many others in this thread) was to make an API that allowed WYSIWYG drawing that could be rendered to screen or printer always at optimum resolution/position.

Like so many of my other projects, I have spent a lot of time thinking about this but I haven't been able to set down and start coding. It sounds like there is enough of us interested that we might be able to do a collaborative project.

I've done this in a much more basic form. Two classes, "ScreenPrinter" and "VirtualPrinter" both implement the "Printable" interface in my project. ScreenPrinter just declares all of the methods of the Graphics class and passes calls through to a hidden Graphics instance. VirtualPrinter simulates a Graphics object without actually having to create a picture buffer, just using some simple math. It's not too hard to do.

Still, it would be even easier if RB's language included some kind of way to do this without the wrapper class, like making Graphics into an interface and replacing it with some other class. This wouldn't break code (since we can still toss around references to "Graphics") but would allow us to create classes of our own that implement Graphics.

Of course, it's a pretty niche need, but it would be nice.

Adam Ernst

_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>