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:

  • design, construction and storage of page structures
  • 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.