View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0010651 | Scribus | Import / Export | public | 2012-03-31 08:00 | 2020-02-21 23:47 |
| Reporter | JLuc | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | new | Resolution | open | ||
| Summary | 0010651: Link text frame to SLA file | ||||
| Description | - Enable to import the content of a text frame from a SLA file (or maybe a dedicated SLAFRAGMENT file ?) - Enable to remember its source in the text frames properties (in the same way an image frame know which image file it is linked to). That could be an option in the Import dialog : "remanent source", or "bidirectionnal link to source". - Enable to refresh (automaticaly or at request) the content of such a bidirectionnal sourcelinked text frame : when the content of the SLA has changed, the text frame is updated. - Enable to save the text frame's content to a linked SLA sourcefile, both on a single frame basis (using an option in the context menu) or for all such text frames in the global document (using an option in file main menu) - Allow to specify in the settings : a dedicated default folder for such SLA fragments. - Optionnaly provide a new "linked SLA file textframes" manager (in the ImageManager way, or in the "Album" way) refresh both content of frame (if file has changed) and file, both for a single frame or for all text frames in the document. | ||||
| Additional Information | - the SLA fragments folder can be shared with other users | ||||
| Tags | No tags attached. | ||||
| Patch | |||||
|
|
============ - Proposition : lets call these text frames 'sourced text frames'. ============ - When to sync and how to secure workflow and prevent access conflict ? An additionnal option on each sourced textframe would be to specify whether the refresh of this frame is - continuously (same as for images frame) - on open or import SLA only - on export SLA only - on both An additionnal button should enable to force the sync of the frame Example : Lets imagine a newsletter.sla file using 2 sourced text frames : edito.sla and news.sla. Jean is responsible for edito and Luc for news so Jean would set edito as export and news as import, and Luc would set edito as import and news as export. No conflicts would possibly happen. Dedicated buttons or menu options would enable to refresh the viewport and main SLA file, aswell as the shared fragments. ============ Question : should the SLA fragments just be linked in the main SLA file, or would their content be copied inside the main SLA file ? It seems the the fragments should be linked, and should be dealt in the same way as images during the " file > collect elements for output" menu action) |
|
|
2 related propositions - 0001791 : "Linking to external text" - 0002107: about "Master documents" |
|
|
this request is intended toward enabling basic cooperation using some cloud storage for the file bits. |
|
|
... before implementing this, we should have scribus to accept relative paths for resources... but it's an interesting request! |
|
|
Note : AMOF this "enable import" versus "enable export" can be thought as some new type of "lock" option, along with the 2 current options : "Lock content" and "lock position and size", and this proposition can be thought as about adding 2 new sort of other "lock" abilities : - "Follow source" = Lock content but update display when source is changed. - "Lock source" = enable local edit but prevent other users to edit this source. As a consequence of these, the user has to be identified in some way, and when he "Lock source", he becomes "owner" of the (re)source and his ident is stored in the sourcefile. In such a case, other users cant edit this source AND cant lock it. Rights management should not become too complex but it should enable cooperation amongst users on a same SLA. |
|
|
This might be the best place to forward this comment from google+ since its author requests dynamic links to ODT files. [quote lang='fr' author='Heric Samson https://plus.google.com/u/0/115862000956298628415'] Des liens dynamiques sur des fichiers odt locaux serait déjà un gros plus. Pour donner un ordre d'idée, le n°4 a donné lieu à 18 "build" du PDF que je mettais à disposition des contributeurs lorsque les changements étaient significatifs. Cela ne veut pas dire que tous les articles ont été importés 18 fois mais quand même, j'ai souvent du écraser le contenu des cadres et refaire l'identification des styles (titres et chapôs). Pour être fiable, le mécanisme d'importation doit être plus simple et donc prévisible : se contenter d'identifier les styles déjà définis dans la maquette Scribus. Eventuellement, proposer des substitutions pour les style utilisés dans le fichier odt et inconnus dans Scribus. La mise en forme des styles odt ne doit pas être importée. En revanche, les italiques, les gras et les soulignés peuvent faire l'objet d'une option d'importation. De mon point de vue, l'auteur doit être libre d'utiliser la mise en forme qu'il veut pourvu qu'on puisse déterminer la nature du texte et donc la mise en forme à appliquer dans la maquette Scribus. Le style est parfait pour identifier la nature du texte, c'est une info sémantique ... je regrette que les utilisateurs de base rédigent 100% de leurs documents en style "normal" :(? [/quote] [EDIT] Héric Samson parle t il d'un magazine Urbania ? https://urbania.ca/auteur/esamson |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2012-03-31 08:00 | JLuc | New Issue | |
| 2012-03-31 08:35 | JLuc | Note Added: 0027884 | |
| 2012-10-14 19:37 | JLuc | Note Added: 0029048 | |
| 2012-10-16 08:38 | ale | Relationship added | related to 0001791 |
| 2013-05-23 12:03 | JLuc | Note Added: 0030167 | |
| 2013-05-23 12:03 | JLuc | Note Edited: 0030167 | |
| 2014-03-23 10:28 | JLuc | Note Edited: 0029048 | |
| 2014-05-15 22:19 | JLuc | Note Edited: 0029048 | |
| 2014-05-20 17:59 | ale | Note Added: 0031889 | |
| 2014-05-22 16:05 | JLuc | Note Added: 0031913 | |
| 2014-08-01 09:55 | JLuc | Note Added: 0033125 | |
| 2014-08-01 09:55 | JLuc | Note Edited: 0033125 | |
| 2016-05-06 19:42 | JLuc | Relationship added | related to 0001925 |
| 2018-03-23 08:52 | JLuc | Note Edited: 0027884 | |
| 2018-03-23 08:54 | JLuc | Note Edited: 0027884 | |
| 2020-02-21 21:36 | JLuc | Note Edited: 0033125 | |
| 2020-02-21 23:47 | JLuc | Note Edited: 0033125 |
