Here is a detailed list of Elepub's features and attributes. On the other pages of menu "Details" you find further explanations on important aspects and also several drawings explaining technical views.
Concepts and main features overview
Object-oriented publication and page structures
Elepub creates publications in its own page and layout structures, which are composed from complex 3D, multi-level and dynamic object structures consisting of arbitrary collections of the different frame and other publication object types (classes) as described below. Publications are stored in an object-oriented database.
As an essential feature, pages are constructed from nested container frames each holding frames and/or other containers. Each of these container frames constitutes a universe for its members, and the container with all members is handled and used as an entity. The use of 3D container frames is a major difference and fundamental advantage over all conventional DTP software where frames are placed directly on 2D pages.
This encapsulation of frames in containers greatly simplifies the automatic or manual construction of pages and publications from pre-defined and re-usable layout modules defined by containers and their members. Depending on the type and size of their member frames each instance of these layout containers knows its individual size but inherits most of its other attributes and values from its "mother object" (see below).
Object oriented storage of publications
Elepub stores publications as persistent objects in its object-oriented database. Such nested object structures are transformed to conventional flat-file structures when they are exported to XML or to DTP software such as QuarkXpress, InDesign or Framemaker or when creating HTML. Object structures can also be imported.
Integrated page editor
Elepub comprises of a full page editor, which can be used to create and modify pages and its components. Therefore, all pages are created and edited completely inside Elepub. When pages are ready for use they are exported to DTP software or to XML. Typically, there is no need to "finish" pages in DTP software.
Inheritance from "mother objects" in object repository
Data inheritance avoids data redundancy and it is a far more intelligent form of re-using data than copying. It also substantially eases the construction of pages composed from nested container and frame structures.
Elepub comprises of an object repository storing inheritable mother objects for frames, layout containers and other objects. Pages are constructed by referring to and inheriting from such repository objects. Frames on concrete pages have their own location and often their own size but they inherit most of their other attributes from their mother objects in the repository. They are children of one such mother object.
Data in the database
User data in Elepub frames is data "in" the database and not data "from" the database because data is typically loaded each time that a page is displayed. The data inside Elepub frames is not a link to or copy of the data in the database but it is exactly the same data entity as in Elestore - formatted by its frame. Therefore, any change to a datum on a page is a change to the datum in the database and vice-versa.
DataLinks in frames
Most frames are owners of DataLInk objects, which establish the reference to Elestore and via Elestore to external databases (see Elestore for details). DataLink objects not only link frames to and access database entities but have also the capability of caching data values temporarily or permanently. Further, they can act as persistent data storage for "frozen" data, which originated from the database but which is supposed to stay independent of changing database values from a given moment on (editorial deadline).
Integration with Elestore Object Content Management System
Elepub is completely integrated with Elestore and relies on user data supplied by Elestore from either its internal object database and/or from external databases. Technically, both were developed as one unit.
Integration with Elecat
Elepub was also designed to generate e-paper pages for distribution and use in Elecat, the e-paper product catalog software. Elepub pages can be exported into Elecat's CDF Catalog Data Format files.
Integration with DTP systems
Elepub supports the three major DTP software packages QuarkXpress, InDesign and Framemaker in that it exports entire page structures to these DTP software systems for color separation. Still, DTP software is not needed to create publications for paper, e-paper or HTML with Elepub - except for color separation and some special finesse in using, placing and designing text and fonts - rarely used in product catalogs.
Elepub comes with a well-equipped repository database of generic and re-usable repository objects such as mother objects, containers, frames, tables, table cells and other object types.
Real pages are constructed from children of repository mother objects by grouping children in containers and placing those containers on pages. Children objects re-use most of the attributes defined in their mother objects. They are capable over overwriting any inherited attribute with their own value. Elepub comes with a well-filled object repository ready for use so that there is no need for lengthy preparations.
Objects in the repository are organized in an inheritance hierarchy:
- Sarah objects at the top are supplying all basic attributes needed for frame objects to exist at all.
- Foundation objects inherit from Sarah objects and own database links connecting Elepub with Elestore.
- Mother objects inherit from foundation objects and add all formatting and positioning attributes.
- Layout containers are composed from several mother objects and are used to form pages via inheritance.
Frames and containers on publication pages inherit from repository layout containers or mother objects. This multi-level inheritance tree allows for a well organized creation and frequent re-use of frames and containers avoiding data redundancy found in conventional DTP systems. Also, changing attributes of just a few repository objects can substantially change the entire publication without any editing of pages. Just a change to the data links in mother objects instantly changes the data visualized in a given publication. This is also the reason why one only needs to turn one switch to present a publication in another language.
Foundation objects inherit from the basic Sarah objects and establish a link to a user data entity in Elestore or via Elestore to an external user database. They are still independent of visualization and formatting.
Mother objects enhance foundation objects with formatting and visualization specific attributes such as size, relative or absolute location and relation to other objects inside the container and all font related attributes etc. They are the basic building blocks for creating layout containers and/or real publication pages by creating children of these mother objects and placing them in containers or on pages.
Layout containers are the primary building blocks for creating concrete pages by placing children of layout containers on a page (a page is really the outermost container). Containers typically adjust themselves automatically during the page generation process to the individual format and size needed under the given circumstances - depending on the various settings, the content and other objects inside their container.
Master pages are special page containers providing an additional basic layer to all real pages referring to one specific master page. Master pages are holders of frame objects with repeatable content such as page headers or footers, which is supposed to be visually present on all real pages. Master pages separate such repeatable content from the content of the real pages by placing all their members on a special page layer. A publication has at least one master page but every section can also have its own individual master page.
Organization and visualization of the repository
The repository is organized similar to a publication but stored in a separate repository database. Repository objects can be visualized on pages and edited similar to real publications although this primarily serves for a visual handling and a better understanding for the user.
In Elepub publications are stored in an object-oriented database and not in files as in DTP software. Such a database is the precondition for many of Elepub's substantial advantages over conventional DTP software.
Publication is a logical entity composed from one or many chapters with one or many sections with one or many pages each composed from one or many layout containers with one or many frames. Publications are stored in the Elepub object database. Technically, any number of publications of any size is supported.
Chapters organize the content of a publication into logical entities similar to a printed publication.
Sections organize the content of one chapter into one or many logical entities each with at least one page. The primary purpose of sections is in acting as holder for an object sequence and for a master page.
Pages are holders for layout containers with frames. Technically, a page is the outermost container frame. Pages are grouped sequentially inside a section and their numbering and naming is independent of their sequence. Pages can be created automatically by the PageGenerator or manually in the PublicationBrowser.
Pages consist of several different layers. Frame and container objects on pages are placed on one of these layers. Layers can be handled as an entity in that all objects on one layer become invisible, non-selectable, unmovable or excluded from export or printing etc. Some layers have specific pre-defined purpose.
Elepub supports several different frame types with individual behavior such as TextFrames, ImageFrames, Tables, TableCells and container frames. See further details below. Frames have a high degree of autonomous capabilities with respect to their size and their placing. Frames can adjust themselves to the size needed by their content and they can also place themselves inside their container with respect to their sequence inside the container and/or to their neighbor frames. Most of this is determined by rules.
Container frames are holders of other frames and/or of containers and enable a nested modular grouping of frame objects to logical entities such as layout containers and pages. Container frames constitute the universe for all of their members. As a consequence all members are placed or place themselves inside the container with respect to the container's base point (and not with respect to the page as in DTP software).
Container frames enable an easy and modular placing and moving of layout modules on pages with all member objects. When creating, placing or moving containers all their members remain unchanged with respect to the container as their universe unless the dimensions of this universe have changed.
Page frames are the outermost container and a special form of container frames. Exactly one page frame is automatically placed on each page and acts as holder for all layout containers and all frames on a page.
Text frames are holders for data where 'data' typically is a datum from Elestore or via Elestore from a user database. This can also be an arbitrary text string similar to DTP frames without any link into the database. In Elepub this usage will be the rare exception because it is in almost all cases better to store such texts in the Elestore text database and to link the text frame to such an autonomous text object.
Image frames are holders for images and are used to visualize images inside containers or on a page.
Tables are a special kind of container frame providing services for creating, organizing and maintaining complex table structures. Tables are composed from table cells, which are ordered in rows and columns, and they can have header and footer frames. Tables can be spread over several pages
Table cells are the basic building blocks for tables. They are ordered in rows and columns. Table cells are holders for a text or image frame and are insofar a very special type of container with only one member.
Row and column cells
Each row and each column in a table is represented by one of these special table cells, which provide default values for all table cells in their rows and columns. Certain values of table cells are inherited from their respective row and/or column cell instead of their mother objects.
Elepub supports different types of lines:
- BorderLines visualize borders of frames and especially of table cells very similar to a spreadsheet table.
- FrameLines are placed inside or in between frames and/or table rows or table columns.
- AutonomousLines are independent objects, which can be placed anywhere inside a container or page.
Rules are applied to many publication object types and define how they are automatically created, sized and placed inside their containers or pages and the holder's relation to other member objects. Most rules are user selectable. Rules are typically applied to repository mother objects and they are among the most important attributes inherited from mother objects to their children containers and frames on real pages.
Publication views, browsers and tools
The page editor offers a visual representation of a page. It is primarily used for selecting and editing pages, which were generated automatically. It closely co-operates with the PageBrowser and in co-operation with the PageBrowser it can also be used to manually create individual pages from children of repository objects.
The page editor offers several different view modalities to better navigate, identify and select page objects. Among other features it can temporarily present specific or all frames on a page with a special border allowing for a better view of the frame structures or it can show the frame names and identifiers inside the frames. The Elepub page editor provides a comprehensive set of graphical tools for editing page objects.
The PublicationBrowser is the primary tool for opening publications, for navigating in publications, for selecting elements and for adding, removing or editing almost any type of publication component from chapters down to individual frames. The PublicationBrowser closely co-operates with the page editor and provides the forms for displaying and editing the values of selected publication objects (frames etc.). It reflects the hierarchical structure of a publication and offers means of very quickly navigating in and organizing even big and complex publications.
The joystick browser is a tool to visually and logically navigate very quickly within the three-dimensional object structures of pages. It acts similar to a joystick but is operated with the mouse or via keys. It can also be used to move or resize objects. In such tasks the joystick browser as a tool is much more precise and often also faster than the mouse. Also it is the best way to navigate inside a page's three-dimensional structures, which can hardly be achieve with a mouse.
The RepositoryBrowser is very similar to the PublicationBrowser but specialized in providing the editing facilities for creating and maintaining repository objects. It especially visualizes inheritance relations of objects and lets the user easily navigate in the inheritance tree.
The PageGenerator is the central automatic page creation tool. It automatically generates new pages from predefined repository objects using data object sequences as defined in Elestore (see Elestore for details). This is the basic procedure performed when generating new pages:
- the PageGenerator traverses an object sequence and performs for every elements the following steps
- the sequence item tells the PageGenerator which repository layout container is to be used for visualizing the data object (article, text, image) defined by the sequence item
- a child of this repository layout is created and the DataLink objects of all member frames are initialized with the data object identification (primary key) as defined by the sequence item
- if applicable a sub-sequence is processed and typically used to fill a table with related data objects
- all member frames of the newly created layout child now load their user data values from Elestore
- all member frames now format themselves and calculate their needed frame size
- the same is done by the entire container if it is was not defined of static size
- the PageGenerator places the filled and formatted layout container(s) on the new page(s)
- and proceeds with the next sequence item.
Most of the needed rules and knowledge about how pages are to be generated is in the used objects, particularly in the repository objects. Elepub publication objects have a high degree of independence and know most of the rules and behavior needed for creating children, populating them with user data, sizing and formatting them and placing them on pages. The generation process is completely object-oriented, i.e. the autonomy about how containers, frame objects and pages are created and formatted is inside the frame objects themselves and is not governed by an external generation logic. This approach is far superior to any procedural generation logic and a pre-condition for fully and easily re-using repository objects.
Publication import and export
Repository frame and container structures can be imported from an ASCII file. This allows for a creation of repository frame and container definitions even quicker than through the user interface but it requires a thorough understanding of the publication objects.
Accessing foreign databases
Elepub accesses user databases via Elestore. It is an essential feature of Elepub to only communicate with Elestore so that all details of accessing and organizing user data are completely hidden from Elepub. This is normally the most problematic part in database publishing. Such problems are avoided completely by the bi-directional integration of Elepub and Elestore as one homogenous system. See Elestore about the easy accessing of user databases.
Publication structures can be exported:
- to CDF, the Catalog Data Format, for distribution and use in Elecat, the e-paper product catalog software
- to XML structures containing the entire page structures with all formatting and content
- to the DTP software packages QuarkXpress, InDesign and Framemaker for color separation and print
- to HTML fully preserving the original page layout
- to PDF
- or publications can be directly output to a printer.
Elepub fully supports XML and is capable of exporting entire publications with all formatting and content to XML structures. Optionally even an import of entire QuarkXpress publication via XML is supported.
Running the Elestore software requires:
PC hardware: min. 1.300 MHz processor, 512
MB RAM, min. 500 MB free disk space
17" or 19" monitor with a resolution of 1.024 x 768 pixels
Operating system: Windows 95, 98, ME, 2000, XP or NT 3.x or 4.x