The history of ElePub
When the spiritual father of ElePub introduced the first release
of EleCat in early 1993 (much earlier than PDF was available
or even known, by the way) we learnt from our first customers
that they also had a totally different problem and that was
in getting relatively simple catalog pages efficiently created
from their databases. EleCat was designed to make existing
DTP pages electronically usable - this worked fine but the
customers had a much greater problem in getting their contents
efficiently formatted in the first place. This was all done
manually!
We were asked to automate this process and we used some existing
tools to automatically create layout in some of the major
DTP applications, primarily in QuarkXpress. Later we had to
develop our own "hacks" to circumvent limitations
of the existing tools.
Whatever we did, whatever the database publishing tools offered,
everything was limited by the data formats of the DTP software,
which were developed in the old-fashioned C language and in
"structured programming", concepts from the 70ies
and early 80ies. We were always struck by DTP's sheer incapability
to really place a database item inside a DTP frame and to
instantly respond to changing data on either side. All that
could be placed on a page was a really only a copy of the
database item without any direct and permanent connection
to the database.
No way! A truly instantaneous connection between a database
and any DTP software was just impossible - and it still is
today, except via import and export procedures causing a lot
of alignment trouble on both sides.
The experience gained from generating more than 40.000 pages
via database publishing as a service company proved us that
database publishing in conjunction with today's DTP software
will always remain basically a one-way road and will always
be based on separate data entities.
In late 1999, when we started the development of a completely
new generation of EleCat in pure object-oriented technology
we noticed that our object framework actually had almost everything
we needed for a full publishing software. Only the user interface
and a few processing actions were missing (which were easy
to add). This is why we decided very early to create three
separate but very closely connected products, EleCat, ElePub
and EleStore, from this one central object framework. That
is the great thing about true o-o: you can re-use most of
what you have created!
How should ElePub be designed and architected?
Our experience told us that, unlike existing solutions, we
should not rely on using available DTP software as a "publishing
engine" for our application. Instead, we came to the
conclusion that we should offer the most vital DTP functionality
inside our own system, especially:
o design, construction and storage of page structures
o a stand-alone page editor to visualize database items unconditionally,
directly and immediately without any importing, copying, referencing
etc.
All of the internal object structures and even 90% of the
needed page editor already existed as part of EleCat, so it
was only natural to enhance this into a new and self-contained
type of publishing application.
Almost all functionality common to DTP software has been
included - except for the two areas where these applications
have their special strength, which we should not wish to mimic
or improve, they are:
- color separation
- and some special finesse in using, placing and designing
text and fonts - rarely used in product catalogs.
This resulted in an autonomous publishing application combining
"art and science". We left some of the "fine
art" to DTP but covered all of the "science",
i.e. the entire database functionality, by ElePub. All data
relevant changes are performed inside ElePub and are therefore
unconditionally, directly and immediately stored in the database.
|
