View Issue Details

IDProjectCategoryView StatusLast Update
0003100ScribusIntegrationpublic2012-02-22 21:12
Reporterchris_t Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status acknowledgedResolutionopen 
PlatformLinuxOSOS Version
Product Version1.3.2 
Target VersionFixed in Version 
Summary0003100: Enhancements to integrate Scribus as an Engine for Content Management Systems
DescriptionIn Production-Workflows (Newspapers etc.) with many Editors it would be great to use a CMS (Workflow-Management, Rights-Management etc.). In addition all the Content could be published easily on the Web (or is already there).

If we use a full automated Print-Production-System we have no intervention in this Process and normally ugly results (e.g. htmldoc).

So:
- with a CMS for Production of Contents (generating .sla-Files via XSLT)
- and a DTP for automated Preflighting (on the Server) and collecting the Data for downloading and reworking
we would have a strong Collection of Tools. Workflow could be described in the following way (">" = needed Features):

1. the Designer sets up a Page-layout within Scribus (all HTML-Style-Elements (placed by the Editor within a WYSIWYG-Editor) are assigned to Scribus-styles)
> Possibility to encapsulate the Dummy-Content within special Markers (like Comments before and after the Content-Element).

2. the Chief-Editor starts the Preflighting, Collection for Export etc.
> possibility to trigger Scribus via PHP/Perl/... (also doing the first corrections).

3. (more or less) small Reworks are done within the downloaded Version.

Additional InformationAlso see http://wiki.scribus.net/index.php/Draft_of_end-to-end_publishing_solution


I am working with Typo3 (Open-Source-CMS) and thinking about integrating this as an Extension. An automated System is described under
http://www.yeebase.com/verlag/technologie/ (german).

(more or less) related Entries:
http://bugs.scribus.net/view.php?id=1675
http://bugs.scribus.net/view.php?id=238
http://bugs.scribus.net/view.php?id=1146
http://bugs.scribus.net/view.php?id=2108
http://bugs.scribus.net/view.php?id=1791
http://bugs.scribus.net/view.php?id=1394
http://bugs.scribus.net/view.php?id=1096
http://bugs.scribus.net/view.php?id=1271
http://bugs.scribus.net/view.php?id=1770
TagsNo tags attached.
Patch

Activities

chris_t

2006-01-25 18:18

reporter   ~0008349

Ok once again with the links :)

Access to the Scribus core from python outside of Scribus(planned for 1.3.4)
http://bugs.scribus.net/view.php?id=1675

New CL option: scribus --to-pdf
http://bugs.scribus.net/view.php?id=238

Multi-user projects/Multi-user Scribus
http://bugs.scribus.net/view.php?id=1146

0002108: External copy editor tool
http://bugs.scribus.net/view.php?id=2108

0001791: Linking to external text
http://bugs.scribus.net/view.php?id=1791

0001394: XML based editing
http://bugs.scribus.net/view.php?id=1394

0001096: Picture frame padding
http://bugs.scribus.net/view.php?id=1096

0001271: support RGB output with CMS (PDFs, inkjet printers, ps, probably more)
http://bugs.scribus.net/view.php?id=1271

0001770: Design a pre-flight report for printing with the the new file tester
http://bugs.scribus.net/view.php?id=1770

plinnell

2006-01-29 20:59

viewer   ~0008465

apologies about the weblinks mantis seems to mess them up

chris_t

2006-01-31 18:46

reporter   ~0008520

on
http://docs.scribus.net/index.php?lang=en&page=readme-13
is a hint...
"Our plans for a new file format should be settled in the 1.3.3 -1.3.4 development period."
does anybody know something about the status of the new file format??
chris

faramond

2007-02-04 23:29

reporter   ~0015091

Last edited: 2007-02-04 23:36

Dummy markers may not be the best approach. They involve editing the master document (i.e., the document with the layout), are not live, and are not very manageable.

A better solution might be a relationship structure like that in Open XML. There, the main document in a package contains numbered links to content, whether text, images, or other (stored as separate files within the package or in external files.) These links are resolved via a relationship file also included within the package. This:
1. separates content from layout (and is not irreversible, unlike with dummy markers: because the content is never actually merged into the code of the master document, you can edit both independently)
2. lets you change multiple links fast (all you have to do is update the relationship file with the new locations)
3. and saves consuming applications from scanning all documents within a package for external links (all that data is stored in one place)

The downside is that Scribus would have to be more intelligent, following these links and rendering the content they reference on the fly (i.e., more like AJAX than SSI.)

avox

2007-02-05 00:47

administrator   ~0015094

We plan to have external stories, just like the images are external now.

What would be the advantage of using relations? IIUC that's just a table mapping
IDs to filenames, isnt it?

faramond

2007-02-05 16:34

reporter   ~0015109

You're right--it is a mapping/dependencies table. The advantage is that the filenames are stored in one place. So:

- Scribus (or a CMS) can access all linked content at open without needing to parse the document. This can increase speed (the app can open the linked data without having to wait for parsing to complete, possibly in separate threads; it also means that all read requests can be issued at once, which means grouped disk reads/less time-intensive disk seeks.)
- With such a table, Scribus (and CMS or print system tools) could also efficiently verify links before rendering or printing, e.g., a message to the effect of "Linked content xxxx could not be found. Please enter correct path or ignore (linked content will not display.)"
- End users or automated systems (such as CMS) can check/insert/change content without actually having to touch the main document in the package. Not touching the main document means less risk of messing up layout (either by hand or with poorly-coded scripts.) A relationship file (which has a simple schema) also obviates the need for a full-blown XML parser when check/inserting/changing content.
- Having a mapping table also facilitates document portability (e.g., when, due to moving files or changing directory structures, links break. Fixing broken links would simply be a matter of opening the mapping table.)
- Scribus or CMS can also add important, file-specific data to a such a table, e.g., the type of content referenced; for custom content, if a plugin is necessary; for dynamic content, whether the file should be updated on every load (or only if file modify date is greater than a certain value), etc.
- Finally, users could enter arbitrary relation IDs/references in a document that is not yet completed. Paths could be specified later when necessary by editing the relationship table. This would be simpler than inserting custom tags/markers into the XML and later replacing those with the desired content.

Hope that helps!

avox

2007-02-05 17:22

administrator   ~0015110

faramond> The advantage is that the filenames are stored in one place.

The disadvantage is that fileinformation is stored in two places...

faramond> So:

faramond> - Scribus (or a CMS) can access all linked content at open without needing to parse the document. This can increase speed (the app can open the linked data without having to wait for parsing to complete, possibly in separate threads; it also means that all read requests can be issued at once, which means grouped disk reads/less time-intensive disk seeks.)

I'm unconvinced if that's needed. Parsing XML is quite fast, it's creation of document structures which takes much time. Furthermore, trying to open all linked files at once will probably choke the computer to a halt.

faramond> - With such a table, Scribus (and CMS or print system tools) could also efficiently verify links before rendering or printing, e.g., a message to the effect of "Linked content xxxx could not be found. Please enter correct path or ignore (linked content will not display.)"

Scribus does that already (preflighter). The next fileformat will probably place needed resources (external files, stories, fonts, ICC profiles, colors) at the start of the document in order to make this task easier.

faramond> - End users or automated systems (such as CMS) can check/insert/change content without actually having to touch the main document in the package. Not touching the main document means less risk of messing up layout (either by hand or with poorly-coded scripts.) A relationship file (which has a simple schema) also obviates the need for a full-blown XML parser when check/inserting/changing content.

Parsing XML is not that hard, and the next fileformat will be even easier to read for humans (hopefully). Also, just looking at the list of external files provides a very limited view on the document - I'm not sure is it's of that much use for a CMS.

faramond> - Having a mapping table also facilitates document portability (e.g., when, due to moving files or changing directory structures, links break. Fixing broken links would simply be a matter of opening the mapping table.)

Scribus already has a dialog for that (Extras->Manage Pictures). Outside of scribus it would be a simple transformation of the *.sla file.

faramond> - Scribus or CMS can also add important, file-specific data to a such a table, e.g., the type of content referenced; for custom content, if a plugin is necessary; for dynamic content, whether the file should be updated on every load (or only if file modify date is greater than a certain value), etc.

IMO Scribus should store its data in the *.sla file and a CMS should store its information in its own structures or parse the Scribus file. A single XML file is much easier to handle than a group of files with links to each others internals.

faramond> - Finally, users could enter arbitrary relation IDs/references in a document that is not yet completed. Paths could be specified later when necessary by editing the relationship table. This would be simpler than inserting custom tags/markers into the XML and later replacing those with the desired content.

What's wrong with linking to some dummy content and later replace that dummy file within the filesystem?

Anyway, IMO the Microsoft design is bloated and complicated. It's also much harder to understand than a single XML file. We just dont have the spare manpower to develop such a complicated scheme without seeing benefits.

axelb

2007-02-07 23:47

reporter   ~0015134

Last edited: 2007-02-07 23:50

If you need xml, you better go for ODF than for the (not so open after all) office open XML. ODF is an ISO standard, and already implemented or used by over 50 different programs or plugins:
http://opendocumentfellowship.org/applications

JLuc

2011-08-24 14:30

developer   ~0026778

Has Scribus's the state of the art evolved on this subject ?

ale

2011-08-25 07:42

manager   ~0026788

the new scripter engine (cf. henning's and jain's work on gsoc) and the patches we got for using scribus from the command line should help here...

i was planning to work on this topic this fall, but had to change my focus.
i plan to work on it in the new year (2012, for the records...)

Issue History

Date Modified Username Field Change
2006-01-25 18:13 chris_t New Issue
2006-01-25 18:18 chris_t Note Added: 0008349
2006-01-29 20:59 plinnell Note Added: 0008465
2006-01-29 20:59 plinnell Status new => acknowledged
2006-01-31 18:46 chris_t Note Added: 0008520
2007-02-01 16:01 avox Additional Information Updated
2007-02-04 23:29 faramond Note Added: 0015091
2007-02-04 23:36 faramond Note Edited: 0015091
2007-02-05 00:47 avox Note Added: 0015094
2007-02-05 16:34 faramond Note Added: 0015109
2007-02-05 17:22 avox Note Added: 0015110
2007-02-07 23:47 axelb Note Added: 0015134
2007-02-07 23:50 axelb Note Edited: 0015134
2011-08-24 14:30 JLuc Note Added: 0026778
2011-08-25 07:42 ale Note Added: 0026788