Le 20/05/2018 ? 19:02, ale rimoldi a ?crit?:
> i think it's time to start creating a set of documents with exact
> instructions for testing the importing of .html, odt, sla (styles) +
> copy pasting and:
>
> - document how it currently works.
> - specify how it should work.
>
> i think that you're one of the ones that has most experience with it...
> could you summarize you're knowledge in a post?
I edited the title of this sub-thread.
AMOF, I import images or PDF in scribus, and IDML sometimes,
but i do never import html or odt
As far as i remember, it leads to hard to improve messy documents.
I tested the sla style import quite thoroughfully 6 years ago,
trying to understand what it did so i could circumvene it
but I found it was not safe to use this feature in the general usecases.
As far as i remember the issues rise when identicaly named styles
occur in the origin and destination document.
It seems that scribus has some dedicated behaviour for this
(in some cases it renames the imported style) but it does not allways do so,
and even when it would do, this behaviour doesnt fit all needs :
sometimes, the imported style should overwrite the existing style,
sometimes it should just be ignored and not imported,
sometimes idealy the resulting attributes should be cherrypicked.
Amof, it looks like a version control merge.
Here are the relevant reports I could find today :
- Style managing when importing pages
https://bugs.scribus.net/view.php?id=11111
- Managing styles when pasting an object coming from another document
https://bugs.scribus.net/view.php?id=11814
- 1.5 style management during page import
https://bugs.scribus.net/view.php?id=11420
Because of these blocking issues, I have stoped try to import parts of SLAs
or to merge SLAs.
Here is a workaround and limited positive experience i found out :
When i have some part of SLA document that i want to rely on to use in several
SLA documents created along several month
or years, i have found out that even when the desinations document are not
supposed to have style changes, they will
have some style changes. As a consequence, the pasted parts (with old style
definition) will conflict and mess the
layout. To avoid that, i use a text editor to thoroughfully remove ALL style
definition in the SLA i want to paste, and
change them into inline attributes. That cleaned 0-style document is then kept
in a safe place where i cannot edit it
and mistakenly reintroduce styles.
(related : https://bugs.scribus.net/view.php?id=14166)
Maybe not an answer but related :
Because of the lack of style conflict management, i found it allmost impossible
to create long heterogeneous documents.
I have to use lots of little documents and concatenate the PDF instead of
merging the SLAs.
I have created a set of shell scripts that help me do the job : i define a
project made of a set of SLA documents and of
options like pages size, margins, default fonts and globaly any attribute in
the SLA's XML.
The scripts performs several actions like checking or setting these options,
computing page numbers for each chapter,
etc and ensures some fundamental quality checks that scribus prepress check
doesnt enforce (like checking that the PDF
of a chapter is uptodate compared to the SLA). It also creates PDFs and merges
them to produce the final PDF. And more
probably.
You got an idea of the code and doc here :
https://github.com/JLuc/scribus-project-manager (i should update it a bit).
This set of script could also be used as a prototype for features of a proper
C++ scribus project management C++ tool.
JL
