Richard's novella on the philosophy of printing (was Re: Report Object...)

Richard Gaskin ambassador at fourthworld.com
Mon Jun 16 03:17:02 EDT 2003


SimPLsol at aol.com wrote:

> HyperCard, at $99, had better built-in reporting a decade ago than the $1000
> edition of Revolution has today!

But without integrated color, multiple window styles, scrollbars, vector
graphics, animation, list fields, geometry management, regular expressions,
arrays, multiple object selection, image objects, nested groups, tab
controls, socket support, "repeat for each", "try"/"catch" constructs, case
statements, built-in compression, object cloning, binary read/write, custom
properties, database integration, alias support, frontscripts and
backscripts, Unicode, XML, drag-and-drop, cgi options, milliseconds, QT
transitions, QTVR, localized date formatting, backdrop, multi-state icons,
"pre" messages, tooltips, custom window shapes, screen capture, >32k
scripts, >32k fields, blinding speed, compatibility with OS X and 10 other
operating systems...and the ability to remain viable, just to hit a few
hilites.  ;)

It's not like the Rev folks have been sitting by the pool drinking mai tais
all day.

So while it's true that HyperCard did an admirable job of providing strong
printing, Rev has more printing features than any of the other xTalks I know
of and a good many other features besides.  These include even basic things
like multi-object selection that so hampered productivity in HC that
strategies for dealing with it were a chapter in every major recipe book.
And unlike $99 HyperCard, Rev is still being developed, its engine the
longest-lived xTalk under a single company.

No doubt Rev will continue to make software development ever easier, and the
printing functions in v1.0 and tools in v2.0 would seem to demonstrate it's
a priority to them.

But in all fairness, priorities must be balanced on a number of factors.
I'm not privvy to their evaluation process, but common factors include:

- the number of people who need a given feature
  (many applications do no printing at all, and those that do
   have needs that vary broadly)

- whether a solution can be scripted with the existing engine
  (Jacque, myself, and many others have delivered printing solutions
   far more complex than most people need; a lot of print jobs are
   single-page forms or things like envelopes which come down to
   laying out a card and printing it with a few lines of Transcript,
   sometimes just one: "print this cd").

- relative cost vs. return on that investment (ROI).

Lets look at this last one in depth:

The analogy of "reinventing the wheel" comes up frequently in discussions
pursuing printing tools, and it may be an even better analogy than
anticipated.

"Inventing the wheel" implies a lengthy process of experimentation and
discovery, but the outcome is more valuable as an idea, as _knowledge_, than
any specific implementation.  If the first wheel was a stone disk mounted on
a wooden axel, the knowledge is useful for making wheels for a delivery
truck but the specific implementation would be of little practical value on
the freeway.  :)

To focus exclusively on a tools-based solution for printing extends the
analogy to building one factory that will manufacture all wheels for all
types of vehicles, from flower carts to airplane landing gear.

As a toolmaker by nature I'm usually inclined toward generalization, but
I've devoted enough years to building tools to recognize their limits in
terms of ROI, and to try to find the appropriate dividing line for the task
at hand.  Building one factory to construct all possible wheels likely has a
lower ROI than building multiple vehicle-specific wheel factories.

Reports Data Pro comes very close to The Ultimate Printing Tool in many
respects, but it represents an intersection of interests tied to a specific
moment in time:  it was developed when a major OS vendor was heavily
evangelizing a product which used an extensibility mechanism adopted by a
good many other products at the time (Apple pushing HyperCard which used
XCMDs).  The developers of Reports Data Pro thus had a ready market
established and nurtured by the largest possible player in their world,
allowing them a healthy return on their investment.

Rev has not yet been pre-installed on every hard drive, so they have to work
a little harder.  

And with the standard XCMD interface non-existent on OS X and all non-Mac
platforms, any multi-platform solution created for use in Rev would be best
served using the Rev native file format, which would hinder its options for
seeking additional return by interfacing it with other programs like
SuperCard, Director, etc., as Reports Data Pro was able to do once upon a
time with XCMDs.

It's worth noting that the developer of Reports Data Pro has made no attempt
to update the product for use in modern tools.  I suspect ROI considerations
play a role in that decision.

So as much as I agree that Reports Data Pro was a way cool solution, I don't
feel it's fair to require RunRev to build it into their product at this
time.  It's a non-trivial task, and a review of of costs and market
conditions suggest that the incremental approach they're taking with regard
to printing solutions may be more optimal for their product as a whole.

If we may put that aspect of the discussion to rest, we can get back to the
more immediate question:

   How does one print complex reports in Rev?


Three options come to mind:

1. Wait for RunRev or a third party to build something
   like Reports Data Pro.

   Risks: May or may not happen, and if it does it's not likely
          for some time; unknowable licensing costs.
   Rewards:  No time investment in rolling your own.


2. Build The Ultimate Printing Tool as a product yourself.

   Risks:  Very expensive to develop and support; relatively small
           market today; possible negative ROI.
   Rewards: Total control over the printed output; possible profit.


3. Build a solution for the task at hand.

   Risks:  Development time (though much less than #2 by far)
   Rewards: Total control over the printed output; immediate results.


Having given the matter some thought over a few years, I've been advocating
#3 as the optimal risk/reward balance at this time.   The raw materials
exist in the engine, and I've seen no type of report yet that can't be done
with the engine as it is today.  The question, as with nearly any software
feature, is whether a particular type of printed result is worth the effort.

If #3 is good, why isn't #2 better?

The answer is the difference between the knowledge of what a wheel is and
what it can do for you vs. making a wheel-building factory for all possible
types of wheels.

As Steve McConnel writes in "Rapid Development":

   "The difference between a tool and a product is that
    with a tool it need only be possible to use it correctly,
    but with a product it should be impossible to use it incorrectly."

The cost for developing and supporting a tool for printing from one data
source to a limited number of formats is likely an order of magnitude lower
than building a product that can handle any relevant data source in any
desired format.

This is why I've been advocating a knowledge-based approach for the moment
over a tools-based approach:  you can get results for lower cost, and
sooner.

So while there may be interest in underwriting dvelopment and support of
such a product down the road, in the meantime I've been more interested in
sharing the knowledge of using Rev's existing printing capabilities to get
results today.

If you can afford to wait for a point-and-click solution, there's no harm in
waiting.  Version after version Rev provides stronger printing options, so
sooner or later you'll likely get what you need.

But if you have a particular printing need that can't wait and are
interested in learning a few things about working with Transcript, it's
likely doable now.

-- 
 Richard Gaskin 
 Fourth World Media Corporation
 Developer of WebMerge 2.2: Publish any database on any site
 ___________________________________________________________
 Ambassador at FourthWorld.com       http://www.FourthWorld.com
 Tel: 323-225-3717                       AIM: FourthWorldInc




More information about the use-livecode mailing list