View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003100 | Scribus | Integration | public | 2006-01-25 18:13 | 2012-02-22 21:12 |
| Reporter | chris_t | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | acknowledged | Resolution | open | ||
| Platform | Linux | ||||
| Product Version | 1.3.2 | ||||
| Summary | 0003100: Enhancements to integrate Scribus as an Engine for Content Management Systems | ||||
| Description | In 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 Information | Also 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 | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
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 |
|
|
apologies about the weblinks mantis seems to mess them up |
|
|
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 |
|
|
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.) |
|
|
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? |
|
|
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! |
|
|
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. |
|
|
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 |
|
|
Has Scribus's the state of the art evolved on this subject ? |
|
|
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...) |
| 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 |
|
Note Added: 0008465 | |
| 2006-01-29 20:59 |
|
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 |
