Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
METHOD FOR CREATING ELECTRONICALLY PORTABLE DOCUMENTS FOR E-BOOK-LIKE PAGE TURNING ON COMMON BROWSERS IN APPLICATION-OPTIMISED MANIFESTATION FOR ONLINE, OFFLINE, AND PRINT APPLICATIONS
Document Type and Number:
WIPO Patent Application WO/2014/180462
Kind Code:
A1
Abstract:
The method creates, from electronic documents of various formats, such as PDF, having a finished layout, a file, which can be viewed or read by means of popular common browsers (e.g., Internet Explorer, Firefox, Google Chrome) in such a way that the familiar page turning is modeled. The method provides documents that can achieve the perceived appearance and the simplicity of handling of high-quality print media. The field of application extends in particular to brochures, catalogues, or magazines that can be electronically transmitted quickly and completely personally by e-mail (as an attachment). Anonymous or non-anonymous distribution by means of downloading is also possible. By means of browsers, the documents can be ergonomically opened on a wide variety of popular device types having different operating systems and can be viewed with the ease of use inherent in said devices. Suitable devices are PCs, notebooks, and touch-screen devices such as tablets or smartphones. No special viewer is needed to use the documents. There is no obstacle of an additional installation.

Application Number:
DE2014/000230
Publication Date:
November 13, 2014
Filing Date:
May 06, 2014
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
MAG GLANCE GMBH (DE)
International Classes:
G06F17/22; G06F17/30; G06F40/00
Domestic Patent References:
WO2012066560A12012-05-24
Foreign References:
EP2090990A12009-08-19
US20040015954A12004-01-22
Other References:
ANONYMOUS: "Data URIs | CSS-Tricks", 25 March 2010 (2010-03-25), XP055139114, Retrieved from the Internet [retrieved on 20140909]
None
Download PDF:
Claims:
Patentansprüche

Verfahren zum Erstellen elektronisch portierbarer Dokumente zum E-Book ähnlichen Durchblättern auf marktüblichen Browsern in anwendungsoptimierter Ausprägung für Online-, Offline-, und Print-Anwendungen.

1. Verfahren auf einer Konfiguration, bestehend aus einem Server VServ und einem User Terminal UPC, derart dass VServ mit einer Datenbank DB ausgestattet ist, in der sich mindestens ein Layout fertiges HTML-Dokument WorkDoc befindet, derart dass es aus einem HTML-Header mit verfahrensgemäßen Bibliotheken besteht und einem HTML-Body mit einem Layout-Container der ein Plug-in PlugBooklet enthält, derart dass pro Seite ein Seiten-Container in die Struktur des PlugBooklet eingebettet ist, derart dass ein Seiten-Container Objekt-Container enthält mit den Multimedia-Objekten, derart dass außer den Texten die Objekte via URI mit Verweis auf die zum WorkDoc externen Ressourcen einbezogen sind, und der Objekt-Container zu seinem Objekt auf das er sich bezieht,

Formatierungs-, Stil- und Positionierungsangaben relativ zu den im Seiten- Container gegebenen Positionen, Begrenzungen und Layern enthält, derart dass das WorkDoc in einem blätterbaren Online-Modus betrachtbar und lesbar ist, und VServ einen lauffähigen Document-Transformer DocTF enthält, und dass das UPC mit einem Browser ausgestattet ist, der Markt übliches HTML verarbeitet, und die Konfiguration eine Verbindung enthält, derart dass sie zwischen UPC und VServ auf Initiative des Users verfahrensgemäß aufgebaut oder abgebaut wird, dadurch gekennzeichnet dass der DocTF auf Veranlassung des Users, der über das UPC und den darauf befindlichen Browser Kontroll-Einfluss auf den DocTF hat, ein Offline-Document OffDoc erstellt, derart dass das Off Doc nach seiner Erstellung auf das UPC runterladbar und lokal auf dem UPC als eine einzelne Datei speicherbar ist, derart dass das OffDoc nach dem Speichern auch ohne Verbindung zwischen UPC und VServ mit dem Browser zu öffnen ist und in durchblätterbarer Weise betrachtbar und lesbar ist, und/oder dass das OffDoc per Memory-Stick, oder per Datenträger, oder per Email-Anhang auch ohne HilfsContainer und ohne einen Zip-Container, als ein einfaches Dokument an andere Terminals übertragbar und speicherbar ist und dort mit dem HTML-fähigen marktüblichen Browser in gleicher Weise ohne weitere externe Verbindung und auch ohne Verbindung zum ursprünglich zur Erstellung des OffDoc verwendeten UPC und ohne Verbindung zu VServ nutzbar ist, dadurch dass DocTF zur Erstellung des OffDoc in einem Hintergrundprozess wie folgt verfährt:

a. DocTF greift auf das WorkDoc in der DB zu und lädt eine Kopie in einen

Hintergrundprozess, derart dass die so geladene Kopie des WorkDoc als Ausgangsprodukt für das neu zu erstellende OffDoc verwendet wird, und b. ein Suchprozess identifiziert alle Verweise auf externe Skript- und HTML- Dateien und ersetzt nach und nach die Anweisungen direkt durch die entsprechenden Inhalte derart, bis dass im neu entstehenden OffDoc keine Verweise mehr auf Skript- und HTML-Dateien außerhalb des neu

entstehenden OffDoc mehr erscheinen, und

c. ein weiteres Suchprogramm identifiziert innerhalb des inzwischen erreichten Standes des OffDoc alle multimedialen Objekte und codiert diese, mit

Ausnahme von Text, in der bevorzugten Ausprägung in Base64 derart, dass das codierte Ergebnis an die Stelle des vorherigen Verweises gesetzt wird und durch einen marktüblichen Browser darstellbar ist,

und nach Schritt c. das fertige OffDoc entweder in der DB gespeichert wird, derart dass es zum einmaligen oder mehrmaligen Download oder per Email einem oder mehreren UPC zur Verwendung zugeführt wird, oder ohne Speicherung direct dem UPC zur Verfügung gestellt wird.

2. Verfahren nach Anspruch 1 , dadurch gekennzeichnet, dass auf Veranlassung des Users über dessen Browser auf dem UPC aus dem WorkDoc in einem

Hintergrundprozess mit Hilfe des DocTF ein Dokument OnDoc durch

Transformation erstellt wird und in der DB gespeichert wird, derart dass das fertige OnDoc vom UPC mit Hilfe einer bestehenden Verbindung zwischen UPC und VServ als Online-Dokument mit dem UPC-Browser abrufbar ist und in einem Umblätter-Modus betrachtbar und lesbar ist, dadurch erzielt dass der DocTF auf Veranlassung des Users die Inhalte nicht direkt in das entstehende OnDoc eingefügt werden sondern als neue URI mit Verweis auf derart modifizierte neue Kopien der Inhalte ersetzt werden, dass diese neuen Inhalte im

Hintergrundprozess für die Darstellung auf einem Monitor in reduzierter oder hierfür optimierter Auflösung umgewandelt und in der DB abgelegt werden und die neuen URI darauf gerichtet werden, und derart dass bei Abruf des fertigen OnDoc auf Veranlassung des Users, zum Öffnen mit dem Browser des UPC, die HTML-Anweisungen aus denen das fertige und in der DB gespeicherte OnDoc besteht, in Realzeit über die Verbindung zwischen dem UPC und den VServ in Abschnitten oder in Gänze geschickt werden, derart dass die URI mit externen Verweisen, die vom Browser vorgefunden werden, über die Verbindung zum VServ aufgelöst werden, derart dass die Inhalte auf VServ adressiert werden und in Realzeit über die Verbindung zum Browser zur Präsentation geschickt werden.

3. Verfahren nach Anspruch 2, dadurch gekennzeichnet, dass auf Veranlassung des Users in einem Hintergrundprozess mit Hilfe eines PDF erstellenden Prozesses PDFGen, ein Dokument PDFDoc erstellt wird, derart dass aus einem Input- Dokument in einem der Formate OnDoc oder OffDoc oder WorkDoc durch PDFGen nacheinander die Links zu den Seiten-Containern des Input-Dokuments an ein Utility-Tool CutyCapt übergeben wird, derart dass das CutyCapt so ausgewählt ist, dass es aus den in den Seiten-Containern in HTML definierten Seiten Screenshots erstellt, derart dass CutyCapt von PDFGen in einem X- Window Prozess oder in einem virtuellen Desktop Prozess gestartet wird, derart dass CutyCapt durch einem automatisierten und parametrisierten Kommando- Zeilen-Aufruf des PDFGen aus jeder Seite einen virtuellen Screenshot, bevorzugt im Format JPEG erstellt, derart dass PDFGen den Screenshot übernimmt und diesen in ein PDF umwandelt, derart dass fortschreitend jede Seite in das

PDFDoc integriert wird.

4. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Schritt zur

Erstellung des PDFDoc am Ende des unter Anspruch 3 beschriebenen

Verfahrens nicht vollzogen wird, derart dass das Zwischen-Produkt bevorzugt aus JPEG-Screenshots der Seiten verwendet wird, derart dass sie die fertigen Seiten mit dem endgültigen Layout repräsentieren und als Ressourcen schonende Vorschau-Version eines Dokuments verwendet wird, derart dass das Vorschau- Dokument von marktüblichen Browsern wie ein OnDoc oder OffDoc

interpretierbar und betrachtbar ist und eine Beurteilung über die Fortsetzung des Prozesses ermöglicht der dann in einen material intensiveren Druckprozess mündet.

5. Verfahren nach Anspruch 4 dadurch gekennzeichnet, dass das PDFDoc speziell für die Übergabe an einen Drucker erstellt wird, derart dass ein hochwertiger Druck mit hoher Auflösung ermöglicht wird, dadurch erzielt, dass in dem Input- Dokument PrintDoc nacheinander alle Bilder in den Objekt-Containern durch diejenige ersetzt werden, die der erforderlichen Auflösung entsprechen oder durch solche ersetzt werden, die mit Hilfe eines Utility-Tools ImageMagick auf die spezifische Anforderung hin erstellt werden, derart dass jeweils eine Kopie von einem Bild bevorzugt in GIF- oder JPEG-Format mit der jeweils höchsten

Auflösung aus DB als OriginalObj entnommen wird und an ImageMagick zur Skalierung auf die geforderte Auflösung optimiert und/oder zur Farbraum- Transformation bevorzugt in CMYK-Format übergeben wird und anschließend das jeweilige Transformationsergebnis in den betreffenden Objekt-Container des PrintDoc eingesetzt wird oder in der DB gespeichert wird, derart dass in letzterem Fall der Link in dem betroffenen Objekt-Container auf das neugeschaffene Objekt in der DB gerichtet wird.

Description:
Beschreibung

Verfahren zum Erstellen elektronisch portierbarer Dokumente zum E-Book ähnlichen Durchblättern auf marktüblichen Browsern in anwendungsoptimierter Ausprägung für Online-, Offline-, und Print-Anwendungen.

Gegenwärtige Situation

Hochwertige Broschüren und Dokumente werden noch weitgehend als

Druckausgabe versandt. Der Bedarf an kleinsten und mittleren Auflagen von

Dokumenten in elektronischen Formaten wie (individuelle) Fotobücher und

Broschüren, (Vereins-) Zeitschriften ist weiterhin vorhanden oder gar im Wachsen. Die Basis hierzu sind die bereits überwiegend elektronisch erstellten und

vorliegenden Texte und Fotos - letzteres aus Digitalkameras und Smartphones.

Im Regelfall wird für die Erstellung von Print-Produkten eine Software angeboten, die aus dem Internet heruntergeladen und lokal (typischerweise auf dem PC) installiert werden muss. Nachteilig sind hierbei der Zeitaufwand und die Umstände bei

Download und Installation. Das Ergebnis ist dann speziell für das Print-Produkt und aufgrund des spezifischen Formats kaum geeignet für eine oft wünschenswerte gleichzeitige Verbreitung im Internet oder im lokalen Netzwerk.

Online-Anbieter nutzen oftmals Flash als Technologie zur Erstellung von Print- Produkten. Dies erweist sich einerseits als sicherheitskritisch und findet andererseits derzeit keine Unterstützung bei Smartphones und Tabletts.

Die Erstellung von Print-Produkten mit reinem HTML und Skriptsprachen oder Programmiersprachen wird aufgrund der unterschiedlichen Quellcode- Interpretationen durch die verschiedenen Browser-Typen und -Versionen gerade hinsichtlich komplexeren Funktionalitäten kaum verwendet oder nur für relativ einfache Funktionen genutzt. Neben dem wesentlich anspruchsvolleren Session- Management in Web-Applikationen im Vergleich zu FAT-Client-Anwendungen, ist die Erzeugung von komplexen Layout-Produkten hinsichtlich der Generierung von verschiedenen Output-Formaten und gleichzeitigem ergonomischen Betrachten eine

BESTÄTIGUNGSKOPIE weitere Herausforderung, besonders in Bezug auf qualitativ hochwertige Print- Formate. Print-Formate benötigen im Vergleich zu Online-Formaten (Monitor- Auflösung) eine wesentlich höhere Bildqualität und führen beim Online-Betrachten schnell zu inakzeptablen Download-Zeiten (Bandbreite).

Weiterhin ist die Kontrolle über das was der Adressat auf seinem Monitor sieht und als Druckexemplar erhält („What you see is what you get", WYSIWYG)

unzureichend gelöst. Anbieter von Print-Produkten präsentieren ihre Ergebnisse im RGB-Format und bieten keine Vorschau auf hochwertige Print-Produkte an, die im (voluminöseren) CMYK-Format an den hochwertigen Drucker geschickt wird - RGB ist nicht druckbar.

Sowohl Anbieter die ihre Software online oder offline zur Erzeugung von Print- Produkten zur Verfügung stellen, besitzen insbesondere im Offline-Modus und im E- Mail- Versand kein angemessenes, allgemeingültiges, portierbares Dokumenten- Format zur Verbreitung der erstellten Ergebnisse ohne die explizite Installation von nicht standardmäßig installierter Software.

Die gängigsten Methoden zur Verbreitung der erzeugten Ergebnisse ist die

Übermittlung von spezifischen Formaten, PDF-Downloads, Online-Präsentationen oder das Versenden der Print-Produkte.

Insbesondere in Bezug auf spezifische E-Book-Formate, wird typischerweise die Installation von weniger verbreiteten Viewern oder gar besonderen Geräten benötigt - im geschäftlichen und privaten Anwendungsbereich. Durch PDF-Dokumente werden die visuellen Funktionen wie z.B. das Durchblättern innerhalb von E-Books aufgelöst.

Der Versand ansprechender Beschreibungen erklärungsbedürftiger Produkte im Printformat erweist sich für kleine und mittlere Unternehmen im internationalen Geschäft als nachteilig hinsichtlich der Kosten und mit Bezug auf eine zeitnahe Belieferung. Dem Wunsch nach einem Dokument-Format das lokal im eigenen Netzwerk oder auf dem eigenen Rechner (des Kunden) behalten werden kann, kommen online Darstellungen ebenfalls nicht nach. Zwar erlauben gängige Browser das Offline-Speichern von Web-Seiten als Dateien in einer lokalen

Verzeichnisstruktur oder gar als gebündelte Datei (z.B. mht-Format vom Internet Explorer), allerdings treten dabei gerade in Bezug auf multimediale Inhalte wie Bilder, Videos und Sounds ohne Netzanbindung häufig Darstellungsfehler auf, die unter anderem auf nicht aufgelöste URI's z.B. ins Internet und eine beschränkte

Rekursionstiefe der Verweise auf externe Dateien innerhalb der HTML-Seite zurückzuführen sind. Ein weiterer Nachteil besteht bei dem Verfahren der Offline- Speicherung der Web-Seite als Verzeichnisbaum darin, dass das Übermitteln aufgrund der Anzahl der Dokumente und der einzuhaltende strukturelle Aufbau z.B. via E-Mail aufwendig und nur praktikabel ist, wenn es zuvor als Container-Datei (z.B. ZIP) umgewandelt wurde.

Verbesserung

Das hier beschriebene erfinderische Verfahren ist den Bereichen elektronische Medien; elektronische Dokumente und deren Formate, Transformationen und

Präsentationen zuzuordnen. Überblick

Das Verfahren ermöglicht das benutzerfreundliche Online-Erstellen, Modifizieren und Betrachten von Layouts, insbesondere für E-Book ähnliche Dokumente. In

unterschiedlichen Ausprägungen generiert und transformiert das Verfahren Online- und Offline- Formate für verschiedene Anwendungszwecke unter Verwendung einer einzigen (intermediären) Quelle in folgende Ergebnis-Dokumente:

• OffDoc (Offline-Document): einfach lokal speicherbares Offline-Format mit multimedialen Inhalten, das mit dem lokal vorhandenen Browser

benutzerfreundlich betrachtet und durchblättert wird zur Nutzung im lokalen

Netzwerk oder Speichermedien ohne Internetverbindung.

• OnDoc (Online-Document): ressourcenschonenden, performantes Online- Format mit multimedialen Inhalten für das ansprechende ergonomische Blättern und Betrachten, vorzugsweise für die Nutzung im Internet (Web- Präsentation).

• PrintDoc (Print Document): qualitativ hochwertiges Printformat zur Online- Druckvorschau mit dem lokal vorhandenen Browser oder zur

Druckaufbereitung für Druckmaschinen unter besonderer Berücksichtigung des WYSIWYG-Prinzips bei gleichzeitig performanter Ergonomie.

Das Verfahren erzeugt optional verschlüsselte Dokumente, die insbesondere für Business-Anwendungen elektronisch übertragen (z.B. Email, FTP, HTTP) und beim Empfänger via allseits verfügbarem Browser geöffnet werden können. Die

Dokumente, können ebenso in einem Online-Portal geöffnet werden oder von dort runtergeladen und zur weiteren Verwendung lokal gespeichert werden. Nach dem lokalen Speichern auf dem PC, Smartphone oder Tablett des Adressaten, sind die Dokumente jederzeit wieder via üblichem Browser zu öffnen - auch offline, ohne Netzverbindung. Aufgrund der Verwendung von HTML in jedem der weitverbreiteten Browsern wird technisch ein HTML Format für den Verfahrens-Output bevorzugt - ohne jedoch darauf beschränkt zu sein.

Das Layout kommt in Form eines elektronischen Buches, Magazins oder einer Broschüre zum entspannten Lesen oder Betrachten und angenähert an das gewohnte Gefühl des Blätterns und Umblätterns. Das Verfahren erweitert den Gestaltungsspielraum des Layouts derart, dass sich die Inhalte über eine

aufgeschlagene Doppelseite erstrecken lassen (links die gerade Seite und rechts die ungerade). Das Ergebnis ist absolut nahtlos und deshalb sogar besser als es im klassischen Vorbild der Printmedien in der Praxis erreicht wird. Diese Gestaltungs- Option wird bevorzugt für Bilder und Graphiken genutzt werden. Sowohl die Online- Formate als auch die Offline-Formate lassen sich in Realzeit zoomen. Auflösung und Detailreichtum der jeweiligen Dokument- Variante lassen sich verfahrensgemäß durch den Autor benutzerfreundlich kontrollieren.

Das User-Interface zum Lesen und Betrachten bietet den zur Verfügung stehenden Komfort des jeweils verwendeten Browsers und Gerätes (z.B. PC, Notebook, Tablett, Handy). Hierzu gehören, ohne Beschränkung, die folgenden Beispiele: • Mausklick auf linken/rechten Dokument-Seiten-Rand führt zum Rückblättern Vorwärtsblättern;

• Mausklick auf einen (z.B. mit einem Pfeil graphisch markierten) aktiven

(sensitiven) Bereich links und rechts vom Dokumentrand, führt zum

Rück/Vorwärtsblättern;

• die Pfeiltasten„links/rechts" blättern entsprechend;

• bei berührungsempfindlichen Screens sind die sensitiven Bereiche

entsprechend zu berühren;

• bei Gestensteuerung ist die entsprechende Geste für links/rechts

anzuwenden.

Lösungskomponenten Das hier vorgestellte erfinderische Verfahren besteht aus Prozess-Treibern (PT), die sich auf einem oder mehreren verfahrensgemäßen Servern (VServ) befinden. Das eigentliche Ziel des Verfahrens ist die Erstellung von verschiedenen Output- Formaten (Verfahrensergebnisse) nach dem gleichen Layout eines ursprünglichen Dokumentes.

Ohne Beschränkung auf diese Ausprägung veranschaulicht Fig.1 die grundlegenden Prozessschritte, die in den folgenden Abschnitten näher beschrieben werden.

In der weiteren Beschreibung wird davon ausgegangen, dass die Original Objekte wie Bilder, Texte, Videos, und Sounds bereits vom UPC zum VServ hochgeladen wurden und in die VServ Datenbank DB für das eigentliche Verfahren nutzbar gespeichert sind.

UPC

Das Terminal (UPC), das ein PC, Tablett, Smartphone oder ähnliches sein kann, greift mit einem marktüblichen Browser über ein Übertragungsprotokoll auf den Layouter (LO) zu. Layouter (LO)

Der LO ist ein usergesteuerter PT mit anwendungsspezifischer intuitiver

Benutzeroberfläche, der in Realzeit als Online-Dienst zum Zweck der Layout- Erstellung verwendet wird. Der Layout-Container, der das Gerüst des Layout darstellt (z.B. Objekte und deren Positionen enthält), setzt auf dem aktuellen Stand der Technik auf und verwendet bereits bestehende Java-Script Bibliotheken (wie z.B. JQuery) , die unter anderem Booklets darstellen können. Ohne Einschränkung der Verfahrensalternativen wird in der bevorzugten Ausprägung folgende Auswahl eingesetzt:

• Das JQuery-Plugin "Booklet" (hier PlugBooklet genannt) von

http://builtbywill.com/code/booklet/ (MIT License) stellt ein E-Book ähnliches Layout in blätterbarer Form zur Verfügung.

• Das JQuery-Plugin "Kinetic" (hier PlugZoom genannt) von

https://github.com/davetayls/jquery.kinetic (MIT License) realisiert das Rein- bzw. Rauszoomen in bzw. aus Dokumenten. Jquery und die beiden Plug-ins sind Open-Source-Objekte des MIT. Letzteres gewährt hierfür eine weitreichende und kostenfreie Nutzungs-Genehmigung unter Bedingungen die zum Zeitpunkt der Erstellung dieser Beschreibung unter folgendem Link zu finden sind: http://opensource.org/licenses/MIT Zum Zeitpunkt der Erstellung dieser Schrift lautete die Bedingung:

"Permission is hereby granted, free of Charge, to any person obtaining a copy of this Software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or seil copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above Copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE

AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM,

DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF

CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE."

Die Bibliotheken der Plugins werden auf neuartige Art und Weise verwendet und erweitert, indem der User benutzerfreundlich dynamisch und zur Laufzeit individuelle Layouts gestalten kann. Der Layout-Container PlugBooklet dient lediglich als Gerüst und wird durch die PT mittels Web-Sprachen (z.B. PHP, JAVA-Script, HTML, CSS, ohne darauf beschränkt zu sein) um folgende Funktionen, dem eigentlichen Inhalt, erweitert:

PlugBooklet wird mit Layout bezogenen Darstellungsanweisungen zu den Objekten wie formatierte Texte, Bildern, Videos und Sound-Objekten, und deren Attribute (z.B. Position, Ebenen, Beschnitt, Auflösung) bestückt. Hierbei übersetzt der LO die vom Benutzer getätigten anwendungsgemäßen Aktionen während des Layoutens in diese implementierungstechnische Bestückung, durch die PlugBooklet für das LO- Ergebnisdokument WorkDoc befähigt wird. Dieses anwendungsferne technische Detail wird durch die Bedienoberfläche des LO vom Benutzer ferngehalten.

Im Rahmen des LO werden dem User zur Layout-Gestaltung in Realzeit via UPC und Browser folgende anwendungsbezogenen Funktionen in intuitive erfassbarer Weise zur Verfügung gestellt

• Hinzufügen, modifizieren und entfernen von multimedialen Objekten wie

Bildern, formatierte Texte, Videos und Sound-Objekte.

• verschieben, vergrößern/verkleinern, drehen und beschneiden von

multimedialen Objekten

• Objekte in den Vordergrund oder Hintergrund platzieren. • Multimedia Objekte wie Sound oder Video werden mit Elementen zur

Ablaufsteuerung (z.B. Start, Stop, Pause, Vorwärts, Rückwärts) versehen.

Das User-Interface des jeweiligen UPC kann je nach Hardware-Ausstattung z.B. mit Maus, Berührung, Gestik bedient werden.

Weitere Optionen für die Ausstattung des LO sind z.B. Seiten-Templates,

Nutzungsberechtigungen via Verschlüsselung oder Passwort. WorkingDoc (WorkDoc) und Datenbank (DB)

Die Erstellung und (nachträgliche) Modifikation des WorkDoc erfolgt anhand von Auszeichnungs-, Skript- und Programmiersprachen sowie deklarativen Sprachen, insbesondere CSS, deren Anweisungen die Layout-Eigenschaften der jeweiligen referenzierten Datenbank-Objekte (DB) oder Server-Objekte innerhalb des individuell definierten Layoutbereichs bestimmen, ohne dabei die Original-Objekte (z.B.

einzelne Bilder) zu verändern.

Das WorkDoc besteht aus einem HTML-Header, in dem unter anderem die für das Verfahren benötigten Bibliotheken eingebunden werden, einen HTML-Body und einen darin enthaltenen Layout-Container, der eine oder mehrere Seiten-Container beinhaltet. Jeder Seiten-Container besteht aus einen oder mehreren Objekt- Container, in dem die multimedialen Inhalte (z.B. Bilder, Video, Text) enthalten sind, (siehe Fig. 2)

Der Objekt-Container beinhaltet ein einzelnes Objekt wie Bild, Text oder Video. Jeder Objekt-Container, bestehend aus einem Set von Anweisungen (bevorzugt HTML- Anweisungen) und dazugehörigen Objekteigenschaften (z.B. URI, Layout- Informationen), definiert ein Objekt innerhalb eines Seiten-Containers (einzelne Seite), die letztendlich im Layout-Container mit anderen Seiten-Containern (d.h. mit anderen Seiten) zusammengefasst wird.

Der Layout-Container wird entweder komplett oder derart in einer DB gespeichert, dass nur die Attribut-Werte (wie Layout-Informationen, Objektreferenzen - URI) des Layout-, Seiten- und Objekt-Containers ohne die dazugehörigen Anweisungen persistiert werden. Das folgende abstrakte Beispiel veranschaulicht das

grundlegende Prinzip der beiden Vorgehensweisen, ohne darauf festgelegt zu sein: 1 ) Vollständige Speicherung:

Der folgende Quellcode wird vollständig in der DB gespeichert.

<div id="Layout-Container_1">

<div id="Seiten-Container_1 " width="425px">

<div id="Objekt-Container_1 " width=" 150px">

<img id="1 " width="150px" src="http://www.obst.de/apfel.jpg" /> </div>

</div>

</div>

2.) Partielle Speicherung:

Bei der partiellen Speicherung werden zunächst anhand eines Suchalgorithmus die Werte (im Beispiel fett markiert) der jeweiligen Attribute identifiziert und in der DB derart gespeichert, dass die Werte (z.B. 150px) den Attributen (z.B. width) und der dazugehörigen Anweisung (z.B. img id) sowie der jeweiligen Seite im Layout- Container zugewiesen werden. Beim Wiedererstellen/Öffnen werden die

Anweisungen und deren Attribute wieder mit den dazugehörigen Werten aus der DB angereichert.

Zur Zuordnung ohne den Kontext des Quellcodes können die Werte in einer syntaktisch bestimmten Reihenfolge angeordnet werden, und für platzsparende optionale Platzhalter können z.B. Semikolon zur Trennung unterschiedlicher

Hierarchien verwendet werden und Kommas zwischen gleichen mehrfach

auftretenden Objekten. Damit würde z.B. obiger Layout_Container 1 wie folgt partiell gespeichert werden:

1 ;1 ,425px;1 ,150px,1 ,150px,"http://www.obst.de/apfel.jpg"

Die vollständige Speicherung ist relativ einfach umsetzbar, hat allerdings gegenüber der partiellen Speicherung den Nachteil, dass mehr Speicherkapazität benötigt wird. Der Quellcode wird in beiden Vorgehensweisen derart gespeichert, dass Fremdcode (z.B. Schadsoftware) zuvor herausgefiltert wird, indem nur Anweisungen und

Attribute die für die Erstellung des jeweiligen Dokuments benötigt werden, erlaubt werden,

Als dritte Alternative kann ein solcher Layout-Container auch als XML-Datei auf VServ gespeichert werden.

Die vorgenannten Beispiele der Ausprägung sind nicht ausschließlich.

Aufgrund der unterschiedlichen Quellcode-Interpretationen durch die verschiedenen Browser-Typen und -Versionen wird das WorkDoc derart gespeichert, dass in Realzeit je nach Browser-Typ und -Version der entsprechende Teil des Quellcodes in das online betrachtete WorkDoc eingesetzt und/oder ausgeführt wird, derart dass die beabsichtigte Darstellung des Layouts und der Inhalte erfolgt.

Als weitere Besonderheit stellt LO ein Verfahren bereit, das die durch den User hochgeladenen und bereits in der DB gespeicherten Objekte (OriginalObj) während des Layout-Prozesses anwendungsbezogen in der Qualität angemessen skaliert, und die diesbezüglichen objektbezogenen Anweisungen zusätzlich in der DB gespeichert werden, derart dass das OriginalObj unverändert bleibt (bevorzugte Vorgehensweise). Bei der Anwendung auf Bilder ergibt sich folgendes

• SmallObj: Umwandlung des OriginalObj in ein hinsichtlich der Auflösung

reduziertes Abbild

• PrintObj: Umwandlung des OriginalObj in ein typischerweise hochauflösendes CMYK-Objekt.

Hierbei liegt es in der Verantwortung des Users/Autors, dass die OriginalObj in einer Qualität vorliegen, die mindesten so hoch ist, wie die höchste

Anforderung. Bei Bildern ist das typischerweise ein für den Druck

vorgesehenes Objekt.

Die Umwandlung der OriginalObj wird in einem Hintergrundprozess serverseitig mit Hilfe von ImageMagick (http://www.imagemagick.org/script/index.php) realisiert, ohne die Verfahrensalternativen einzuschränken. Bemerkung: ImageMagick is free Software delivered as a ready-to-run binary distribution or as source code that you may freely use, copy, modify, and distribute in both open and proprietary applications. It is distributed under the Apache 2.0 license approved by OSI and recommended for use by the

OSSCC.

Bei Bildern wächst die Anforderung an die Auflösungsqualität mit der Vergrößerung des Bildes innerhalb des Layouts.

Oocument Transformer (DocTF)

Der Document transformer (DocTF) ist ein Transformer der auf VServ läuft und auf Veranlassung des Users (via Browser seines UPC) aus einem WorkDoc das jeweilige Output-Format (Verfahrensergebnis) in einem Hintergrundprozess generiert und UPC zur Verfügung stellt. Die Output-Dokumente sind ausführbare HTML- Dateien.

Offline Document (OffDoc)

Das OffDoc ist ein Output- Dokument des DocTF. Es ist lokal in einem UPC oder vergleichbaren Gerät speicherbar und für die Offline-Nutzung im Umblätter-Modus mit den typischerweise auf dem UPC oder einem vergleichbaren Gerät vorliegenden Browser zu verwenden. Das Öffnen von einem externen Speicher wie USB-Stick ist ebenfalls möglich. Das UPC oder ein vergleichbares Gerät benötigt keine

Verbindung zum VServ.

Die (HTML-) Struktur des OffDoc entspricht der des in Fig. 2 dargestellten WorkDoc, jedoch enthält die bevorzugte Ausprägung des Headers des OffDoc das PlugZoom. Das bewirkt, dass der User zum Zoomen unter anderem das Maus-Rad verwenden kann.

Verfahrensschritte zum OffDoc: 1 . ) Das WorkDoc wird auf Veranlassung des user-seitigen Browser von der VServ- Anwendung aus der DB mit einer Datenbanksprache in einem Hintergrundprozess im VServ geladen.

2. ) Ein Suchprogramm identifiziert innerhalb des WorkDoc alle Verweise auf externe Skript- und HTML-Dateien und ersetzt die Befehle durch die entsprechenden Inhalte.

Dieses Vorgehensweise wird rekursiv durch das gesamte WorkDoc angewendet.

3. ) Ein Suchprogramm identifiziert innerhalb des WorkDoc alle Verweise auf multimediale Inhalte wie Bilder, Videos und Sounds (bevorzugt OriginalObj) und codiert diese vorzugsweise in Base 64, ohne darauf beschränkt zu sein.

4.) Das so transformierte WorkDoc wird in VServ zwischengespeichert und kann über LO mit Hilfe des UPC-seitigen Browsers heruntergeladen und lokal auf dem UPC gespeichert oder per Email versendet werden. Das spätere Öffnen des dann lokal vorliegenden OffDoc benötigt keine Verbindung zu VServ und kann ohne sonstige (Internet-) Netzanbindung betrachtet werden.

Das Ergebnis OffDoc kann permanent in der DB des VServ gespeichert werden oder bei nur gelegentlicher Anfrage, kann der DB-Speicherplatz eingespart werden und das OffDoc jedesmal aufs Neue (weil performance-optimiert) erstellt werden.

Bevorzugt bleibt das WorkDoc in der DB erhalten, um daraus bei Bedarf eines der anderen Ergebnis-Dokumente zu generieren.

In einer alternativen Ausprägung wird die Codierung in Schritt 2 bereits im

vorangehenden Schritt 2 durchgeführt, d.h. sobald sich die multimedialen Inhalte in der verfahrensgemäßen Bearbeitung befinden. Online document (OnOoc)

Das Online-Dokument OnDoc ist für die Online-Nutzung auf VServ im Umblätter- Modus mit den typischerweise auf dem UPC vorliegenden Browser zu nutzen. Das UPC benötigt eine (Realzeit-) Verbindung zum VServ.

Verfahrensschritte zum OnDoc:

1.) Das WorkDoc wird auf Veranlassung des Users aus der DB mit einer

Datenbanksprache in einem Hintergrundprozess im VServ geladen. 2. ) Ein Suchprogramm identifiziert innerhalb des WorkDoc alle Verweise auf multimediale Inhalte wie Bilder, Videos und Sounds und ersetzt diese durch

Verweise, die auf ein reduziertes Abbild in der Auflösung eines jeden Objektes referenzieren (SmallObj), um das Online-Arbeiten während der Layout-Session auch bei der typischerweise begrenzten Bandbreite der Verbindung zwischen VServ und UPC flüssiger zu erledigen.

3. ) Das transformierte WorkDoc wird nach oder während der Bearbeitung auf VServ gespeichert und kann über UPC performant als Ganzes oder auch seitenweise in den Browser- Bereich des UPC geladen werden. Bevorzugt bleibt das WorkDoc in der DB erhalten, um daraus bei Bedarf eines der anderen Ergebnis-Dokumente zu generieren.

Print document (PrintDoc)

Das Print-Document (PrintDoc) wird auf VServ erstellt und ist für die Online-Nutzung im Umblätter-Modus mit dem typischerweise auf dem UPC vorliegenden Browser zu nutzen, dient aber vorwiegend als Basis zur Generierung von qualitativ hochwertigen Druckformaten wie PDF. Das UPC benötigt eine (Realzeit-) Verbindung zum VServ. Videos und Sounds können zwar grundsätzlich dargestellt werden, sind jedoch für den Dmckprozess nicht vorgesehen und werden daher nicht in das PrintDoc, das als Vorstufe zum Printprodukt (Hard-Copy) vorgesehen ist, integriert.

Verfahrensschritte zum PrintDoc:

1 . ) Das WorkDoc wird auf Veranlassung des Users aus der DB mit einer

Datenbanksprache in einem Hintergrundprozess im VServ geladen.

2. ) Ein Suchprogramm identifiziert innerhalb des WorkDoc alle Verweise auf Bilder und ersetzt diese durch Verweise, die auf die OriginalObj die den

Qualitätsansprüchen hochaufgelöster CMYK-Bilder (PrintObj) entsprechen sollen (Verantwortung des Users/Autors), um dem User mit UPC eine Vorschau des drucknahen Ergebnises zu bieten - "WYSIWYG".

3. ) Das transformierte WorkDoc wird nach oder während der Bearbeitung auf der VServ-DB gespeichert und kann ausschnittsweise oder seitenweise ohne übermäßige Belastung der Übertragungsmedien oder der erwarteten ergonomischen Download-Zeit zum UPC-Browser geladen werden.

Die Besonderheit aller Online und Offline-Formate ist, dass kein spezieller Viewer und keine spezielle Hardware als UPC benötigt wird - Consumer-Standard genügt. Um eine performante Nutzung zu gewährleisten, werden bei großen OnDoc und bei dem PrintDoc die Inhalte beim Betrachten seitenweise geladen.

OutputFormatter (OutFormatter)

Bei allen oben genannten Output-Formaten kann die Ausgabegröße des

Zieldokuments variabel bestimmt werden, d.h. dass sowohl das Layout-Gerüst als auch alle darin enthaltenen Objekte proportional skaliert werden können. Dies ist insbesondere bei der Erzeugung von qualitativ hochwertigen Printdokumenten in Kombination mit PrintDoc und zur Optimierung der Anzeige auf unterschiedlichen Monitorgeräte anwendbar. Das hier beschriebene Verfahren ist nicht zwingend notwendig, sondern als optionale Erweiterung gedacht und kann wahlweise nach dem Laden des WorkDoc eingebaut werden.

PDF Generator (PDFGen)

Der PDFGen erstellt basierend auf dem PrintDoc, in Kombination mit dem

OutFormatter, PDF-Dokumente (PDFDoc) in beliebig skalierten Formaten, die vorrangig für den professionellen Druck oder die Druckvorschau bestimmt sind. Hinweisend gilt, dass Druckerzeugnisse wie Broschüren, Büchern oder Zeitschriften eine durch 4 teilbare Gesamseitenzahl benötigen.

Verfahrenschritte für PDFGen

1. ) PageChecker überprüft ob die Gesamtseitenzahl des PrintDoc durch 4 teilbar ist. In der Annahme, dass dies der Fall ist folgt Schritt 2

2. ) Bevorzugt wird das mit der optionalen Erweiterung OutFormatter transformierte PrintDoc in einem Hintergrundprozess in einem X-Window (oder in einem virtuellen Desktop) geladen. Mit einem an CutyCapt übergebenen Link, der auf einen einzelnen Seiten-Container des PrintDoc verweist, wird serverseitig ein (virtueller) Screenshot in druckoptimierter Qualität, vorzugsweise in jpeg, erstellt.

3. ) Das unter Verfahrensschritt 2 erstellte Bild wird serverseitig in ein PDF integriert.

4. ) Die Verfahrensschritte 2-3 werden in einer Schleife so lange durchlaufen, bis alle Seiten in das PDF integriert sind.

Verfahrensschritte 2-3 setzen auf dem aktuellen Stand der Technik auf und nutzen bevorzugt die Funktionen von CutyCapt (http://cutycapt.sourceforge.net/), ohne dabei die Verfahrensalternativen einzuschränken, derart dass die Reihenfolge der

Druckbögen bindegerecht erfolgen kann.