|
|
|
|
|
originating.png (202,730 bytes) |
|
|
once imported.png (185,960 bytes) |
|
|
2nd paragraph should read - A paragraph with pure "default par style" being defined as CYAN ARIAL UPPERCASE. When imported it keeps being "default par style" but the definition is not imported and so the look is NOT correct. |
|
|
At the end of a magazine creation session, requiring quite a few page-import actions (and maybe a couple of style-import actions too), the SLA is crippled with lots of "Copy of Suchstyle" and "Copy of Copy of Suchstyle". There even is a "Copie de Suchstyle (2)" which is its french counterpart. The "(2)" there is quite mysterious since there is no "Copie de Suchstyle" at all without the (2). After researching in the SLA it appears that these "Copy of" styles are not used at all. So AFAIAC it's possible to delete them and it's quite easy to do so in editing the SLA with a text editor. Better would be not to create them, and even better would be to handle styles correctly during page or style imports. |
|
|
Right now another experience : I import various document using the same styles at the end of a document : the styles are not duplicated in the resulting merged document and everything looks allmost fine. (But then, since no new style is created, a layout problem would have occured, in case the styles had had the same name but a different definition ???) However, there seem to be a problem with interline space : when it has been changed localy, that change is not reported in the imported pages (the style default value used). Importing another document's pages rises another issue : some characters become "bad glyph" squares... |
|
|
A first management of this issue would be to plainly check, at the begining, whether there is a style conflict (= a style with the same name but with different properties in each of the SLA files). In case of such a conflict, scribus would display a detailed warning "There is a conflict with the style NAMEOFSTYLE" and basicaly enable to choose "Abort" or "Proceed". Smarter action options could later be "Abort", "Overwrite existing style", "Keep existing style", "Rename imported style". Smarter warning message would display the style differences : "Space after paragraph : 2pt (existing) / 0pt (imported) ; color : blue (existing) / darkblue (imported) ..." |
|
|
Think we should confirm this bug and set it for 1.5.1 |
|
|
Also reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778 |
|
|
The same issue exists when - copy an object in a document and paste it in another document - place an object in the scrapbook and paste it in another document |
|
|
I committed several improvements related to this issue in r24307. Things should now work better when importing the sample document attached in first note. At this point, I however cannot fix all issues related to text styles import as an issue related to the 1.5.0 and former file formats comes in the way : paragraph styles were until r24307 saved before character styles. This basically prevent us at this point to perform some necessary consistency checks when importing for eg. a paragraph style which depends on a specific character style. We may have to wait 1.7.x to completely fix import of text styles. |
|
|
Wouaouh jghali great to learn you're on that issue. As for the technical side of the issue, i dont understand how the file format interferes once the document is loaded... but you know. |
- Anonymous
