View Issue Details

IDProjectCategoryView StatusLast Update
0010651ScribusImport / Exportpublic2020-02-21 23:47
ReporterJLuc Assigned To 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status newResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0010651: 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
TagsNo tags attached.
Patch

Relationships

related to 0001791 acknowledged Linking to external text 
related to 0001925 acknowledged Multiple users sharing one open document 

Activities

JLuc

2012-03-31 08:35

developer   ~0027884

Last edited: 2018-03-23 08:54

View 3 revisions

============

- 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)

JLuc

2012-10-14 19:37

developer   ~0029048

Last edited: 2014-05-15 22:19

View 3 revisions

2 related propositions

- 0001791 : "Linking to external text"
- 0002107: about "Master documents"

JLuc

2013-05-23 12:03

developer   ~0030167

Last edited: 2013-05-23 12:03

View 2 revisions

this request is intended toward enabling basic cooperation
using some cloud storage for the file bits.

ale

2014-05-20 17:59

manager   ~0031889

... before implementing this, we should have scribus to accept relative paths for resources...
but it's an interesting request!

JLuc

2014-05-22 16:05

developer   ~0031913

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.

JLuc

2014-08-01 09:55

developer   ~0033125

Last edited: 2020-02-21 23:47

View 4 revisions

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

Issue History

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 View Revisions
2014-03-23 10:28 JLuc Note Edited: 0029048 View Revisions
2014-05-15 22:19 JLuc Note Edited: 0029048 View Revisions
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 View Revisions
2016-05-06 19:42 JLuc Relationship added related to 0001925
2018-03-23 08:52 JLuc Note Edited: 0027884 View Revisions
2018-03-23 08:54 JLuc Note Edited: 0027884 View Revisions
2020-02-21 21:36 JLuc Note Edited: 0033125 View Revisions
2020-02-21 23:47 JLuc Note Edited: 0033125 View Revisions