View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16058 [Scribus] User Interface minor N/A 2020-02-22 17:22 2020-02-22 17:23
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Adjust position of first page when inserting new page
Description: When inserting a page or a set of new pages before the first page of a 2-sides facing-pages document,
Scribus could help the user adjust the document :

- ask whether it should change the position. When such an option is checked, scribus would proceed to insert the page(s) and then open the Preferences dialog immediatly after inserting the page

- OR : simply ask wether the inserted future-new-first page should be left or right

It would make scribus use or discovery easyer, all the more since the "Insert page" and the "first page position" have very distant UI access
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
10651 [Scribus] Import / Export feature have not tried 2012-03-31 08:00 2020-02-21 23:47
Reporter: JLuc Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: 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.
Tags:
Steps To Reproduce:
Additional Information: - the SLA fragments folder can be shared with other users
Attached Files:
Notes
(0027884)
JLuc   
2012-03-31 08:35   
(Last edited: 2018-03-23 08:54)
============

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

(0029048)
JLuc   
2012-10-14 19:37   
(Last edited: 2014-05-15 22:19)
2 related propositions

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

(0030167)
JLuc   
2013-05-23 12:03   
(Last edited: 2013-05-23 12:03)
this request is intended toward enabling basic cooperation
using some cloud storage for the file bits.

(0031889)
ale   
2014-05-20 17:59   
... before implementing this, we should have scribus to accept relative paths for resources...
but it's an interesting request!
(0031913)
JLuc   
2014-05-22 16:05   
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.
(0033125)
JLuc   
2014-08-01 09:55   
(Last edited: 2020-02-21 23:47)
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



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
10109 [Scribus] Scripter feature N/A 2011-07-08 08:43 2020-02-21 23:00
Reporter: ale Platform:  
Assigned To: jainbasil OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: scripter-ng api: add functions to move layers through the stack
Description: it should be possible to move a layer up, down, to the top and to the bottom (and eventually above and below a specific one)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16054 [Scribus] Styles tweak always 2020-02-19 10:22 2020-02-21 19:16
Reporter: sreerajp Platform: Windows  
Assigned To: jghali OS: 10  
Priority: normal OS Version: 1909  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: Styles are disabled when trying to edit style for first time
Description: Styles will be disabled if we open the Style Manager on creating a new document
Tags:
Steps To Reproduce: Create a new page in Scribus.
Got to Edit -> Styles
Click on Edit>> button
Select a Paragraph Style. It will be disabled.
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16056 [Scribus] Story Editor / Text Frames minor always 2020-02-20 16:46 2020-02-21 00:06
Reporter: sgonzalez Platform: Intel x64  
Assigned To: OS: Windows 64 bits  
Priority: normal OS Version: 10  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Cannot override "All Caps" nor "Small Caps" set in character style
Description: When "All Caps" or "Small Caps" are set in Style Manager for a character style, then it is not posible to override those settings in Story Editor. Apparently the setting is removed but when the dialog is closed it is not saved (when opening Story Editor again, the setting is still there).
Tags: All Caps, Character Style, small caps, story editor, Text frame
Steps To Reproduce: Set "All Caps" or "Small Caps" in Style Manager for a character style, then all text frames using that character style are refreshed with the new property.

Edit text in Story Editor, uncheck "All Caps" or "Small Caps" settings (apparently the setting is unchecked) and save the changes.

The text in the frame remains as "All Caps" or "Small Caps", and when opening Story Editor again the settings are checked.
Additional Information:
Attached Files:
Notes
(0047418)
jghali   
2020-02-21 00:04   
I have modified the summary because this is in fact not limited to story editor.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16052 [Scribus] Story Editor / Text Frames minor always 2020-02-17 18:23 2020-02-20 15:49
Reporter: utnik Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: complex text frames (from combined polygons) show strange artefacts.
Description: text frames with 'holes' (like converted letters with counters) can't be fully filled with text. some areas won't accept any text. (see screenshot.)
the same frames don't show any such problem when converted to (and used as) image frames.
Tags:
Steps To Reproduce: - draw two different shapes (i.e. a bigger and a smaller rectangle)
- select both of them and combine them with 'item' → 'path tools' → 'path operations' → 'subtract' (you'll get a complex frame with a hole in it.)
- convert the object into a text frame and fill it with text

there are some areas without text. (strange path connections between the two original shapes.)
the same problem appears when you convert text (or just one letter with a counter, like A, B, D, R…) to outlines and then to a text frame. the counters (holes in the frame) don't behave as they should.

Additional Information:
Attached Files: complex_text_frame.png (142,384 bytes) 2020-02-17 18:23
https://bugs.scribus.net/file_download.php?file_id=10875&type=bug
Notes
(0047399)
utnik   
2020-02-17 18:40   
the same behavior in scribus 1.4.8 and with 'complex' shapes created with inkscape and imported as .svg files.
(0047400)
PeterBenedek   
2020-02-17 20:08   
I can reproduce in Linux Mint 19.x and Scribus 1.5.6svn
(0047416)
jghali   
2020-02-20 14:22   
I see where the problem is. Unfortunately at this point it looks like fixing this issue will need some quite extensive modifications.
(0047417)
utnik   
2020-02-20 15:49   
in this case, the way to go is (for the time being) to split the polygons and let the text in the outer one flow around the smaller (inner) shapes. not that problematic, but not as elegant as if the problem could be entirely solved…


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16055 [Scribus] Documentation minor always 2020-02-19 20:16 2020-02-20 14:02
Reporter: LutzBose Platform:  
Assigned To: jghali OS: OSX  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: Errors in messageBox(...) documentation
Description: 1. the manual describes the return value as the number of button starting with 1
   the real return value is the return value of the button type descripted in pre-defined constants (eg. BUTTON_CANCEL: 4194304 and not the button-number 1...3)

2. the manual desribes the pre-defined constant BUTTONOPT_DEFAULT.
    This constant is not defined - to use is instead the constant BUTTON_DEFAULT .

--> please change this desription in manual, chapter 'Using Dialogs' messageBox(...)
Tags: Dialogs, messageBox
Steps To Reproduce:
Additional Information: wrong in local manual
and in online manual
Attached Files:
Notes
(0047413)
LutzBose   
2020-02-19 20:21   
by the way: the 'caption' of function messageBox(...) I have never seen as title of the message box :(


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15359 [Scribus] Story Editor / Text Frames feature always 2018-06-17 12:51 2020-02-20 09:07
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 17.10  
Status: confirmed Product Version: 1.5.5.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Hyphenation unpredictable behaviour (works or not)
Description: When a text runs on several linked text frames,
- Extra > Unhyphens runs consistantly either on the selected text or on whole text frame when no text is selected
- Extra > Hyphens does not run consistantly. It works or does nothing depending on the selected text (or other unknown factors)
Tags: hyphenation
Steps To Reproduce:
Additional Information:
System Description
Attached Files: Montserrat-Light.otf (91,496 bytes) 2019-03-12 19:47
https://bugs.scribus.net/file_download.php?file_id=10374&type=bug
bug hyphens 2-2.sla (43,895 bytes) 2019-03-12 19:58
https://bugs.scribus.net/file_download.php?file_id=10375&type=bug
bug hyphens.sla (46,278 bytes) 2019-03-17 09:36
https://bugs.scribus.net/file_download.php?file_id=10379&type=bug
hyphen issue.png (12,140 bytes) 2019-03-17 09:36
https://bugs.scribus.net/file_download.php?file_id=10380&type=bug
bug hyphens unpredictable.sla (49,015 bytes) 2019-03-17 10:13
https://bugs.scribus.net/file_download.php?file_id=10381&type=bug
Notes
(0045994)
JLuc   
2019-03-12 19:58   
(Last edited: 2019-03-17 09:38)
Same happens with "chômage" word.

Here is the SLA document.

(0046017)
JLuc   
2019-03-17 09:36   
In this document, 2 examples where there is no way to automaticaly hyphenate the word. Neither selecting frame, nor selecting paragraph, nor selectinf all, nor selecting single word before requesting to hyphenate does achieve hyphenation.

Words are : contexte and consommation.
(0046018)
JLuc   
2019-03-17 10:13   
(Last edited: 2019-03-17 10:18)
This other document is an example of unpredictable behaviour of hyphenation.

It provides 4 testing paragraphs each with a coloured word. Explanations are included beside the test texts.

In first and 2nd paragraph, word is "globalement".
- select the text frame, hyphenate : nothing happens
- enter text edit mode
- select whole text or only first paragraph text, hyphenate : nothing happens
- select first paragraph text except first and last line , hyphenate : nothing happens
- select first paragraph text except 2 first lines and last line, hyphenate : it happens !

2nd paragraph text is first paragraph text with 2nd line missing.
- Select 2nd paragraph, hyphenate : hyphenation happens !

In 3d and 4th paragraph, word is "chômage" and "chomage".
- Select paragraph, hyphenate : nothing happens !
- Select word, hyphenate : it does.

I previously uploaded the used font.

(0047415)
JLuc   
2020-02-20 09:03   
(Last edited: 2020-02-20 09:07)
Hyphenate best works when ONE single word is selected. But even so it doesnt work in all cases.

Not so well but not too bad, hyphenate works when selecting the text inside a single texte frame. Sometimes though, it doesnt work on such a text : maybe when the selected text's features some specific applied style changes (even when these style changes are not related to the place where hyphenation should occur)

It seems to never work at all when selecting all the inside text of a linked text chain.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1925 [Scribus] General feature always 2005-04-27 07:05 2020-02-20 07:25
Reporter: ringerc Platform: x86 Linux  
Assigned To: OS: Fedora Core  
Priority: none OS Version: 3  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Multiple users sharing one open document
Description: There has been a fair bit of discussion on IRC etc about having multiple users able to edit a single document, probably via some sort of collaboration server.

Here's a bug for it. Please link useful wiki entries, bugs, mailing list posts, etc from here.

Please understand that there is NO ETA for this, nor any definite plans. Nobody is working on it. Collecting ideas and information now, however, will help make it easier and better if/when it is finally implemented.

This is not about things like linked text or WebDAV access to resources. Those, while also collaboration features and very useful, are not the same thing. This bug is specifically about multiple users working on a single Scribus document at the same time.
Tags:
Steps To Reproduce:
Additional Information:
System Description Home desktop. Beefy athlon box with a gig of RAM. Stock Qt.
Attached Files:
Notes
(0004434)
ringerc   
2005-04-27 07:19   
Reminder sent to: cbradney, kobuswolf, user180, PFJ
Adding you to the monitor list. You can use "unmonitor" if desired, but I know you're all interested in this.
(0007901)
packetbell   
2006-01-02 19:16   
It would be very helpful already if a superset of common UNIX [read|write] PDF [print|annotations] style permissions can be applied to individual frames, pages or entire documents. With that, and support for I/O file streams [1924], one could implement a basic collaboration server with some quick python scripting.

I also like the idea of an external copy editor tool [2108], preferably web based. For instance, if I write a newspaper column, I would have write permissions to the text frame that contains my column. A python script would then return the formatted text-frame to my web browser as a PNG, so I can see how much room I've got left.
(0047414)
JLuc   
2020-02-20 07:25   
See Link text frame to SLA file proposal : https://bugs.scribus.net/view.php?id=10651


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12480 [Scribus] General minor have not tried 2014-07-05 13:26 2020-02-20 07:21
Reporter: JLuc Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Afterflight checker : Warn when some image is outside "images" folder
Description: A new afterflight checker, or a possible project manager, could warn when some image is outside "images" folder.

When doing "prepare ouput and bring images together" ("Fichier" > "Rassembler pour la sortie"), all used images are brought inside "images" subfolder.
This has to be done to share the datas or save them for future use.

BUT it is still possible to edit the file and change some image, maybe use another image as the one in "images" subfolder. Its not possible to know that, afterward, and this leads to dangerous potential situation where it appears later that a used image has been "lost".

[Edit] Since the PDF export is done at least when all is fine (but possibly before), the preflight could a good place to test whether all used images are in "images" subfolder. However, this check is not strictly related to PDF export.
That's why this report now mentions a new "afterflight checker" or "Project manager" that would provide this checking function.

Tags: PreflightChecker
Steps To Reproduce:
Additional Information: [Edit 2015-03] Notes of a discussion on IRC :

- The life of a document is not ended once printed. It can be stored and later re-printed. This can need some work to be done on the document and thus, user has to be able to restore all links and images, years later.
In such situation, its very important that the collect for output operation has been done *after* all image changes or additions have been done in the document.

- This feature belong to some "Project manager"
or some "Afterflight checker" if that makes sense.



Attached Files:
Notes
(0032913)
JLuc   
2014-07-22 10:18   
(Last edited: 2014-07-24 10:54)
In the meanwhile, here is the command i use to find files where some new images have been inserted since the last "Collect all images for output" :

grep -H PFILE= *.sla | grep -v "PFILE=\"images" | sed 's/^\(.*\.sla\).* PFILE="\([^"]*\)".*$/In \1, image has source file outside \/images : \2/'
 


Each resulting line displays the name(s) of a sla file that has to be opened with scribus so as to bring used images in "images" folder, and the source folder of the faulty images.

+ Since i often split published documents in parts that each are in a subfolder, i have writen a more complex "slacheck" script, based on that grep command.

- ATM, it outputs also the embeded images as part of the images that dont have their files in the images/ folder. That is true, but not usefull.

(0032915)
Kunda   
2014-07-22 11:28   
Very cool JLuc!
(0032917)
ale   
2014-07-22 11:59   
basically: very interesting to have an optional "official" images directory...
but i'd prefer a way to set/choose it (also) through the document settings and not have to first collect for output to have one...
(0032959)
JLuc   
2014-07-24 09:56   
(Last edited: 2014-07-24 10:55)
Since i've writen that script, i discover issues in allmost each of the documents (magazine issues) i've archived, which would make their later recovery a problem.
Having that option in PDFchecker would be a neat workflow security improvement.

(0034286)
JLuc   
2014-12-08 19:52   
Improved script is there
https://github.com/JLuc/scribus-project-manager/blob/master/slacheckimages
(0034867)
JLuc   
2015-04-09 20:03   
I edited this report, changed the title and added some comments in the description :

Notes of a discussion on IRC :

- The life of a document is not ended once printed. It can be stored and later re-printed. This can need some work to be done on the document and thus, user has to be able to restore all links and images, years later.
In such situation, its very important that the collect for output operation has been done *after* all image changes or additions have been done in the document.

- This feature belong to some "Project manager"
or some "Afterflight checker" if that makes sense.
(0034923)
JLuc   
2015-04-14 07:10   
(Last edited: 2015-04-14 07:14)
1) As for the "Use document's preference" hint, its not valid really since there is NO "fonts" pane in that dialog, so its not possible to select which of the used fonts are embeded or vectorized.

2) Even if this feature is not required to export the PDFt, it would feel very ok to fit amongst the preflight checks, in a user POV. Maintenability and long term quality is not to be insured in the last bits of a project, or when its finished. It has to be cared from the start, for example when establishing a well choosen set of documents folders. Hence having that proposed check in the preflight check is correct IMO.

(0043504)
JLuc   
2017-02-27 20:44   
Project management and quality reach wider activities than plain PDF export.

Let me quote jghali about quality management it :
« ... errors are rarely intentional. In a quality managed environment, when errors can be committed, a basic rule says: if you can prevent an error, then prevent it. »

In this case, that translates: if you don't want parts of the project to get lost when saving the files, then do warn that there is such a risk.

further quotes : « For more information about quality management:
https://en.wikipedia.org/wiki/Quality_management
https://en.wikipedia.org/wiki/Corrective_and_preventive_action »


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15114 [Scribus] PDF feature N/A 2018-01-27 20:44 2020-02-19 13:21
Reporter: u ltd. Platform: amd64  
Assigned To: OS: alike debian  
Priority: low OS Version: 9  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Make Bounding Box choosable for embedded pdf files
Description: After loading a pdf file to an image frame you can choose to fit the pdf file to the frame border but you cann't choose which part of the pdf (MediaBox=PageSize / TrimBox / BleedBox / CropBox / ArtBox)
Feature requests:
* make that choosable.
* (if not choosable:) communicate to user which box actually is taken.
Tags: boxes, PDF
Steps To Reproduce:
Additional Information: Not important, only if there's someone out there who has nothing to do...
System Description Consisting of packages from debian Jessie, debian Stretch and debian Sid.
Attached Files:
Notes
(0047412)
dcpurton   
2020-02-19 13:21   
+1 to this issue.

An important use case is that if some PDF artwork with a bleed box should indeed bleed into one or more of the margins of the importing document, this is currently impossible as Scribus always chooses the ArtBox.

I had to manually change the ArtBox in a PDF recently to get the bleed to display in an image frame.

I think it would be good to increase the priority of this issue from low.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16035 [Scribus] OS-Linux minor sometimes 2020-01-23 23:54 2020-02-17 23:31
Reporter: jeff Platform: Linux  
Assigned To: OS: Fedora  
Priority: normal OS Version: 31  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scribus UI top menu position incorrectly offset under certain screen arrangements when running a GNOME Wayland session
Description: This one is a bit of a corner case but I thought I'd report it since I have a screenshot to prove it: the menus show up at the wrong position, sometimes off-screen/cut-off, making them unusable under certain arrangements of monitors.
Tags:
Steps To Reproduce: In a GNOME Wayland-based session (haven't tried with GNOME Xorg or other DEs, I'm just assuming this is Wayland/XWayland-related), arrange your screen's positions relative to each other like in my screenshot here (where you can see them staggered in gnome-control-center, instead of aligned), start Scribus, click the menubar, and notice that the menu shows at a weird position.

Changing the alignment of the two displays (i.e. aligning the height of the screens) makes the issue behave differently, much less pronounced.
Additional Information: I am running Scribus 1.5.6svn build ID "C--T-F-C1.16.0-64bit" from November 6, 2019, from https://copr.fedorainfracloud.org/coprs/luya/scribus-unstable/
Attached Files: 2020-01-23 scribus dualscreen menu position incorrect under certain screen arrangements under Wayland.png (316,264 bytes) 2020-01-23 23:54
https://bugs.scribus.net/file_download.php?file_id=10847&type=bug
Notes
(0047401)
jghali   
2020-02-17 23:31   
We do not control directly menu position, this is handled by Qt. This issue may well be related to this Qt bug:
https://bugreports.qt.io/browse/QTBUG-81695


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16048 [Scribus] Story Editor / Text Frames minor always 2020-02-15 04:38 2020-02-15 11:55
Reporter: sreerajp Platform: Windows  
Assigned To: OS: 10  
Priority: normal OS Version: 1909  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Baseline Shift issue
Description: For Baseline Shift if the character we are shifting hits the baseline of the top line, the entire line containing the character we are shifting is shifting down. This is not a desired behavior as per my knowledge. Since the user is doing the activity with his/her knowledge why should the shifting happen?
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0047392)
jghali   
2020-02-15 11:10   
(Last edited: 2020-02-15 11:12)
The baseline linespacing mode being a variant of the automatic linespacing mode, at this moment this behavior is expected. If you do not want this behavior, you should be using fixed linespacing mode.

(0047393)
sreerajp   
2020-02-15 11:44   
Are you planning to change this, may be in future?
(0047394)
jghali   
2020-02-15 11:55   
There is no plan to change this at this moment. However I do not rule out this behavior might be changed in the future.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16049 [Scribus] Story Editor / Text Frames feature N/A 2020-02-15 04:40 2020-02-15 10:58
Reporter: sreerajp Platform: Windows  
Assigned To: OS: 10  
Priority: normal OS Version: 1909  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Span Columns for selected text
Description: It will be very useful if we can span selected text to multiple columns. This feature is there in Indesign and will relieve the user from managing TextFrame grouping. With this feature the heading and body text can be managed in a single Text Frame which will be a great feature.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: scribus.png (143,919 bytes) 2020-02-15 09:42
https://bugs.scribus.net/file_download.php?file_id=10870&type=bug
Indesign.png (100,597 bytes) 2020-02-15 09:42
https://bugs.scribus.net/file_download.php?file_id=10871&type=bug
IndesignSpan.png (21,385 bytes) 2020-02-15 10:11
https://bugs.scribus.net/file_download.php?file_id=10872&type=bug
Notes
(0047386)
JLuc   
2020-02-15 08:37   
I do not understand your request. Can you describe an example ?
(0047387)
sreerajp   
2020-02-15 09:42   
Suppose I have a text frame which is splitted to 5 columns. I want to add a headline to 5 column content which will cover the 5 columns. In scribus, now, I have to create another text frame to type the headline and set the style then adjust the text frame to 2 columns. Then I have to group both the frames to make it bounded.

I have attached images of both scribus and Indesign.
(0047388)
JLuc   
2020-02-15 09:57   
Ok i understand that the results are the same but you prefer how you achieve this with indesign.
So how do you achive this with ID ?
Is there some sort of "colspan=2" paragraph property ?
(0047390)
sreerajp   
2020-02-15 10:11   
Actually both are not same. One is having grouping of text boxes which will cause some work for user if we want to edit anything in Heading or content matter. But in Indesign there is no such extra work.

Yes Indesign uses Span column in paragraph style. Attached a screen shot of the same


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16047 [Scribus] Story Editor / Text Frames minor always 2020-02-15 04:34 2020-02-15 10:57
Reporter: sreerajp Platform: Windows  
Assigned To: OS: 10  
Priority: normal OS Version: 1909  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Malayalam Conjunct and Symbols Rendering Issue
Description: For a text frame filled with Malayalam Characters, if the user traverses using keyboard (i.e, left or right keys) the cursor will appear in the middle of conjunct characters and if the user press enter key the character is getting separated. This should not happen.

In Indesign there is no such issue and the cursor will move to the end position of the conjunct character from the start position of the character.

For Malayalam symbols for vowels the issue is that user can click using mouse in between the character and vowel symbol and on pressing enter it is separated.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16036 [Scribus] Import / Export major always 2020-01-25 19:49 2020-02-11 14:54
Reporter: kdd6 Platform: mac  
Assigned To: OS: lion, sierra  
Priority: normal OS Version: 10.7.5, 10.12.6  
Status: new Product Version: 1.4.8  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: illustrator files will not import on mac, but will on windows
Description: i do not recall when i began converting all of the .cdr clip-art to .ai clip-art so i could use it with illustrator. i had corel's graphic suite 9 at the time. i did not realize immediately that i could use the illustrator files with scribus. i was working primarily with windows and corel and adobe products for photography, graphic design and web design. i had been dabbling in the open source software arena searching for more tools and fell in luv!

in 2011 i added macs to the mix. for a few versions these converted files could be imported. sorry, but i do not recall when this phenomenon began, but i do recall i reported this same problem several years ago. maybe it was around or after the 1.3.x/1.4.x change.

with each new version in windows, the illustrator files import, but not so on (my) mac. i do remember comments on the list at that time others with macs were not having this problem.

i will attach several converted/converted files and maybe something in the (second) conversion caused this to happen. if this is my problem, then maybe someone could offer assistance with a patch to fix my problem. for a fee of course.
Tags:
Steps To Reproduce: try to import an illustrator file
Additional Information: the first conversion was on windows, graphic suite 9 files through corel draw x4 to illustrator 9 files.

the second conversion was on mac (lion) through illustrator cs5.5.

these imported for a version or two before importing no longer functioned.
Attached Files: attnwk05-cd9.ai (38,765 bytes) 2020-01-25 19:49
https://bugs.scribus.net/file_download.php?file_id=10848&type=bug
CGS04190-cd14.ai (21,849 bytes) 2020-01-25 19:49
https://bugs.scribus.net/file_download.php?file_id=10849&type=bug
ai-0000248.cdr (39,364 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10862&type=bug
ai-0000958.cdr (38,700 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10863&type=bug
cd9-attn0020.cdr (18,708 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10864&type=bug
cd9-celtc111.cdr (18,154 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10865&type=bug
cd13-X3004176.cdr (135,778 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10866&type=bug
cd13-X3006747.cdr (13,626 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10867&type=bug
cd14-CGS06007.cdr (112,540 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10868&type=bug
cd14-CGS08960.cdr (104,473 bytes) 2020-02-11 14:54
https://bugs.scribus.net/file_download.php?file_id=10869&type=bug
Notes
(0047345)
utnik   
2020-01-26 08:52   
i can confirm with scribus 1.4.8 on macOS 10.14.6 –the files won't load.
with scribus 1.5.6.svn both .ai files can be imported as long as i chose the .ai part of them. with the .pdf part scribus shows no reaction at all.
(0047375)
jghali   
2020-02-08 21:15   
The .pdf part of those Illustrator files contains nothing : opening them with Adobe Reader shows blank pages too.
(0047385)
kdd6   
2020-02-11 14:54   
i can confirm that scribus 1.5.5 that the cd9.cdr files on mac os 10.15.3 on open
receives the error message "starting uniconverter failed . . . . " and then "scribus crashes on signal 11".
on import, nothing. the import nor the open dialog does not appear as the do on the other files.

the converted ai to cdr. files will import with a click at the end.

the cd13 and 14 both import and open fine (with a little help). i had read jghali's note regarding the pdf import being blank. i too experienced this; however, i found that if you choose the pdf and it does not present itself immediately, i found that a click on the page places the file. the


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16044 [Scribus] OS-MacOSX major always 2020-02-09 18:09 2020-02-11 09:59
Reporter: JuanRubio Platform: Mac-Apple  
Assigned To: OS: MacOs hig sierra  
Priority: normal OS Version: 10.13.6  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scribus was not able to load its preferences
Description: When I choose the language of the user interface "Latin Spanish" in preferences I get the following error:

"Scribus was not able to load its preferences:
Default settings will be loaded."

... and when I start the program, if I want to enter preferences again, they are no longer available, it does not allow me to enter the preferences dialog box.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: MacOs hig sierra 10.13.6 (17G11023) Bug .png (36,797 bytes) 2020-02-09 18:09
https://bugs.scribus.net/file_download.php?file_id=10858&type=bug
MacOs hig sierra 10.13.6 (17G11023) Bug 2.png (203,294 bytes) 2020-02-10 03:08
https://bugs.scribus.net/file_download.php?file_id=10859&type=bug
MacOs hig sierra 10.13.6 (17G11023) Bug 3.png (230,236 bytes) 2020-02-10 03:08
https://bugs.scribus.net/file_download.php?file_id=10860&type=bug
scribusSpanish.png (119,855 bytes) 2020-02-11 09:59
https://bugs.scribus.net/file_download.php?file_id=10861&type=bug
Notes
(0047378)
jghali   
2020-02-09 19:04   
We have no official translation for "Spanish (Latin)". So I'm not sure how you can get that language to show in the UI language list. That language for sure does not appear on Windows.
(0047380)
JuanRubio   
2020-02-10 02:54   
Oh, maybe I am wrong, it is true only "Spanish" appears, a thousand apologies, that is the language that when I choose it causes me the error.
(0047381)
JuanRubio   
2020-02-10 03:08   
I send 2 screenshots so you can see the sections that have an error.
(0047382)
jghali   
2020-02-10 21:23   
I tried multiple times to reproduce your preference loading issue on Windows. Unfortunately at this point of time I have been unsuccessful.
(0047383)
JuanRubio   
2020-02-11 04:50   
Maybe you are not successful because as I explained from the beginning that I report this error, my system is MacOs hig sierra 10.13.6. My computer is an Apple Macbook. And apparently you are using Windows to replicate the error. You will have to get an Apple computer with MacOs X installed to be able to replicate the error I am telling you.
(0047384)
utnik   
2020-02-11 09:59   
i can confirm some problems with scribus 1.5.5 and 1.5.6.svn-r23404 on macOS 10.14.6 in spanish.
after changing the ui language to 'spanish' i'm not able to reach the preferences any more. in 1.5.5 the menu looks a bit strange (see screenshot). scribus 1.5.6 doesn't show the strange .pdf entries, but the prefs won't open either.
when i close a document, scribus crashes with 'signal 11'. this doesn't happen with a german or english ui.
i had to change the ui language back manually in 'prefs150.xml' to use scribus again.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16045 [Scribus] Story Editor / Text Frames major always 2020-02-10 12:45 2020-02-10 15:51
Reporter: sreerajp Platform: Windows  
Assigned To: OS: 10  
Priority: normal OS Version: 1909  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Text selection in the text box is not properly working
Description: While selecting the text, say first 10 lines, in a text box if the mouse cursor moves outside the text box the top/bottom lines are not getting selected. Sometimes it is very difficult to select the first character (if the selection is backwards).

Imagine the following scenario

I have three line, where the line in between is blank. I have selected the three line and changed font size to say 22pt from 12pt. Now if I place the cursor in the blank line the font size will be 22pt. So if I type something in the blank line the content of that line will be 22pt.
Tags: text
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16043 [Scribus] Templates minor have not tried 2020-02-06 15:32 2020-02-09 21:36
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Template folder
Description: When saving a document as a "modèle" (french wording), scribus asks where to save.

I wish my new "modele" to be proposed to me when i want to create a new document from "modele".
So where should i store it ?

In case i have to store it in the same folder as the other default "modeles", could scribus display their folder path in the « Open from "modele" » filedialog window ?

In case there are other possible places to store the user-created "modeles", could scribus displays them or propose a way to easily access these precious places in the « Save as "modele" » file dialog window ?

Since obviously scribus knows thes paths since it has to use them when it proposes the default "modeles", it should share this usefull knowledge when it's usefull to enable to save new defaults "modeles".
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0047374)
jghali   
2020-02-08 21:07   
>> I wish my new "modele" to be proposed to me when i want to create a new document from "modele".
>> So where should i store it ?

In the directory specified in File > Preferences > Paths > Document Templates. Once saved here, the template will appear in the "New From Template" dialog in the "Own Templates" section.
(0047379)
JLuc   
2020-02-09 21:36   
Gosh, I had forgotten that "paths" option ! Thanks for remembering.

Your answer is very helpfull to me... but the 0016043 request for UI improvement is still valid.

A UI should not require more specific knowledge than what it provides itself.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14836 [Scribus] Graphics / Image Frames major have not tried 2017-05-31 16:11 2020-02-09 17:55
Reporter: aszab Platform:  
Assigned To: OS: Sierra  
Priority: high OS Version: 10.12.4  
Status: new Product Version: 1.4.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Image links corrupted
Description: Hi,

The file I am working on contains lots of images (more details in the "additional information" box below).
Yesterday I noticed that all but 2/3 images links got corrupted (i.e. image frame now appears crossed in red). The image links have not been changed. I could restore some of the links thanks to the "image management", but not all of them. I had been working so far for a couple of day on the file very smoothly, without encountering any trouble.
Besides, the "vérificateur" (check box) indicates many images as now missing.
The .PDF print shows the text but no picture (except on the images where the link could be restored)

I would really appreciate if you could help me solve this issue : get the images on the file

Many thanks for your help




Tags:
Steps To Reproduce:
Additional Information: Current .SLA file size : 244 Ko
Number of images on the file : 77 (only approx. 15 appear correctly now)
Number of pages w/ text+images : 9
Number of pages forecast for this file : 16 (and 30 more images)
Attached Files:
Notes
(0043973)
jghali   
2017-05-31 16:20   
(Last edited: 2017-05-31 16:21)
We will need your document to investigate the issue.

>> Yesterday I noticed that all but 2/3 images links got corrupted (i.e. image frame now appears crossed in red).

Did you move your .sla file? Links are stored relative to the document path, so if you move your file, there is a high probability links will break. If you choose to move your document, you should use File > Collect for output to collect file and images so they can be moved.

>> I would really appreciate if you could help me solve this issue : get the images on the file

Right-click on image frame, then Get Image.

(0043974)
aszab   
2017-05-31 16:32   
>> Did you move your .sla file?
No I did not move the file

>> Right-click on image frame, then Get Image.
I am sorry this does not work. Actually I have just tried and a blurred image appears when I tick "revisualization"
+ When I select it for download, nothing happens.
(0043976)
jghali   
2017-05-31 17:07   
(Last edited: 2017-05-31 17:08)
>> I am sorry this does not work. Actually I have just tried and a blurred image appears when I tick "revisualization"

If an image appears, that means it has worked! Scribus does not show images in full resolution by default for memory usage reasons. You can change that by right-clicking image frame and change preview resolution (Preview Settings > Low Resolution / Normal Resolution / Full Resolution). However it is not advised to do so.

>> When I select it for download, nothing happens.

Download what, from where? Scribus does not support using internet URLs for image links.

(0043977)
jghali   
2017-05-31 17:13   
(Last edited: 2017-05-31 21:16)
>> Yesterday I noticed that all but 2/3 images links got corrupted (i.e. image frame now appears crossed in red).

Thinking about another possibility: your computer is running out of memory. A symptom of this is white image frames and image failing to load. When working with doc with lot of images, it is advised to split doc in several files. As mentioned in my previous note, you should avoid using full resolution previews when working with doc containing lots of images. Doing so increase memory usage.

(0043980)
aszab   
2017-06-01 11:46   
Dear jghali,

Thank you for your help, as the hereunder advice does enable the images to show up again. Which solves my current problem.
>> You can change that by right-clicking image frame and change preview resolution (Preview Settings > Low Resolution / Normal Resolution / Full Resolution). However it is not advised to do so.

2 questions :
1/ is it possible to change the resolution for all the images at once ? (I had to change their resolution one by one)
2/ why is it not advised to do so ? (">>However it is not advised to do so.")
(0043981)
jghali   
2017-06-01 15:00   
1/ is it possible to change the resolution for all the images at once ? (I had to change their resolution one by one)

For future document: File > Preferences > Tools > Image tab > On Screen Preview
For current document: File > Document Settings > Tools > Image tab > On Screen Preview

2/ why is it not advised to do so ?

Using a full resolution preview considerably increase memory usage. This reduce the number of images Scribus can load and increase the risk of crashes.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4520 [Scribus] Graphics / Image Frames crash always 2006-11-12 21:05 2020-02-09 17:52
Reporter: sherwood Platform: PC  
Assigned To: jghali OS: Windows XP Pro  
Priority: normal OS Version: 5.1 SP2  
Status: assigned Product Version: 1.3.3.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Crash while placing multiple large JPEG images
Description: In a new document, Scribus fails while placing multiple large JPEG images, with the message

"Scribus crashes due to the following exception: EXEPTION_ACCESS_VIOLATION"

Additional debugger information from MS Visual Studio 2005 debugger in the attached file.
Tags:
Steps To Reproduce: In an empty 1-page document, insert an image frame, size about 2.4 cm x 2.5 cm.

Place the image 1994_Apr_013.jpg, which I have previously made available as http://rapidshare.com/files/2839962/1994_Apr_013.jpg.html. Ignore the warning about resolution tags missing.

After the image is successfully placed, type ^C once, followed by ^V 15 times. This should make 15 copies of the image. After several seconds, the above crash occurs.

If ^V is typed 10 times, there is no crash, and the copies can be moved (they are created superimposed).
Additional Information: System has 2 GB RAM.

The crash is reproducible, but the address of the access violation varies.
Attached Files: ScribusCrash2.txt (3,474 bytes) 2006-11-12 21:05
https://bugs.scribus.net/file_download.php?file_id=2399&type=bug
Notes
(0015059)
jghali   
2007-01-31 23:12   
This is solvable by using shared objects for image. Will try to work on that for 1.3.6/1.3.7
(0032767)
Kunda   
2014-07-15 12:26   
Rapidshare links is obsolete. How big was the image? (so I can reproduce)
(0045015)
jberg   
2018-03-01 09:49   
I couldn't add any more notes over on 0015174, but would like to add that (a) the images I had were downscaled to 2048 longer side (mostly 2:3 and 3:4 format), and that it also doesn't generally happen while loading this document, only while loading it for the first time with nwe images, or so.

I have no reason to doubt your analysis, but I have (including swap) about 12-14 GB available memory, and scribus (1.5.4svn) uses about 6 or 7 while having three such documents open.

So I think in my case it would imply that something is - perhaps when thumbnailing - leaking memory? Once I open the document a few times or do the same steps a few times eventually I no longer get a crash and can work with the document just fine.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15896 [Scribus] Properties Palette feature N/A 2019-11-01 17:15 2020-02-07 04:01
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Indigo UI: shrink the size of the XYZ pane
Description: following martin's Indigo UI project, i've started shrinking the XYZ pane in the properties palette.

some notes:

- the name of the item disappears.
  martin planned, to put in an "advanced" expandable section, i'd prefer to make the name editable in the outline window: it's a better place for it! (a separate patch will follow; please wait for that patch before committing this one)
- the group and ungroup buttons are removed (they are actions, not properties; the are other and better ways to group items)
- martin puts the basepoint at top left (most prominent place!), i'd prefer putting it at the bottom right (it's not so often used...)
- martin puts the "do not export item" button in the "advanced" expandable section.
  as i wrote in 0015894 i did not expect it, but i've found an ok place for it... please discuss there if we can remove the button. i would be really be really glad if we can get rid of it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: xyz-3.png (20,970 bytes) 2019-11-01 17:15
https://bugs.scribus.net/file_download.php?file_id=10674&type=bug
indigo-pp-xyz.diff (32,117 bytes) 2019-11-01 17:48
https://bugs.scribus.net/file_download.php?file_id=10675&type=bug
Martin's_basepoint.jpg (20,060 bytes) 2019-11-01 19:31
https://bugs.scribus.net/file_download.php?file_id=10676&type=bug
Move_icons.jpg (2,654 bytes) 2019-11-01 20:20
https://bugs.scribus.net/file_download.php?file_id=10677&type=bug
xyz-4.png (30,362 bytes) 2019-11-02 11:29
https://bugs.scribus.net/file_download.php?file_id=10679&type=bug
xyz-4.xcf (75,050 bytes) 2019-11-02 11:37
https://bugs.scribus.net/file_download.php?file_id=10680&type=bug
xyz-4_modified_PeterB.xcf (80,919 bytes) 2019-11-02 12:22
https://bugs.scribus.net/file_download.php?file_id=10682&type=bug
Basepoint.jpg (32,841 bytes) 2019-11-02 12:22
https://bugs.scribus.net/file_download.php?file_id=10683&type=bug
xyz_PeterB.jpg (34,670 bytes) 2019-11-02 13:00
https://bugs.scribus.net/file_download.php?file_id=10685&type=bug
alignment.gif (332,316 bytes) 2019-11-02 14:20
https://bugs.scribus.net/file_download.php?file_id=10687&type=bug
xyz_PeterB-2.jpg (34,103 bytes) 2019-11-02 14:26
https://bugs.scribus.net/file_download.php?file_id=10688&type=bug
XYZ_compromise.jpg (17,944 bytes) 2019-11-02 19:05
https://bugs.scribus.net/file_download.php?file_id=10691&type=bug
xyz-5.png (16,285 bytes) 2019-11-02 19:30
https://bugs.scribus.net/file_download.php?file_id=10692&type=bug
ale_original.jpg (13,524 bytes) 2019-11-03 08:09
https://bugs.scribus.net/file_download.php?file_id=10693&type=bug
peter_request.jpg (8,649 bytes) 2019-11-03 08:09
https://bugs.scribus.net/file_download.php?file_id=10694&type=bug
xyz-6.png (17,362 bytes) 2019-11-03 11:43
https://bugs.scribus.net/file_download.php?file_id=10697&type=bug
basepoint_flipp_horizontally.jpg (7,593 bytes) 2019-11-03 12:14
https://bugs.scribus.net/file_download.php?file_id=10698&type=bug
basepoint_middle_left_size.jpg (10,138 bytes) 2019-11-03 12:14
https://bugs.scribus.net/file_download.php?file_id=10699&type=bug
Flip_buttons.jpg (10,972 bytes) 2019-11-03 13:32
https://bugs.scribus.net/file_download.php?file_id=10701&type=bug
indigo-pp-xyz-peter.diff (52,026 bytes) 2019-11-04 17:16
https://bugs.scribus.net/file_download.php?file_id=10704&type=bug
Basepoint_left.jpg (137,266 bytes) 2019-11-05 08:34
https://bugs.scribus.net/file_download.php?file_id=10706&type=bug
Scribus, shrink the size of the XYZ pane.svg.png (58,855 bytes) 2019-11-05 19:17
https://bugs.scribus.net/file_download.php?file_id=10707&type=bug
xyz-bubu-01.png (8,620 bytes) 2019-11-06 08:07
https://bugs.scribus.net/file_download.php?file_id=10714&type=bug
xyz-bubu.diff (54,014 bytes) 2019-11-08 09:30
https://bugs.scribus.net/file_download.php?file_id=10727&type=bug
indigo-pp-xyz-20200110.png (19,552 bytes) 2020-01-10 10:45
https://bugs.scribus.net/file_download.php?file_id=10837&type=bug
indigo-pp-xyz-20200110-switched.png (21,267 bytes) 2020-01-10 10:47
https://bugs.scribus.net/file_download.php?file_id=10838&type=bug
Notes
(0046896)
ale   
2019-11-01 17:48   
(Last edited: 2019-11-04 18:25)
[there is a newer patch further down...]

here is the patch.

the one open issue, is the rotation icon that cannot be read.
we can of course keep the unicode character... it's probably good enough (and in the current state of the icon, probably even better)

the images can be downloaded from the merge request on gitlab:

https://gitlab.com/scribus/scribus/merge_requests/8

there will be an appimage as soon as the CI has done its work.

just one note: if we can remove the "do not export" button, then i would align the basepoint widget to the right of the panel.

and, as discussed on irc: if somebody can provide better (quality) icons: you're very welcome!

i've not tested it throughly, but i think that the patch is ready for review and commit.
(or as soon i've (somebody has) submitted a patch for the "outline" window... i plan to do it tomorrow...)

(0046897)
PeterBenedek   
2019-11-01 19:31   
" - martin puts the basepoint at top left (most prominent place!), i'd prefer putting it at the bottom right (it's not so often used...)"

Sorry ale, but I do not agree.
Basepoint function is very important, it must be used many times during editing, in case if the work is serious!
I suggest that if it is in the lower right corner, make bigger (like Martin's basepoint).
(0046898)
jghali   
2019-11-01 19:57   
There is one big problem with this patch: it removes the item name edit field without moving it in another place.
(0046900)
PeterBenedek   
2019-11-01 20:20   
Proposal:

"Move icon" in the Inkscape (symbolic icons) very nice.
What do you think?
(0046901)
PeterBenedek   
2019-11-01 20:34   
From field switch order (if you pressed the tabulator button) the H field is left out.
(0046902)
ale   
2019-11-01 21:33   
@jean, as written above, my plan would be to move the editable item name to the outline window... i really would like to avoid to have it in a "hidden" part of the palette like martin was suggesting.
@peter, yes i like those up and down icons, too can youp rovide 4 png files of the right size? i think that 16 x 16 should be fine.
@peter: i'm fine with using martin's basepoint widget. but i prefer to first get the new laoyut with the existing one and -- as we shortly discussed with craig in irc -- later replace it with a nicer / more useful one. (martin's has also two more anchor points, which means that the logic of the code has to slightly change...)


and yes, the icons need some more polishing... (and we also need the dark theme icons...).
(0046905)
jghali   
2019-11-02 05:38   
(Last edited: 2019-11-02 05:42)
@ale, that would be the wrong way to do it, see my response on 0015897. That would also imply that user working on PDF forms would need to use an additional dialog window, the document outline window, to do their job. And given the performance impact this dialog has when opened, I would prefer to avoid giving users another reason to open it.

(0046907)
cbradney   
2019-11-02 06:43   
Agree, this needs more work. Item name should not disappear from this palette.
(0046909)
ale   
2019-11-02 07:36   
the performance argument is indeed a very valid one.

the main goal of my effort is to make both the properties palette and content palette, with most sections expanded, to use at most half of the vertical space on a typical screen (ok, my screen).

in my experience, very few users have a use for the item name and it's difficult to place it somewhere without using a full line.
(of course, the ones who are participating in this thread are the ones that are most likely to see a use for it... but somebody who creates a book, a flyer or a magazine will probably never edit an item name)

as written above, martin wanted an expanding "advanced" section for the xyz pane.
personally, i don't like the idea: an item should belong to a place or not.
so we should find the right place for each thing, rather than hiding what we don't like.

a (temporary?) compromise, could to create an "advanced" collapsing section for the whole properties palette and put in there things like the "item name" and the "do not export" button...
what do you think about that?
(0046911)
PeterBenedek   
2019-11-02 10:08   
(Last edited: 2019-11-02 10:10)
" but somebody who creates a book, a flyer or a magazine will probably never edit an item name"

Only a opinion.
I've been using it for ten years the scribus but I've never edited name of item.

(0046912)
PeterBenedek   
2019-11-02 10:33   
Proposal:

The values ​​of X and Y shouldn't be side by side, but under each other.
Side by side terrible.
(0046914)
ale   
2019-11-02 11:28   
(Last edited: 2019-11-02 11:31)
i've implemented this layout without much thoughts on this specific topic.

i see that the three other main dtp software has them vertical. in two columns
inkscape has it all horizontally: x, y, w, h.

having x,y and w,h horizontally, allows us to use very little space and imo a very logical placement for the three lock buttons (proportions, position, size).

i wonder if side by side is just something that is just as good once somebody gets used to it or if it has real drawbacks.
(the tab order is currently broken, but i will fix it as soon as possible)

personally, in scribus, i don't look at the values as having any meaning. i just go to adjust a single value to something correct and i check visually on the canvas that everything looks ok.
but i agree that if you want to check the x,y coordinates (or the w.h pair) it's more comfortable if they are stacked on top of each other rather than side by side.

if you can suggest a good layout with the three buttons, i can try a different proposal, otherwise i'd suggest to keep it as is and we will see if in practice it is as disturbing as it seems at first sight.
now, that the single items are in place, it's not hard to move them around.

and after having written all this i've tried to shuffle around the fields and buttons... would the attached proposal be better?
the xy wh are for sure to your taste... but are the lock buttons ok?

(0046916)
ale   
2019-11-02 11:37   
i attache the xcf with a layer per label / button
(0046917)
PeterBenedek   
2019-11-02 12:22   
New and old Properties.
I thought so.
Opinion?
(0046919)
PeterBenedek   
2019-11-02 13:00   
Just a idea...
(0046923)
ale   
2019-11-02 13:24   
i don't know, i really don't like the basepoint on the left.
personally, i (almost) never change it... it's probably because i don't rotate so often the items.

i have the feeling that the last proposal with the three columns attracts my eyes fully in the wrong place.

also, i'm trying to use as little vertical (and horizontal) space as possible...

i can try to make a merge request with my poposal above, without the "do not export item", the new level icons, and with a new widget for the base point aligned to the right... (having seen your screenshot above has given me an idea how to easily tweak the current widget to look better... but four of the buttons won't be clickable for now)

it will take a couple of hours...
(0046924)
PeterBenedek   
2019-11-02 14:20   
The left basepoint is important for the continuity of work.
You choose the alignment and then X-pos or Y-pos.

Set a simple example for you...
(0046927)
ale   
2019-11-02 16:13   
i wrote a very intelligent note to this topic but it somehow got lost.

i will not write it again just this:

here is an appimage with the proposal above, inclusive the new widget for the basepoint (it does not work yet, but you can click the position that correspond at the ones that are implemented in scribus):

https://gitlab.com/a.l.e/scribus/-/jobs/340092171/artifacts/file/Scribus-nightly-x86_64.AppImage

personally, i really like it.

ps.: btw, the new widget is much simpler and cleaner than the previous one : - )
(0046929)
PeterBenedek   
2019-11-02 17:49   
-- Padlock icon is wrong place (I don't understand the logic).
-- Would be needed a small padding inside the widget.
-- ale! Please! Basepoint widget let it be the left of the panel.
(0046930)
PeterBenedek   
2019-11-02 18:51   
Compromise?

Please consider the possibility.
(0046931)
PeterBenedek   
2019-11-02 19:05   
Move icons sequence: I change the order
(0046932)
ale   
2019-11-02 19:30   
peter, i really don't understand why you want so hard the basepoint to the left.

in the gif above, i don't understand either why you're changing the basepoint.
you have the snap to item activated and you can align the frames without copy pasting the position.
(it's a clever trick, but there are easier ways to get items to be on top of each other...)

indeed, i've never seen somebody using the basepoint in such an intensive way!

i would say that the most typical use of the base point i can think of is to get the rotation to behave correctly.
but i might also be an edge case...

my reasons for having on the right side are:

- it allows to have a more compact widget.
- normally, what i want to reach is one of fields among x, y, w, and h... and rotation... and it's those fields that i'd like to give the best visibility
- we can use the same widgets for possibly creating an horizontal toolbar by separating this in two.

for the lock buttons, i agree that the logic is not really good.
martin's idea was to have the position (full) lock attached to the x, y fields and the size lock attached to the w and h.
the size constraint is also attached to the w and h.

i guess that the fact that it's easier to place the luck buttons was the reason why martin has put x and y on a line instead of a column.

i've tried to put together one last proposal...

https://gitlab.com/a.l.e/scribus/-/jobs/340133784/artifacts/file/Scribus-nightly-x86_64.AppImage

this time the basepoint is working.

there are some spacing and padding issues, but i'd like to solve them when all the widgets will be reworked and we can go through all the spacings and find a common solution for the whole palette.

you're welcome to try it out in the appimage and see if it's really so terrible to use...
(0046933)
ale   
2019-11-02 19:42   
your latest proposal has crossed mine.

personally, the part i use most in the xyz panel are the level buttons... followed by the rotation... sometimes i set the width to a given value in mm.

the two proposals are very similar. but i'd prefer to keep on the left side the small fields with rotation and levels... and the big basepoint can easily be reached on the right side.
(0046934)
PeterBenedek   
2019-11-02 20:17   
"you have the snap to item activated and you can align the frames without copy pasting the position."
It is not the alignment that matters, but the order of the operation.
If you first set a value and then click the basepoint, the end result will be different.
Correct order: set the basepoint --> set the value
That is why the basepoint should be to the left.

Proposal:
Please change the order of the movement buttons (https://bugs.scribus.net/file_download.php?file_id=10691&type=bug)
Correct order: Move to back, Move one level down, Move level one up, Move up
(0046938)
PeterBenedek   
2019-11-03 08:09   
(Last edited: 2019-11-03 08:10)
Hi ale.

Thank you for your work, and your time.
Basepoint is bigger, that's great.
X below Y, thats excellent.

Final request :-)
In your original proposal the basepoint was below the H field.
Is this possible?

(0046939)
ale   
2019-11-03 11:40   
(Last edited: 2019-11-03 11:44)
a new appimage with the order of the level ups an downs reversed and left aligned right basepoint...

https://gitlab.com/a.l.e/scribus/-/jobs/340305155/artifacts/file/Scribus-nightly-x86_64.AppImage


the behavior when enlarging the palette is not correct yet...
this is a general issue with the panels...
i'd like to find a solution for it when all the panes have been adapted. (then we will know what's the minimal and maximal width)

(0046940)
PeterBenedek   
2019-11-03 12:14   
I am very grateful for it.

Two little things.
1) basepoint flipp horizontally icon is wrong
2) basepoint tool middle left icon bigger than the rest (yours too, but not so much: basepoint_middle_left_size.jpg)

thanks again
(0046941)
ale   
2019-11-03 12:47   
a new appimage with both things (hopefully) fixed!

https://gitlab.com/a.l.e/scribus/-/jobs/340325646/artifacts/file/Scribus-nightly-x86_64.AppImage

thanks for reporting the two issue!
(0046943)
PeterBenedek   
2019-11-03 13:32   
(Last edited: 2019-11-03 13:34)
Icons on the Flip buttons need to be replace because, they represent the operation incorrectly.

(0046945)
ale   
2019-11-03 14:48   
oooops. uploaded.

https://gitlab.com/a.l.e/scribus/-/jobs/340353267/artifacts/file/Scribus-nightly-x86_64.AppImage

i was testing with the wrong shape (a line...) and i did not see that it was not correct...
(0046946)
PeterBenedek   
2019-11-03 15:26   
Perfect :-)
(0046955)
ale   
2019-11-04 17:16   
here is a new patch...

https://gitlab.com/scribus/scribus/merge_requests/11
(0046957)
PeterBenedek   
2019-11-04 18:03   
(Last edited: 2019-11-04 18:04)
I miss the padding of panel.
Martin's solution in Indigo project: http://forums.scribus.net/index.php?action=dlattach;topic=1617.0;attach=1989;image

(0046958)
ale   
2019-11-04 18:24   
(Last edited: 2019-11-05 06:55)
@peterbenedek , i'd like to look at it towards the end of the implementation of the UI panels.

currently, there are so many things that are not finished yet and i don't know what is wrong because of the older panels and how exactly the whole palette will look like at the end of the process.

i'd like to suggest that i finish the panels in the properties panel and we can then, when everything is new in, talk about it again?
before starting the huge work on the text panel...

as soon as the xyz is in, i'd like to get in touch with martin: i need explanations on the color panels... he might also have more general feedback.

(0046960)
PeterBenedek   
2019-11-04 18:46   
I mean.
Ok.
They did a fantastic job.
(0046968)
PeterBenedek   
2019-11-05 08:34   
(Last edited: 2019-11-05 08:38)
You don't have to do anything, just listen to this...

Therefore, Basepoint is important to be first in the line of operation (related ticket 0015903)...
I made a flowchart of the problem:

Task: Adjust the height of the object, top to bottom.
Explanation: All operations in the XYZ panel depend on the position of the currently selected base point, even if you do not need to set it before each operation.

(0046974)
ale   
2019-11-05 13:49   
(Last edited: 2019-11-05 13:50)
peter, i have understood your point very well.
and you're 100% right.

but i also believe that most of the time, most users want to look at the values or set them without changing the basepoint.

i found it very interesting to see how intensively you use it, but i don't think i have ever seen anybody changing the basepoint at all.
i also think that if you look for speed, scribus provides better ways to tweak your items, without the need to go to the properties palette.
(personally, in most cases i would go for alt(-shift)-arrow or a guide.)

in the past, i've never read any complaint that the "old" scribus placement of the basepoinit would be bad.
and that's not because it was good (it was terrible), but because most people don't use it. or when they use it, they're in a slow workflow anyway.

(0046978)
bubu   
2019-11-05 19:17   
Hi devs, finally I found this discussion. I'm so happy to see you developing this feature.

I'm nobody here just a translator and a user. But I try tho help you.

As a user...
1. I agree to remove the label of the object from this palette. I never renamed object in normal document, only when I created PDF forms, but in PDF properties palette there are a possibility to rename the object. https://gitlab.com/scribus/scribus/merge_requests/8#note_239173966
2. I usually use origin tool. It's a useful tool. The original "vertical" Scribus XYZ palette was clear: origin tool belongs to X,Y,W,H fields _and_ rotate field. This is broken in new proposals here.
3. Original origin tool was better: It was clear that it has 5 states. When I see this new tool - inspired by InDesign - I think there is 9 states... but it's not true. And new tool is more checkbox like and not radio button like. When I see more squares (=checkboxes) I think I can select multiple states... but it's not true, I can select only one state (like radio buttons). So circles - original look - is better here.

I don't want to criticize, but to help. So here is sketch mockup, how can we join origin tool to X, Y, W, H fields and rotate field. I hope this helps you.
(0046980)
ale   
2019-11-05 21:35   
i plan to use the same widget also for the lines, so i would like to avoid the old 5 circles widget.

i don't know why martin suggested 9 squares, but if we stick with 5 possible values, then i agree that we should make it more clear which buttons can be clicked and which not.
it's probably just a matter of using a different color for those buttons... or simply hiding them.
but i think that the final goal was to have 9 possible states.

i really like the widget you propose above, but it's a bit harder to draw... (basically, the code must draw it; with the boxes martin suggests, it's just a bunch of buttons with a png on top of each; "automatically" layouted)

if you have a proposal for better icons, they're very welcome. but, if possible, i'd like to keep the grid of buttons: it makes things much easier on the programming side.
as said, the other constraint is that it should be easy, to use the same schema (and widget) also for the lines (with only three possible values).

concerning the basepoint on the left: personally i don't "like" the fact that, then, the other buttons are layouted in a "random" way.
where i could see a usable solution, is the proposal a, but with the flip buttons below the rotation input field

b is too cramped for me.

also, the levels are harder to reach... and that's the z part of xyz : - )

my conclusion?

if possible i'd like to stick with the patch as is and get it accepted as fast as possible.
once it's in, we can further discuss where to place the basepoint widget.
and proposal a is not a bad start, if you both really are so uncomfortable with the widget on the right.
(0046986)
ale   
2019-11-06 08:07   
here is a branch with what i could "easily" (still more than an hour of work i could not use for the color panel... mostly spent on fighting designer's grid awkwardness) do out of bubu's a proposal.

https://gitlab.com/a.l.e/scribus/tree/indigo-pp-xyz-bubu

https://gitlab.com/a.l.e/scribus/-/jobs/342954448/artifacts/file/Scribus-nightly-x86_64.AppImage

two comments:

- i'm not sure it would look good, but on the semantics side, i would switch levels and locks...
- the basepoint widget could shrink a bit and/or get better icons... drawing a square behind the circles might be possible.

my position has not changed:

- the levels are a bit hidden (switching levels and locks might help)
- i'd prefer to see the previous patch being committed asap and continue the discussion in a different ticket.
(0046988)
PeterBenedek   
2019-11-06 08:45   
ale, this fantastic. The basepoint tool is finally convenient to use
I am grateful for it.
(0046989)
bubu   
2019-11-06 08:50   
Thank you ale, this layout is much better!
(0046991)
ale   
2019-11-06 10:22   
yes @peterbenedek, but now it's the levels that are not convenient to use : - (
and the rotation.
(if i change the basepoint, before the next movement, i have to take care to reset it to the top left; and if i don't change the basepoint, i have to move around my item to fix its position *and* look for the rotation in the middle of the widget).
i really, think that this layout is worse for those who do not use often the basepoint.

i wonder, if the basepoint shouldn't automatically go back to the top left if you have not used any function that rely on it for more than one minute (or other more or less short time : - )
and you could set the default basepoint in the document settings / preferences.

and the basepoint widget feels too big to me... but i hope that you both will be able to improve on that : - ) (while respecting the fact that it's a 3 x 3 grid!)
after this patch has been accepted!
(0047034)
ale   
2019-11-08 09:30   
here is the "bubu" patch...

please pick one of the two latest diff files

(the new pngs can be downloaded from gitlab, see the links above)
(0047150)
ranjithsiji   
2019-11-27 07:09   
What is the status of this feature? Will it go into the main code?
(0047218)
cbradney   
2019-12-08 21:48   
I've not so fond of https://bugs.scribus.net/file_download.php?file_id=10714&type=bug
It all feels too scrunched up, no label for level. Label for rotation is hidden next to the basepoint contorl. Flip H/V could easily be groups next to locking if you want to have 4 icons together. You could consider grouping the level in a 2x2 group?
(0047219)
ale   
2019-12-08 22:08   
- what kind of label would you want for the levels?
  for the number? personally, i feel that we could remove the number altogether (it's probably of little to no practical use)
  the icon are exactly the same as they are in inkscape...
  and i think that they are rather clear in their meaning.
  i don't think that a text label is needed (there are tooltips that explain what each button does)
- the rotation icon feels indeed a bit lost.
  currently, it's just a unicode character and it should be replaced by an icon.
  i welcome propositions to improve the placement of the rotation (if possible keeping it next to the flip buttons)
- i'd prefer not to have the flipping and the locking together.
  imo, rotation and flips belong together.

personally, i would welcome it, if this patch would finally be accepted as is.

as long as the issues are with the placement of the buttons, it's all in an .ui file and it's easy for anybody to tweak it and propose a new version for discussion.
(or make screenshots and reshuffle the items)

personally, for the next step i'd like to focus on having the basepoint to support lines and to make the xyz + shape always shown in propeties palette (no expanding / collapsing for them, like in the main part of the text panel)
but as long as this patch is not accepted i'm a bit stuck...
(the line panel is mostly ready... and depends on this...)
(0047319)
jfl   
2020-01-06 13:54   
About the item name: couldn't the "Name" field be removed completely? The editable field on it's own would make it clear enough that this is the name of the item. Alternatively, "Name" could be moved to the left of the edit field:
Name: _____________________
(0047329)
ale   
2020-01-10 10:45   
(Last edited: 2020-01-10 13:32)
here the current state:

- item name on top, but separated (i'm still for moving to a collapsing at the end of the PP)
- better placement for the rotation
- i suggest putting the current level in the tooltip over the level down / up buttons. i really can't find a different solution that does not require way to much space and "attention" compared to the usefulness of the information (normally, you just care if an item is above or below another, not the level value... in my experience it has almost only been useful for debugging purposes... not in production)
- i'm tempted to switch the flipping buttons with the level ones and make the buttons on the right side right aligned (and remove the alignment with the x,y / h,w fields)

and here the appimage:

https://gitlab.com/a.l.e/scribus/-/jobs/399164588/artifacts/file/Scribus-nightly-x86_64.AppImage

(0047330)
ale   
2020-01-10 10:47   
here is a mockup of the proposal above, with flip and levels switched and locking on the right side.
(the xy/hw fields do not yet have the same width, sorry)
(0047366)
ranjithsiji   
2020-02-07 04:01   
This is verygood and I fully support to get it on the upstream code. If we can rework all other pallets like this then that will be great for scribus


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14467 [Scribus] General major N/A 2016-12-14 01:01 2020-02-04 20:27
Reporter: SRDC Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version: 1.5.5  
Patch: No
Summary: 1.5.x slows down immensely (with high CPU usage) when opening 1.4.6 file
Description: Have a 147 page 20MB .sla file - no pictures, but lots of groups (a custom daily planner). Just upgraded from Scribus 1.4.6 (scribus PPA), where the document works fine, to Scribus 1.5.2 (from scribus-ng PPA).

Reason for upgrading (besides liking to keep updated software) was that group/ungroup and deletion of groups takes a LONG time. Based on some bug report discussions, it looked like the scribus-ng release might help that. However, it doesn't seem to work well since I can't open the file.

OS: Ubuntu Gnome 16.04.1
CPU: i5 2.4GHz
Memory: 4GB
Tags:
Steps To Reproduce: Open file saved in Scribus 1.4.6 in Scribus 1.5.2. Not sure if it is for every file, or just this one.

Not sure how to upload the file, as it is too large for the file upload.
Additional Information:
Attached Files: 2016-Daily-Planner.sla.gz (318,118 bytes) 2016-12-16 12:21
https://bugs.scribus.net/file_download.php?file_id=9323&type=bug
Notes
(0042981)
Kunda   
2016-12-14 01:24   
Since you haven't shared the SLA and....
there are known issues for large files and...
issues also opening older versions of 1.4 on 1.5...
try testing by opening the SLA on 1.5.3svn (the latest SVN version)
Of course, backup your work first. Also devs don't recommend using 1.5.3svn for production.
(0042982)
SRDC   
2016-12-14 01:25   
Is there a good way to share the SLA?
(0042984)
SRDC   
2016-12-14 01:37   
OK. I uploaded it to our website: http://solidrock-ent.com/2016%20Daily%20Planner.sla
(0042985)
Kunda   
2016-12-14 02:03   
@SRDC thanks.
Devs, I can confirm the issue on 1.5.3svn r21650
Manjaro 16.10
Qt5.7
(0042986)
Kunda   
2016-12-14 02:06   
(Last edited: 2016-12-14 02:24)
@SRDC It actually opened. So it's not an 'infinite loop'. It took ~ 8 minutes or something. (I have 4 cores and 16GB ram)

(0042987)
SRDC   
2016-12-14 02:11   
OK. I thought I'd left it for over an hour, so just assumed it was 'infinite.' Thanks. What should I do now? Just stick with 1.4.6 for that document?
(0042988)
Kunda   
2016-12-14 02:25   
@SRDC for now stick to 1.4.6
Let see what the devs say when they're online.
(0042989)
SRDC   
2016-12-14 02:35   
Alright. Thanks for your help!
(0043062)
Kunda   
2016-12-16 12:18   
Moving to 1.5.3 Roadmap to get some attention
(0043063)
Kunda   
2016-12-16 12:22   
I've attached the sample SLA to the ticket (compressed with gzip)
(0043917)
Eneen   
2017-05-20 11:32   
I've tried to open this file and it takes about 2 mins, but Sribus uses only 1 core of my 8 here. It also seems slow when panning.
(0043920)
ale   
2017-05-22 08:25   
yes, scribus is single threaded (and will be using only one core).

while taking advantage of multiple cores would be welcome, i think that the slowness during the import should be solved in the current code... but only if it also affects the loading of the files once it has been saved in 1.5.x format...

is there a tag for sample files that can be used to test the performance of scribus?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15399 [Scribus] Typography major always 2018-08-14 01:40 2020-02-04 12:06
Reporter: kneekoo Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: new Product Version: 1.4.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Unable to enter certain diacritics in a Text Frame
Description: I tried Scribus 1.4.6 from the default repositories in Linux Mint 18.3 (based on Ubuntu 16.04) and Linux Mint 19 (based on Ubuntu 18.04), and the Text Frame didn't react to typing certain diacritics, with all Romanian keyboard layouts available:
- Romanian
- Romanian (Win keys)
- Romanian (cedilla)
- Romanian (standard cedilla)
- Romanian (standard)

What worked: îâÎÂ
What didn't work: ășțĂȘȚ
Tags: diacritics, text frames
Steps To Reproduce: 1. Install the keyboard layouts mentioned above;
2. Switch to each layout;
3. By using the attached images in this ticket press the keys having the ășț/ĂȘȚ diacritics inside a Text Frame.

The result should be the same for all the keyboard layouts.
Additional Information: Later, I tried Scribus 1.4.7 from this PPA: ppa:scribus/ppa
> https://launchpad.net/~scribus/+archive/ubuntu/ppa

The result was the same (failure) for the "Romanian (standard cedilla)" layout, so it didn't make much sense to try the others.

I didn't notice any information mentioning the PPA would be official or not. So what about it? Is it official or can it be trusted?
Attached Files: kb-layout-Romanian.png (55,292 bytes) 2018-08-14 01:40
https://bugs.scribus.net/file_download.php?file_id=10213&type=bug
kb-layout-Romanian-cedilla.png (56,041 bytes) 2018-08-14 01:40
https://bugs.scribus.net/file_download.php?file_id=10214&type=bug
kb-layout-Romanian-standard.png (56,200 bytes) 2018-08-14 01:40
https://bugs.scribus.net/file_download.php?file_id=10215&type=bug
kb-layout-Romanian-Win-keys.png (65,756 bytes) 2018-08-14 01:40
https://bugs.scribus.net/file_download.php?file_id=10216&type=bug
kb-layout-Romanina-standard-cedilla.png (56,511 bytes) 2018-08-14 01:40
https://bugs.scribus.net/file_download.php?file_id=10217&type=bug
148-update-text-frame-1.png (30,200 bytes) 2020-02-04 12:03
https://bugs.scribus.net/file_download.php?file_id=10851&type=bug
148-update-text-frame-2.png (29,726 bytes) 2020-02-04 12:03
https://bugs.scribus.net/file_download.php?file_id=10852&type=bug
148-update-text-frame-3.png (32,615 bytes) 2020-02-04 12:03
https://bugs.scribus.net/file_download.php?file_id=10853&type=bug
155-normal-edit.png (21,923 bytes) 2020-02-04 12:03
https://bugs.scribus.net/file_download.php?file_id=10854&type=bug
155-update-text-frame.png (23,038 bytes) 2020-02-04 12:03
https://bugs.scribus.net/file_download.php?file_id=10855&type=bug
Notes
(0045375)
ale   
2018-08-14 14:45   
can you please also try with 1.5?

it it works there, and it's not trivial to fix it for 1.4, i fear that for the use case you will have to use the development version...
(0045376)
kneekoo   
2018-08-14 20:18   
Of course I can try it, but the problem is this is not a particular use case. Those diacritics belong to the Romanian language and they're supposed to be used everywhere. This makes Scribus practically useless for everyone who needs the Romanian diacritics.
(0047354)
danimunte   
2020-02-04 07:25   
Hi kneekoo,
Please, have you solved this problem?
Thank you.
(0047355)
kneekoo   
2020-02-04 12:03   
Well, it turns out it's more complicated than that, and 1.4.x can actually use the Romanian diacritics but you have to fight Scribus to get there. I'll describe the issue in more detail here.

> 1.4.8
// note: in my testing, the default font chosen by Scribus was Arial Regular
- I created a new document and inserted a Text Frame, then double-clicked it to edit its contents
- trying to input "ăîâșț" on one line and "ĂÎÂȘȚ" right under it resulted in displaying the text below, the other key presses being completely ignored, like I didn't press any key:
ăîâ
ĂÎÂ
- I right-clicked the text frame and chose Edit Text, to open the Story Mode
- trying to add the missing letters on each row ended up with the same result - like I didn't press any key
- I selected (Ctrl+A) everything inside the Story Mode editor and switched the font to FreeSans Regular
- I clicked the end of the first line and added "șț", which was displayed properly, then went on the bottom line to add "ȘȚ", which also looked right
- I clicked Update Text Frame (Ctrl+W) button to save my changes
- the Text Frame got updated as seen in 148-update-text-frame-1.png
- I opened the Story Mode again, selected the whole text (Ctrl+A) and re-applied the FreeSans Regular font, resulting in 148-update-text-frame-2.png

The Story Mode is clearly buggy, but before drawing a conclusion I did a new test, to see if there was an issue with small case characters or something else:
- I deleted the previous text frame
- I created a new text frame, with more rows, with the result provided by 148-update-text-frame-3.png

So was the last line of text trouble-free in the Story Mode or only the last line, whatever that was? A fresh test revealed that it's the latter. Apart from the last line, the ones above get the wrong (default) font, and it requires you to apply the correct font for a second time.

> 1.5.5
// note: the default font Arial Regular as well
- I created a Text Frame, double-clicked it and entered a few lines of text, resulting in what you can see in 155-normal-edit.png
- I right-clicked the text frame -> Content -> Edit Text with Story Editor, I selected the entire text (Ctrl+A), I changed the font to FreeSans Regular and clicked Update Text Frame, with the correct result on the first try (155-update-text-frame.png)

Please note that LibreOffice properly displays diacritics, even with Arial. I also tested this in an HTML page with the 5 diacritics, in Arial, and they were all displayed correctly.
(0047356)
kneekoo   
2020-02-04 12:06   
In the 1.5.5 screenshots also please note that the letters on the first line are partially cut on top.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16007 [Scribus] General minor have not tried 2019-12-12 15:10 2020-01-29 12:54
Reporter: HairyW Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Option menu not pop up when right mouse click on inserted image frame or text frame
Description: I recently installed scribus-1.5.5.dmg on an iMac with MacOS 10.15 Catalina. The action menu won't show up when I right mouse click on an inserted image frame or text frame.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16010 [Scribus] Import / Export major always 2019-12-16 15:41 2020-01-27 12:28
Reporter: mujeebcpy Platform: gnulinux  
Assigned To: mapreri OS: kubuntu  
Priority: high OS Version: 19.10  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: pdf import is distorting individual elements in pdf
Description: when some pdf (normally with graphic and text elements and in cmyk colorprofile) imported or opened in scribus. the pdf get distorted. im attaching the pdf here.
Tags: PDF, poppler
Steps To Reproduce: download the pdf from this thread
open that pdf in scribus or file ->import->get vector file
Additional Information: libpoppler-utils version is 0.74
users with 0.71 not facing the issue. also 1.5.5 appimage also haven't this issue.
im attaching the pdf and the screenshot of actual pdf and how it appearing in scribus
Attached Files: inscribus.png (169,129 bytes) 2019-12-16 16:00
https://bugs.scribus.net/file_download.php?file_id=10811&type=bug
WC AD 3.pdf (1,724,817 bytes) 2019-12-16 16:37
https://bugs.scribus.net/file_download.php?file_id=10812&type=bug
inscribus.jpg (194,348 bytes) 2019-12-16 18:32
https://bugs.scribus.net/file_download.php?file_id=10813&type=bug
Notes
(0047273)
mujeebcpy   
2019-12-16 15:49   
due to internet issue the files weren't attached. attaching here
(0047274)
mujeebcpy   
2019-12-16 16:36   
the pdf file which makes the issue
(0047275)
ale   
2019-12-16 17:27   
i can confirm that the pdf does not have issues with poppler 0.71
(0047277)
jghali   
2019-12-16 17:52   
I cannot reproduce this issue with poppler 0.83.
(0047278)
mujeebcpy   
2019-12-16 18:04   
could you able to open the above pdf without any issues?
(0047281)
PeterBenedek   
2019-12-16 18:32   
Tested in Linux Mint 19.1; Scribus 1.5.6svn.appimage (fresh)

I see this...
(0047283)
mujeebcpy   
2019-12-16 19:25   
@peter it works on appimage. we have issue with ppa package, and personally i use fedora, its poppler version is 0.73. and im using own builded version of scribus. that too have the issue. i assume it related with poppler version.
(0047335)
mapreri   
2020-01-14 12:12   
You wrote "Kubuntu 19.10", but that has poppler 0.80, not 0.74. Care to explain?

0.74 is in ubuntu disco (19.04) and in the PPA for bionic (18.04). I'm now going to update that copy to 0.80 as well for bionic, but I'd rather not do disco, since that's going to be unsupported in a couple of weeks.
(0047336)
mujeebcpy   
2020-01-16 18:17   
that was my mistake. it was 19.04. we didnt upgraded the systems, we plan to upgrade the systems to 20.04. till that we use 19.04. sorry for the mistake
(0047337)
mapreri   
2020-01-16 22:31   
Alright, I uploaded a new poppler (basically, the same version currently in 20.04) to the PPA for 19.04, then re-uploaded scribus-ng to get it rebuilt against it.

Please check with version 1.5.5-0ubuntu19.04~ppa1 whether you can still see this bug.
(0047338)
mujeebcpy   
2020-01-17 05:23   
ok. will try. but we use scribus-trunk package. because in 1.5.5 hyphen in charecter style will crash the scribus. is this update comes to 1.5.6 ?
(0047339)
mapreri   
2020-01-17 17:18   
yes, the scribus-trunk 1.5.6~svn packages are automatically built whenever there is a new commit in the trunk branch. When that will happen it will pick up the new poppler, so just wait for that to happen.
(0047346)
mapreri   
2020-01-26 12:26   
AFAIK those packages have been rebuilt too now. Can you confirm whether this bug is fixed or not?
(0047347)
mujeebcpy   
2020-01-27 05:16   
yes. Fixed. Thank you
(0047349)
jghali   
2020-01-27 12:28   
@mapreri, thanks! Resolving then.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16034 [Scribus] Story Editor / Text Frames feature always 2020-01-20 04:53 2020-01-21 14:50
Reporter: Fahad Platform:  
Assigned To: Fahad OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: Yes
Summary: First line indent doesn't work for single line RTL paragraph
Description: Following 0015106, there is one case I missed in last patch which is the indentation in one line only.

I propose a small patch for it.

Tags:
Steps To Reproduce:
Additional Information:
Attached Files: one-line-rtl-indentation (868 bytes) 2020-01-20 04:53
https://bugs.scribus.net/file_download.php?file_id=10842&type=bug
test-intend.sla (16,617 bytes) 2020-01-20 19:31
https://bugs.scribus.net/file_download.php?file_id=10843&type=bug
current.png (288,981 bytes) 2020-01-20 19:31
https://bugs.scribus.net/file_download.php?file_id=10844&type=bug
new.png (380,369 bytes) 2020-01-20 19:31
https://bugs.scribus.net/file_download.php?file_id=10845&type=bug
16034_rtl_first_line_indent_single_line_para.patch (991 bytes) 2020-01-20 21:14
https://bugs.scribus.net/file_download.php?file_id=10846&type=bug
Notes
(0047340)
jghali   
2020-01-20 11:21   
Could you provide a sample document for my reference where this patch makes a difference?
(0047341)
Fahad   
2020-01-20 19:31   
the sample attached, with screenshots of current & new behavior.
(0047342)
jghali   
2020-01-20 21:14   
Thanks. When opening your document, I replaced the DejaVu Sans Book by Arial as I didn't have this font on my system. It then occured to me your patch was incomplete as in my case the first line indent was still not applied to the last paragraph. I had to modify line 2851 of pageitem_textframe.cpp in the same way you did with line 2480.
(0047343)
jghali   
2020-01-20 21:16   
Patch applied with my additional fix!
(0047344)
Fahad   
2020-01-21 02:32   
Thanks. I was hesitated to modify any new cases unless I encountered them.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16033 [Scribus] Color Management major always 2020-01-11 21:32 2020-01-13 13:24
Reporter: Traumflug Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.4.8  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.4.9.svn  
    Target Version:  
Patch: No
Summary: SVG exports wrong colors
Description: Setting an object to a certain color and exporting that to SVG puts colors into the SVG not matching the color set in Scribus.
Tags:
Steps To Reproduce: 1. Open the attached document.
2. Verify color management is turned off.
3. Verify color 'Admiral Blue' is set to RGB 17-52-110
4. Verify the box in the document uses this color.
5. Export the only page in this document to SVG.
6. Open this SVG in a text editor to view the color actually exported.

Expected outcome: color in SVG set to #11346e (17 = 0x11, 52 = 0x34, 110 = 0x6e)

Actual outcome: SVG containing this:
    <path style="fill:#10346e; fill-rule:eveno...
Additional Information:
Attached Files: Bildschirmfoto vom 2020-01-11 22-15-33.png (29,504 bytes) 2020-01-11 21:32
https://bugs.scribus.net/file_download.php?file_id=10839&type=bug
Colorexport.sla (10,401 bytes) 2020-01-11 21:32
https://bugs.scribus.net/file_download.php?file_id=10840&type=bug
Colorexport-Seite001.svg (364 bytes) 2020-01-11 21:32
https://bugs.scribus.net/file_download.php?file_id=10841&type=bug
Notes
(0047331)
jghali   
2020-01-11 23:00   
(Last edited: 2020-01-11 23:04)
This issue is caused by a round-trip error between two Qt functions. It is already fixed in our 1.5.x development branch. I will however push a small workaround to 1.4.9.svn.

(0047334)
Traumflug   
2020-01-13 13:24   
Wow, this is a quick resolution! Thank you very much.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16032 [Scribus] Properties Palette feature N/A 2020-01-10 08:42 2020-01-13 08:24
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Indigo UI+: do not expand / collapse the main panels in the properties palette
Description: when "going" to the properties palette, it's very likely that one will want to reach to the xyz, shape, or colors / line panels.

personally, i might be using multiple times in a row one of the panels, but then the next one is probably one of the others

with the improvements proposed by the Indigo project, it should be possible to reduce the total height of the four panels mentioned above to almost match the height of the shortest one before the optimization.

i suggest that we try to keep those panels as slim as possible and that we keep them always expanded.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: indigo-pp-2020-01-10-compare.png (138,395 bytes) 2020-01-10 08:45
https://bugs.scribus.net/file_download.php?file_id=10836&type=bug
Notes
(0047328)
ale   
2020-01-10 08:45   
here is a screenshot that shows an older xyz (1.5.5svn) and a preview of the indigo xyz and shape panels.

three remarks:

- the xyz panel shown is still a WIP.
- there is still/again the item name on top... maybe you can guess now, why i'd like to move it to the bottom of the properties palette.
- the xyz panels has a few changes asked by craig, but not all of them are in yet.
(0047332)
jfl   
2020-01-12 21:13   
Thanks for your efforts, ale. I'm glad to see this project going further. I do wonder about the width of it all, though. The current palettes take too much space not only vertically, but also horizontally. Anyway, what I see in that screenshot is already be a big improvement.
(0047333)
ale   
2020-01-13 08:24   
the new palettes are optimized for vertical space.
i think that this is the most urgent issue.

in a second step, we can for sure track down the worst offenders that make the palettes too wide and work on them.

if and when the changes get in, it won't be the end of the work on the palettes... but we will have a new starting point for further optimizing them!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16031 [Scribus] User Interface tweak always 2020-01-09 01:04 2020-01-09 17:47
Reporter: ebray187 Platform: x86-64  
Assigned To: jghali OS: Linux  
Priority: normal OS Version: Gentoo  
Status: resolved Product Version: 1.5.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: Wrong color scheme on the side panel of the Story editor
Description: Wrong color scheme on the side panel of the Story editor make it unreadable (white fonts on white background).
Same problem on the text section but there the background color can be easily changed in the background setup menu.
See the attached screenshot.


Tags: story editor
Steps To Reproduce: In KDE global settings, set "Breeze-dark" as global theme.
Open Scribus. Create a text frame and open the story editor.
Additional Information: DE: KDE 5.64.0 / Plasma 5.17.4
WM: KWin
Theme: Breeze-dark
Attached Files: Screenshot_20200108_213503.png (146,718 bytes) 2020-01-09 01:04
https://bugs.scribus.net/file_download.php?file_id=10830&type=bug
emerge-info.txt (5,910 bytes) 2020-01-09 01:04
https://bugs.scribus.net/file_download.php?file_id=10831&type=bug
scribus-1.5.5-storyeditor.patch (425 bytes) 2020-01-09 02:48
https://bugs.scribus.net/file_download.php?file_id=10832&type=bug
16031_storyeditor_sidebar_color.patch (6,057 bytes) 2020-01-09 11:13
https://bugs.scribus.net/file_download.php?file_id=10833&type=bug
scribus-1.5.5-storyeditor_sidebar_color.patch (6,229 bytes) 2020-01-09 16:17
https://bugs.scribus.net/file_download.php?file_id=10834&type=bug
Screenshot_20200109_131202.png (149,459 bytes) 2020-01-09 16:17
https://bugs.scribus.net/file_download.php?file_id=10835&type=bug
Notes
(0047324)
ebray187   
2020-01-09 02:48   
Just a nasty quick fix.
(0047325)
jghali   
2020-01-09 11:13   
Would this patch work for you?
(0047326)
ebray187   
2020-01-09 16:17   
Work like a charm. Thanks!
Attached adjusted patch for Gentoo
(0047327)
jghali   
2020-01-09 17:47   
Committed!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16029 [Scribus] General minor N/A 2020-01-06 16:38 2020-01-08 13:36
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: on linux disable/remove the menu "help > check for updates" and the tab "about > updates"
Description: on linux, if scribus is installed through the package manager, it should be updated through package management commands and scribus should not offer other ways for updating scribus.

at first i wanted to suggest a cmake option to disable or remove those two items.
but currently they seem to be relevant only for the official macos and windows builds: i would suggest that they are opt-in at compile time (that is: only releases and snapshots that are on sourceforge should have it activated; all other builds should probably not).
(for all "other" people compiling scribus, those entries make little sense and might be misleading: what is it supposed to do on a self compiled scribus? currently i have fairly up to date scribus trunk and the dialog says that on scribus.net there is a newer built... no, there isn't any!)

i suggest

- only add the menu entry "help > check for updates" if scribus.net in the official builds on sourceforge.
- disable the content of the "update" tab in the "help > about scribus" by default (and only enable it in the official builds mentioned above).
- once this is done, get feedback from the linux and appimage (and other) maintainers and check if there is a way to provide useful ad hoc information in the "update" tab and maybe allow them to inject it at compile time.

for now i suggest adding:

- DWANT_HELP_UPDATE_MENU
- DWANT_HELP_UPDATE_TAB

with a default to "no".
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047320)
ale   
2020-01-07 09:28   
(Last edited: 2020-01-07 09:28)
mapreri suggests:

Probably, rather than removed it could be reworded to mention to check
with your package provider to see whether there is an update available
from them. Keeping it might be useful information to the user, if
anything.

(0047323)
ale   
2020-01-08 13:36   
currently the content is fetched from the scribus site.

i guess that linux distribution, if they want to show some content, are better served by a static text provided in the package.

personally, i tend to favor a removal of the update information when scribus is installed through a package manager... but i'm fine with an ad hoc message.

currently, i've only seen two users who were puzzled by the update tab, so it does not hurry.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16030 [Scribus] Import / Export minor always 2020-01-07 10:43 2020-01-07 14:21
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: correctly import .ai and / or .pdf templates for a specific online printing service
Description: easyflyer is providing a zip file containing an .ai and a .pdf file to be used as a base for creating flyers.

https://www.easyflyer.fr/flyers/standard/10-x-15-cm-carte-postale/135g/recto/flyer-a6-recto-1000-ex.html

scribus can open both files, but the result is not "good enough" for building the upon them:

- opening the .pdf file gives an exact layout but all information about the layers is lost (and it's not possible to know which items are to be hidden and where the designer should work)
- opening the .ai part of the .ai file gives a file with the correct layers information but we get only one page instead of two and there is no real content shown.
- opening the .pdf fpart of the .ai file gives the right content but completely loses the layers information.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Gabarit-FlyerA6-150x100mm-RectoSeul.zip (583,837 bytes) 2020-01-07 10:43
https://bugs.scribus.net/file_download.php?file_id=10829&type=bug
Notes
(0047321)
jghali   
2020-01-07 13:32   
>> opening the .pdf file gives an exact layout but all information about the layers is lost

There is only one layer which contains importable elements, this is the one which contains the technical instructions.. and whose elements will have to be removed including the layer if you ever want to use this as a template. The "Template" layer contains no elements and is consequently not very useful as a template. You will just be faster creating directly a document with proper page size and bleeds.

>> - opening the .ai part of the .ai file gives a file with the correct layers information but we get only one page instead of two and there is no real content shown.
>> - opening the .pdf fpart of the .ai file gives the right content but completely loses the layers information.

Same, if you want to use this as a template, you will be quicker to create a document directly with correct page size and bleeds. These documents are pretty useless as templates given the additional work they require before being usable.
(0047322)
ale   
2020-01-07 14:21   
i would be faster yes!

but that's not the point.

being able to correctly open the templates provided by such print shops will help the "less technical" user to simply follow the instructions provided on the website.

if it's not possible, that's not a huge issue. but if it's possible and not too cumbersome to correctly import the layer information that would be a huge advantage for the "casual" scribus user that need to create a flyer or a simple brochure.

there are a few print services that provide .sla files, but i fear that they will be a minority for a few more years...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14723 [Scribus] General minor have not tried 2017-04-07 09:02 2020-01-07 12:51
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [PATCH] Add variable for document directory to render-frame processing
Description: on github, filmor is suggesting :

I'd like to include in a Lilypond render-frame a file that is relative to the Scribus document. However, the information about this is apparently not forwarded at all.

I propose adding a variable $scribus_doc_dir$ that would allow me to change the Lilypond call to lilypond --pdf -I$scribus_doc_dir$.

a patch is attached:

https://patch-diff.githubusercontent.com/raw/scribusproject/scribus/pull/86.patch
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scribus-renderframe.patch (606 bytes) 2019-10-07 08:05
https://bugs.scribus.net/file_download.php?file_id=10625&type=bug
Notes
(0043718)
ale   
2017-04-07 09:03   
... maybe with $scribus_doc_path$ instead?
(0043719)
jghali   
2017-04-07 09:33   
Hmmm... that path does not exist until the document is saved. So it looks like it won't work.
(0043721)
ale   
2017-04-07 15:40   
mmmm... i guess that in 99% of the cases the document will be saved before a render frame will be created...

and if it has not been saved yet, you could use the current directory (if any) or the default document path(). or do anything somehow meaningful...
no idea what absolutePath() does in that case...
(0045354)
filmor   
2018-07-25 10:10   
Hey, will this get merged at some point? Should I change anything? I have been using my patched version of Scribus since quite a while, it works fine. I could try to test the case of a new unsaved document.

The use-case is that I want to build my Lilypond files in Frescobaldi and just reference them in Scribus using an `\include` in the render-frame.
(0045355)
filmor   
2018-07-25 10:11   
Also, I disagree with `$scribus_doc_path$`, the path of the document includes the document file name, which I don't care about.
(0045516)
filmor   
2018-10-18 10:53   
Is there anything I can do to help? It's literally a two-line patch that does not interfere with anything that doesn't use the functionality, but forces me to build my own patched Scribus for 1.5 years now, it hasn't even progressed past "new"...
(0045518)
ale   
2018-10-18 15:39   
@filmor, as you read above, jean has concerns about the case where a file is not save yet... do you have an idea how to solve that case?
(0045519)
filmor   
2018-10-18 17:52   
Well, it could indeed just default to `.` or something like this. Would that be enough for you?
(0045522)
ale   
2018-10-20 14:39   
i guess a good solution is required that convinces jean... `.` will be for sure not defined, since the document has not been saved yet and it does not have a path...
(0045528)
Luna Nightshade   
2018-10-21 18:24   
What about having it point to the temp directory until it is saved? Which would be the default behavior for scribus until the patch is implemented.
(0046751)
filmor   
2019-10-07 08:05   
This is a new version of the patch that checks whether the file has been saved before and applies against current master.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16026 [Scribus] General feature always 2020-01-03 00:33 2020-01-04 19:41
Reporter: johnxj Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Toolbars do not minimize when Scribus 1.5.6svn is minimized to taskbar
Description: This is Scribus 1.5.6svn from the PPA on Xubuntu 18.04 up to date. Computer has UHD (3840x2160) display. While setting it up with Preferences and no document opened I discovered two short toolbars that I did not want displayed. Sorry, I don't know what they are called; one start with an icon to open a new document and the other starts with an icon to undo.
Tags: desktop, toolbars
Steps To Reproduce: If you drag them off from the top dock and leave them floating, but then minimize Scribus to the desktop taskbar they remain on the desktop. Then if you open another application window (e.g., Chromium web browser), the toolbars remain on top of the Chromium window.

If you dock them, when you minimize Scribus to the taskbar the toolbars will then minimize with the Scribus window as they should. The problem exists only when they are floating. And all the other toolbars minimize properly, even when floating.
Additional Information: Also, there seems to be no way to completely stop these toolbars from being visible. But that may be a PEBKAC issue.
Attached Files:
Notes
(0047317)
ale   
2020-01-04 14:05   
this seems to be a qt issue on linux... and it might or not have a workaround.

the following post and ticket might be related

https://stackoverflow.com/questions/57743803/problem-in-restoring-floating-toolbar-for-qmainwindow
https://bugreports.qt.io/browse/QTBUG-78293

personally, i'm wondering if the use cases for having floating toolbars are important enough to justify the implementation of a workaround.
(of course, if there is a bug, it should be fixed... but i'm not sure that it in this case it's worth hacking around qt's issues)
(0047318)
johnxj   
2020-01-04 19:41   
First, my version of QT:
qmake --version
QMake version 2.01a
Using Qt version 4.8.7 in /usr/lib/x86_64-linux-gnu

As for the links above, my issue does not involve focus. When I minimized Scribus these two toolbars did not minimize, but all other toolbars did minimize. When I restored Scribus these two toolbars still had focus without having to click on them.

But now I have happy news: The problem has disappeared! The two toolbars that did not minimize if they were floating now suddenly do minimize! I have made no changes to the system or to Scribus, but I see that Scribus-trunk has been updated five hours ago. I closed Scribus about 12 hours ago, and just now re-launched it, so maybe the updates got applied. I can't find any documentation about how the updates are applied or how I can tell if an update has been applied. All I can say is that the problem is resolved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15982 [Scribus] Internal minor always 2019-12-02 10:45 2020-01-04 13:10
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: Yes
Summary: Remove #elif-ed code that cannot compile in scfonts.cpp
Description: this branch

https://gitlab.com/scribus/scribus/blob/master/scribus/scfonts.cpp#L1193

cannot compile

pos2 = paths.find("\n",pos+1);

QString does not seem to have a find() function.

.... and i don't think that we can have a linux build without fontconfig...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scfonts-no-linux-without-fontconfig.diff (2,531 bytes) 2019-12-10 10:10
https://bugs.scribus.net/file_download.php?file_id=10804&type=bug
Notes
(0047189)
ale   
2019-12-02 10:49   
the same #elif in can also probably be removed in scfonts.h
(0047224)
ale   
2019-12-09 08:15   
the "dead branch" is because it's an elif to "if fontconfig"... and i don't think it's possible to have a linux system without fontconfig.
(0047237)
ale   
2019-12-10 10:10   
(Last edited: 2019-12-10 10:10)
here is the patch



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16027 [Scribus] Translation text always 2020-01-03 04:42 2020-01-03 12:58
Reporter: yichuang Platform: linux  
Assigned To: jghali OS: Debian Stretch  
Priority: none OS Version: 9.11  
Status: resolved Product Version: 1.5.5.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: There are some non-English words in English version of Scribus Help
Description: When I view Help > Scribus Manual > Scripts Included With Scribus, there are some words not in English.

Tags: document, help
Steps To Reproduce: Help > Scribus Manual > Scripts Included With Scribus
Additional Information:
Attached Files: helpGuideEn.png (146,922 bytes) 2020-01-03 04:42
https://bugs.scribus.net/file_download.php?file_id=10828&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16028 [Scribus] Shape Drawing feature N/A 2020-01-03 08:27 2020-01-03 08:27
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: make the shape selection non sticky
Description: the shape to be added should always be the rectangle.
picking a different form should only uses it once.

if we really want to allow a different "default" shape, it should be set in the preferences or the settings.
or we could add a setting to make the choice sticky... but i'm not sure that it's really needed. (i would rather put the effort in improving fast duplication...)

currently, i avoid using the drop down: picking a different shape in the "shape" section of the properties palette is faster than setting back the shape to rectangle once done.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16024 [Scribus] General minor always 2020-01-01 14:30 2020-01-01 14:30
Reporter: zerubbabel Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Footnote formatting lost after save and reopen
Description: I like to have my footnotes streaming together rather than on separate lines, which seems to work fine. I can delete the line break between footnotes and they follow one after the other just fine. The problem is that after I close the file and later reopen it, the footnotes revert to being on separate lines. It is tedious to reformat them each time.
Tags: footnotes
Steps To Reproduce: Just insert several footnotes in a document and try what I described above.
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15472 [Scribus] User Interface major always 2018-11-03 19:58 2019-12-31 15:34
Reporter: hawson Platform: Arch Linux  
Assigned To: OS: Linux  
Priority: normal OS Version:  
Status: new Product Version: 1.5.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [ON HOLD] Shortcuts with modifiers do not work
Description: All shortcuts that require a modifier such as ctrl- or alt- do not work. Thus, common actions such as copy (ctrl-c) and paste (ctrl-v) and save (ctrl-s) do not work from their shortcut keys. Single key shortcuts work fine. All actions work fine from drop down menus, toolbars, etc. This appears to be related only to how the keystrokes are interpreted.

Attempts to re-map the shortcuts show that the control key is being interpreted as "Meta".

I downgraded to Scribus 1.4.7, and shortcuts work fine (version 1.4.7 also required downgrading libidn and podofo minor versions as well, but those seem unlikely to be culprits).
Tags: shortcuts
Steps To Reproduce: 1. Open a new document
2. Create an element
3. Try to copy/paste the element using ctrl-c/ctrl-v
Additional Information: This seems similar to task 15436, although there seems to be no correlation with opening the preferences dialog box: the shortcuts never work.
Attached Files:
Notes
(0045568)
jghali   
2018-11-03 21:07   
Unable to reproduce on Windows.
(0045569)
hawson   
2018-11-03 21:31   
> Unable to reproduce on Windows.

Not surprising.

Two other datapoints:
1. under 1.4.7 (where shortcuts *do* work), attempting to reset a shortcut shows some odd characters. (See attached). Prior to this, it displayed as "Ctrl-S" as normal. Under 1.5.4, trying to remap reports "META" (not Ctrl or SUPER).
2. The laptop in question is technically a Chromebook, although it has a full Linux install on it. This is relevant only in that the key I'm using has been remapped to "control" instead of the original "search" function. I think that this is interpreted as a "SUPER" key, as opposed to CTRL, ALT, or something else.

From the 'xev' tool, here are two scankey events: one when the search/SUPER key is pressed, and one when released:

KeyPress event, serial 37, synthetic NO, window 0x5600001,
    root 0x10f, subw 0x0, time 182196939, (30,103), root:(624,426),
    state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 37, synthetic NO, window 0x5600001,
    root 0x10f, subw 0x0, time 182197058, (30,103), root:(624,426),
    state 0x4, keycode 133 (keysym 0xffeb, Super_L), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False
(0045570)
ale   
2018-11-04 11:05   
... unable to reproduce on debian testing with a somehow recent development code...
(0045571)
PeterBenedek   
2018-11-04 15:16   
Unable to reproduce on Linux Mint 19.
(0045572)
hawson   
2018-11-04 15:33   
Could the window manager have anything to do with it? I'm running XFCE 4.12, but I don't think I have any particular settings that would interfere.
(0045573)
hawson   
2018-11-04 15:43   
Here's the ~/.Xmodmap file, in case it's relevant:

<---snip--->
$ cat .Xmodmap
clear control
clear mod4
keycode 133 = Super_L
keycode 37 = Control_L
add control = Control_R Super_L
add mod4 = Control_L Hyper_L Super_R

keycode 74 = XF86AudioMute F8 F8 F8 F8 F8 XF86Switch_VT_8 F8 F8 XF86Switch_VT_8
keycode 75 = XF86AudioLowerVolume F9 F9 F9 F9 F9 XF86Switch_VT_9 F9 F9 XF86Switch_VT_9
keycode 76 = XF86AudioRaiseVolume F10 F10 F10 F10 F10 XF86Switch_VT_10 F10 F10 XF86Switch_VT_10
<---snip--->
(0045634)
hawson   
2018-11-17 19:06   
I tried a different window manager (TWM), in case that was getting in the way of things: no change. Shortcuts still don't work.
(0045645)
hawson   
2018-11-19 13:03   
Built scribus from source (r22773), but there's still no change in behavior: ctrl/alt shortcuts are not registered.
(0045646)
ale   
2018-11-19 13:56   
you might want to try to remove all your customization (like the Xmodmap file) and see if then scribus works correctly for you.

when you get to a working state, then add each customization back, once at a time, until oyu find out which one is giving you headaches...
(0046486)
ale   
2019-08-19 12:29   
please test with 1.5.

if you cannot reproduce with 1.5 i think we can close this ticket.
(0047312)
hawson   
2019-12-30 17:41   
This problem still occurs in 1.5.5 (tested this morning).
(0047314)
ale   
2019-12-31 15:34   
so, generally speaking the shortcuts do work.
in your case shortcuts do not work in scribus but work in other applications.

i tried to do an internet search for "chromebook qt shortcuts" or "chromebook qt keyboard" but i could not find anything relevant.
nonetheless, i tend to think that it's a chromebook related issue...

hard to say what is happening on your computer and since nobody else commented in this ticket it seems to be something that is specific to your setup...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15342 [Scribus] General minor sometimes 2018-05-28 16:11 2019-12-31 14:42
Reporter: enzogian Platform: Windows  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: undo command is not working
Description: this happens for everything I do out of the text editor.. I mean, any change I apply to an object via properties in the tool palette cannot be undo via keyboard *only is possible via menu but not from the command keyboard control z
Tags:
Steps To Reproduce: draw a box and change its line color or thickness and try to undo the operation from the keyboard.. it does not obey.. you have to do it only from the edit menu ...
Additional Information:
Attached Files:
Notes
(0045280)
enzogian   
2018-05-28 16:14   
sorry I need to clarify this is happening randomly only in some of the features.. for example scaling an object then it can not be undo...
the line color was not the best example to test as it does well..
as I said is quite hard to determine exactly when happens but the scaling image is one example *scaling from the properties palette then try to undo the last action or values applied and it does undo..
(0045283)
ale   
2018-05-29 08:47   
this works for me

- create text frame and fill it
- create an image frame and load an image into it
- type some text in the text frame
- set the image to free scale
- scale it down a bit

ctrl-z to undo multiple times:

- the image is scaled up step by step
- the text gets undone in chunks

that works for me...
(0045284)
ale   
2018-05-29 08:52   
- create the two frames and set the image frame to freescale
- fill some text
- set the image frame to autoscale
- type some text

ctrl-z does undo step by step, as expected...

@enzogian , can you give a list of steps that show the issue?


p.s.: please check https://bugs.scribus.net/view.php?id=15309 ... you should probably desable the item action mode...
(0047311)
hawson   
2019-12-30 17:40   
This affects me as well with version 1.5.5-4 (Arch Linux build from 2019-11-12).

To reproduce:
1. Create a new document.
2. Create a text box.
3. Double-click on text box.
4. Type some text ("hello world")
5. Press ctrl-z to undo typing.

This fails.

If I use the menu option: Edit > Undo, it works as expected.

I'll go on to say that *none* of the control-key based accelerators work (ctrl-c, ctrl-n, ctrl-s, etc). Other accelerators that do not need a ctrl- mapping (e.g. F4 for styles, "T" for textframe, etc) do work.

No other programs have this problem (Firefox, various gui editors, LibreOffice, et al).

Scribus version 1.4.7 does not have this problem.
(0047313)
ale   
2019-12-31 14:42   
@hawson as you are stating in 0015472 you seem to have a problem with your control based keyboard shortcuts..
your step above do work for me.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16020 [Scribus] OS-MacOSX block always 2019-12-19 11:25 2019-12-30 15:13
Reporter: ramuntcho Platform: macos  
Assigned To: OS: mac  
Priority: high OS Version: 10.15  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: If you switch to french language, preferences are no more available
Description: In the Preferences of Scribus, you can switch to French. If you do, the window for modifying the preferences is no more available.
Tags:
Steps To Reproduce: Open Scribus
Create a new document
In menu Scribus, choose Preferences
Change in the window to have the interface in French (or spanish)
Qui Scribus
Launch Scribus
Go to the menu Scribus and choose the line Preferences... nothing happens, the Preferences window doesn't appear anymore
Additional Information:
Attached Files: French.png (210,581 bytes) 2019-12-19 11:25
https://bugs.scribus.net/file_download.php?file_id=10819&type=bug
Capture d'écran 2019-12-30 15.56.34.png (17,887 bytes) 2019-12-30 15:13
https://bugs.scribus.net/file_download.php?file_id=10823&type=bug
Crashlog Scribus.txt.zip (217,799 bytes) 2019-12-30 15:13
https://bugs.scribus.net/file_download.php?file_id=10824&type=bug
Notes
(0047299)
ale   
2019-12-19 20:24   
... until december 22nd, after switching to french, you need to check if the menu entry is marked as suppressed, before starting scribus...

:-)

... in the meantime you can try and see if cmd-, opens the preferences...

if you want your preferences back, you can also remove the preferences file. if you want to go this way, i can look for the instructions for mac... i don't know them by heart...
(0047306)
ramuntcho   
2019-12-26 17:36   
Hi,

In fact, in english there isn't any submenu like in french (with Annotation PDF, Signet PDF...). When you choose French for the first time, and don't close Scribus, menus are in French and there is no submenus to the line Preferences... but nothing happens. When you close and open Scribus, the submenus appear. Shortcut to open Preferences isn't working.

We wanted to use Scribus with french children on macOS Catalina, so it would be better to have a french version.
:-))

PS Why "until december 22nd " ?
(0047309)
ale   
2019-12-27 12:32   
the 22nd december was a pun on the ongoing strike in france... sorry.

i've tried to see in the code if i see a reason why the menu is wrongly wired in french, but i could not find any.

since i don't have a mac computer at hand, i cannot test it.
on linux i have a "normal" préférences dialog

that "Scribus" menu is a mac specific thing, so there might be an issue that is only visible on a mac...

can you try to download the latest 1.5.6svn snapshot and see if you have the issue there too?
(0047310)
ramuntcho   
2019-12-30 15:13   
Hi,

I have made several tests with 1.5.6 svn, same bug.
But i have also try some other languages :
- no problem with hungarian, deutsch, portuguese, swedish
- problem with french, spanish, catalan, italian

In fact, when you choose one of the language of the second group, Scribus freezes and you have to do a force-quit. Sometimes, there is this window which appears. I have also joined the crashlog.

So there's something in common with these languages...

:-))


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15381 [Scribus] PDF major always 2018-07-18 12:25 2019-12-28 21:39
Reporter: Miadim Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.4  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: PDF Import displays non uniform letters
Description: When I import PDf from Vectorial File, it displays non uniform letters meanwhile they are perfect in the source file (see linked files) which is not good for publishing.
Tags: PDF
Steps To Reproduce:
Additional Information:
Attached Files: Scribus_SourceFile.PNG (75,452 bytes) 2018-07-18 12:25
https://bugs.scribus.net/file_download.php?file_id=10196&type=bug
Scribus_Bug.PNG (128,022 bytes) 2018-07-18 12:25
https://bugs.scribus.net/file_download.php?file_id=10197&type=bug
Scribus_SampleFile.pdf (54,979 bytes) 2018-07-18 12:40
https://bugs.scribus.net/file_download.php?file_id=10198&type=bug
Notes
(0045352)
jghali   
2018-07-18 12:31   
Please provide sample file.
(0045353)
Miadim   
2018-07-18 12:40   
Here is the file I used.
The Scribus file is a default new one, not even saved.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16003 [Scribus] Scripter minor N/A 2019-12-10 09:44 2019-12-28 21:35
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: Yes
Summary: Scripter: rename traceText() to outlineText()
Description: ... and deprecate traceText()...

(i like traceText(), but matching the UI will help with the discoverability...)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scripter-text-to-outlines.diff (3,574 bytes) 2019-12-10 14:08
https://bugs.scribus.net/file_download.php?file_id=10806&type=bug
Notes
(0047242)
cbradney   
2019-12-10 22:18   
What do we need to do to keep backwards compatibiility? or don't we care?

Add this?

{const_cast<char*>("traceText"), scribus_texttooutlines, METH_VARARGS, tr(scribus_texttooutlines__doc__)},

?
(0047245)
ale   
2019-12-11 09:09   
if i did not do an error while preparing the patch, the diff above should maintain the backward compatibility.
but adds a path for deprecating the "old" command.

in this case, i don't think that backwards compatibility is important.

this is not a common command and i don't think that there is any script that is published to the public that uses this feature.
for "private" scripts, it should be easy to make the change.
(0047305)
jghali   
2019-12-26 03:27   
I'd prefer that we keep naming scripter functions with verb + action, so something like convertToOutlines or outlineText. Make your choice!
(0047307)
ale   
2019-12-27 11:58   
i don't care about the name, as long as it's easy to find the command if you look for what is in the corresponding menu.

as long as we don't have an "object oriented" scripter, outlineText() might be slightly better...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16022 [Scribus] User Interface minor always 2019-12-28 05:51 2019-12-28 05:51
Reporter: jdb Platform: Linux  
Assigned To: OS: Arch Linux  
Priority: normal OS Version:  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Changing icon set require restart of Scribus
Description: Changing the icon set type requires a restart of Scribus.

Expected behaviour would be to have the icons change without requiring a restart, or prompt the user that a restart is required.
Tags:
Steps To Reproduce: 1. Change icon set in preferences
2. Hit apply
Additional Information: Bug 0015753 refers to this problem. While it isn't necessarily a bug as it works as expected after restart, it otherwise gives the user the impression that the feature does not work at all.

The user experience for those using a dark theme, which Scribus will inherit by default on some platforms, is lacking as *most* of the icons in the toolbar are barely visible.
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11402 [Scribus] Usability minor always 2013-01-27 22:03 2019-12-27 11:59
Reporter: JLuc Platform: ubuntu 12.04  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: search and replace: replace font is very slow
Description: Using the Search and Replace dialog it is possible to change all occurences of a specific font with another one.
(only checking 'font' both in the search and replace column).
This is very handy when working on a bit of document that doesnt use styles.

Problem is : the operation takes a very (very) long time, and there is no progress bar so it's easy to believe that scribus is hanged.

Maybe some impressive efficiency improvement can be reached somehow in optimizing the code ?
That would be the best.

Maybe a progress bar could be shown or anything that would show that scribus is making progresses. Like the number of characters searched and the number of occurences found.


Tags: search
Steps To Reproduce:
Additional Information: 1.4 and 1.5svn
Attached Files:
Notes
(0044562)
PeterBenedek   
2017-10-22 16:05   
Tested in r22196; Linux Mint 18

I can reproduce.

Remark:
-- Open new document
-- Make TextFrame
-- Insert any text in TextFrame (Content - Sample Text... - Paragraphs: 60)
-- Edit - Search/Replace... - Search for: Text (for example: e --> E)
Result: The operation lasts for a moment.

BUT

-- Open new document
-- Make TextFrame
-- Insert any text in TextFrame (Content - Sample Text... - Paragraphs: 60)
-- Edit Texth With Story Editor
-- You use the Search/Replace... Search for: Text (for example: e --> E)
Result: The operation takes a very long time.
(0047301)
ale   
2019-12-20 17:33   
0014567 introduces a "stop" button.

if the review phase takes too long, i might also add a counting of the occurrences found.

a big question:

- i cannot add a normal progress bar since i don't know how many occurrences there will be in total.
- as far as i can tell, it's slow when replacing lot of small things. in that case i can't count 1 by 1 nor 10 by 10... can somebody make tests with slow use cases and tell me how often i should update the number of occurrences?
- where should i show it? in the same line where it says "No occurrences"?
(0047308)
ale   
2019-12-27 11:59   
counting the occurrences is now in.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16021 [Scribus] General minor N/A 2019-12-23 11:06 2019-12-26 04:42
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: Yes
Summary: Open recent menu: put the accelerator on the number
Description: currently the accelerator is put at the beginning of the path, which will always be / on linux and C (or D) on windows.

the patch puts the accelerator before the indexing number...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: recent-files.diff (1,004 bytes) 2019-12-23 11:06
https://bugs.scribus.net/file_download.php?file_id=10821&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15753 [Scribus] OS-MacOSX minor always 2019-08-03 14:27 2019-12-23 11:20
Reporter: utnik Platform: macintosh  
Assigned To: OS: osx  
Priority: normal OS Version: 10.14.5  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: icons and palette entries are invisible under the dark theme of macOS
Description: scribus icons and lots of the palette entries are invisible when running under the dark theme of macOS. (see screenshots)
the problem is new in 1.5.5, as scribus versions up to 1.5.4 didn't use the dark theme of the os.
Tags:
Steps To Reproduce: select the 'dark' theme in the 'general' tab of the 'system properties'.
open scribus. (or switch to scribus if it is already running…)
Additional Information:
Attached Files: scrshot_scribus1.5.5_dark.png (730,407 bytes) 2019-08-03 14:27
https://bugs.scribus.net/file_download.php?file_id=10545&type=bug
scrshot_scribus1.5.5_light.png (749,184 bytes) 2019-08-03 14:27
https://bugs.scribus.net/file_download.php?file_id=10546&type=bug
Scribus 1.5.5 dark on macOS.png (1,462,187 bytes) 2019-12-23 11:20
https://bugs.scribus.net/file_download.php?file_id=10822&type=bug
Notes
(0046435)
Luna Nightshade   
2019-08-06 04:21   
Try go to File -> Preferences, then under User Interface (topmost entry) set the Icon set manually to Scribus 1.5.1 Dark as a Workaround.
(0046436)
utnik   
2019-08-06 07:40   
i've tried all options there. even 'scribus 1.5.1 dark' is invisible.
(0046438)
cbradney   
2019-08-06 20:05   
No issues here at all from the 1.5.5 dmg, nor from 1.5.6.svn
(0046439)
cbradney   
2019-08-06 20:21   
btw did you use the 10.13 dmg or the 10.14 one?
(0046444)
utnik   
2019-08-06 22:24   
i use the 10.14 dmg under macOS 10.14.5 – but i wasn't aware of a 1.5.6 version so far. is there a compiled version for macOS?
(0046445)
utnik   
2019-08-06 23:52   
after updating to macOS 10.14.6 the icons and the numeric entry fields are ok with the dark theme.
the location of the basepoint in 'properties' → 'x, y, z' is still not visible.
(0047303)
Colin Whyles   
2019-12-23 11:06   
On macos 10.15.2 I find Scribus 1.5.5 impossible to use. As stated, icons and palettes are invisible and trying to select objects to group them seems impossible or random. I cannot even switch tabs between properties, alignment and text propterties.

I have reverted to 1.5.4, which is fine.

I am using the latest 16" Macbook Pro with 64Gb RAM, Intel UHD Graphics 630 1536 MB, 8Tb SSD. Scribus flies in it, but not 1.5.5.
(0047304)
Colin Whyles   
2019-12-23 11:20   
I just tried again with a simple, one-page document, and although I cannot see the icons, regardless of which icon set I choose, they do seem to work now.

I then closed Scribus, and opened it again with a much more complicated (music) document and I can see the icons and selection seems fine. Very odd.

I wonder if it is necessary to close and reopen after changing the icon set? As you can see, I switched to Macintosh, Scribus 1.51 dark.

It doesn't account for why I was having difficulty selecting items last night. That is a different problem though that I will report separately if necessary.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16015 [Scribus] General minor N/A 2019-12-17 10:03 2019-12-20 17:34
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: How to add undo to SearchReplace::doReplace() / StoryText::replaceSelection()?
Description: while applying the formatting uses ScribusDoc functions that implement the undo steps, replacing text goes directly to the StoryText and both text/storytext.cpp and ui/search.cpp do not have (yet) any undo related code.

if i want to add support for undoing the text replacement, should i add a function

ScribusDoc::itemSelection_ReplaceText(const QString& newText, Selection* customSelection)

?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047302)
ale   
2019-12-20 17:34   
a reply to this is still pending...
the current code does not contain the undo for text replacement, so if it's not in 0014567 it's not a regression... but it would be nice to have in there...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14567 [Scribus] Story Editor / Text Frames feature always 2017-01-18 11:07 2019-12-20 17:28
Reporter: Fahad Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Search \ replace all text frames
Description: The scenario:
I am designing a book that has more than 50 text frames and then I discover spelling error in one word or I want to replace it with another word. It is very boring to select all 50 text frames one by one and open Search\replace and write the word and its replacement.


Search \ replace dialog should work on all text frames by default.
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files: searchAll.patch (12,916 bytes) 2018-01-18 08:18
https://bugs.scribus.net/file_download.php?file_id=9934&type=bug
search-and-replace.epgz (19,627 bytes) 2018-03-17 13:15
https://bugs.scribus.net/file_download.php?file_id=10009&type=bug
search-and-replace.png (52,978 bytes) 2018-03-17 13:17
https://bugs.scribus.net/file_download.php?file_id=10011&type=bug
search-and-replace.diff (121,047 bytes) 2019-12-20 13:29
https://bugs.scribus.net/file_download.php?file_id=10820&type=bug
Notes
(0044857)
Fahad   
2018-01-18 08:18   
Here is a patch will implement this feature. The work is done by @Majda.

The current status now:
- every thing is working fine, you can search and replace into all text frames.
- the logic behind search for all text frames is explained as follow:
 The search algorithm is to start from selected text frame, if there is no
text frame selected select the first text frame in the current page, if
not, find the first text frame from next pages, if reaching the end of
the document start searching from the first page.

Enhancement may be added in the future:
 - make search and replace dialog is modeless, so you can search and interact with text directly.
(0044860)
PeterBenedek   
2018-01-19 17:05   
This is excellent feature. :-)
(0045046)
Fahad   
2018-03-17 06:41   
Does anybody test the patch? any feedback?
(0045047)
ale   
2018-03-17 13:15   
hi fahad,
do you also have a git branch?
that could help for testing...

personally, i'm not too hot in spending time on the search and replace because
a/ i don't use it much in scribus (i wonder if i have ever needed)
b/ the dialog is overwhelming
c/ important features are missing (your patch will introduce one of those features).

if @majda is still working on the search and replace, i'd like to propose a refactoring of the search and dialog... mostly based on the dialog from libreoffice. i attach a png and the "pencil" file.
(0045048)
ale   
2018-03-17 13:17   
... and the png...
(0045050)
ale   
2018-03-17 13:18   
in the mockup above, if you choose a formatting, it's shown as a text below the search or replace box (as it is done in libreoffice)
(0045051)
ale   
2018-03-17 14:34   
i can do some more work on the mockup if
- somebody likes it
- somebody wants to work on it
(0045053)
Fahad   
2018-03-18 03:54   
Hi @ale, Unfortunately Majda has finished her internship and I am here to finish her work if needed. Refactoring of the search and dialog is good but out of my scope here. Let's first test the functionality and see if it works as expected.
(0045073)
Fahad   
2018-03-22 08:09   
Hi @ale, I have setup HOST repository again and I applied the patch for testing. The repository here

https://github.com/HOST-Oman/scribus
(0045247)
ale   
2018-05-15 13:38   
@fahad

i've finally tested. it looks neat!

i've found one small issue: if i click "replace all", it tells me that it has reached the end of the document and if it should start from the beginning.
this is a bit odd.
i would expect to simply replace all occurrences.
if you click on "yes", it will ask you again the same question.
not a huge things, but i really do not expect it...

personally, i would expect it to do a one pass replacement.
as an example replacing "text" in "tetextxt" should leave "text" when finished with replacing with the replacing all.

all in all: the simple example i've tested did work.
(0047204)
Fahad   
2019-12-05 18:00   
@jghali could you please have a look to this bug since you fixed 0011369?
(0047206)
ale   
2019-12-06 13:13   
i'm working on a new version of the patch that applies to the current code...
(0047268)
ale   
2019-12-14 09:09   
it's taking some time, but i'm progressing...
(0047300)
ale   
2019-12-20 13:29   
(Last edited: 2019-12-20 17:28)
voilà:

https://gitlab.com/scribus/scribus/merge_requests/21
https://gitlab.com/a.l.e/scribus/-/jobs/385792805/artifacts/file/Scribus-nightly-x86_64.AppImage (for the next week)

some comments:

- this is a complete rework of the search and replace dialog.
- the main goal was to allow search and replace to act on one multiple items (the current selection, the whole document).
- during the rewrite i've fixed several bugs and implemented a few feature requests. often following suggestions in tickets here in mantis.
- there is now a .ui file and several other features will now be much easier to implement: i've opened a request at opensourcedesign, asking a ui/ux expert to work on it. this will take some time: further improvements are to be expected AFTER this patch has been reviewed / accepted.

if possible, please review this patch on gitlab and leave there (or here) comments on what i should change and -- at the end of the process -- commit the merge request as is.
i'd like to continue my work on this feature and it's important that i know how the code works AND learn from the errors i did.

in the merge request, i've added a list of known issues (the patch can probably be committed without fixing them... but it would be nice to get them fixed before the code is in scribus).

p.s.: there are chances that with the time the version on gitlab will diverge from the patch posted here (actually, it's already different...)



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16017 [Scribus] User Interface minor always 2019-12-17 20:42 2019-12-18 15:58
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Magenta is displayed as black and grey
Description: In style edit dialog, magenta color is displayed as black and grey in character-style's dialog's color choice part.
See screenshot 1
It should be displayed magenta as it is displayed in color-edit dialog : as magenta.
See screenshot 2.

Other colors are also displayed black and grey in character-style dialog's color choice part.

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files: 2. color edit dialog.png (3,296 bytes) 2019-12-17 20:42
https://bugs.scribus.net/file_download.php?file_id=10815&type=bug
1. character style color edit.png (3,513 bytes) 2019-12-17 20:42
https://bugs.scribus.net/file_download.php?file_id=10816&type=bug
Notes
(0047292)
jghali   
2019-12-18 01:18   
Not sure what your are talking about... Are you talking about the shade icon which is on the left of the shade value?
(0047297)
JLuc   
2019-12-18 12:31   
All icons are black and grey : both left and right. And so is the text and all backgrounds. See uploaded picture.

Color edit screen capture displays something coherent : my eye sees a magenta square and the text also reads "magenta". Good, nice, easy to grasp because the color itself is a good way to "label" a color for people working on colors.
(0047298)
ale   
2019-12-18 15:58   
@JLuc i think that if you have a look at the indigo proposal you will find there what you will like more...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16019 [Scribus] Usability feature always 2019-12-18 14:28 2019-12-18 14:28
Reporter: utnik Platform: all  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: text flow – don't scale the offset of a contour line when scaling an object
Description: when scaling an object with an extended contour line scribus scales the offset of the contour line with the object.
in the real page layout work the offset should be kept nominally instead of percentually. (as 3mm or 1/8" instead of 6%)

this should be easy to realize for rectangles.
for free forms there may be no better way than to keep it proportionnal without kompletely rethinking the whole task.

the best (most user friendly) way would be to define a 'real' offset from the contour line (or a clipping path) instead of moving the contour line.
this would work for rectangles and free forms. the contour line would be scaled with the image and the text flow could be kept at a distance (i.e. 3mm or 1/8") from this line.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16016 [Scribus] Usability minor always 2019-12-17 14:52 2019-12-18 10:24
Reporter: PeterBenedek Platform: x64  
Assigned To: OS: Linux Mint  
Priority: none OS Version: 19 (64bit)  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Current zoom level field loses the focus, after you manually enter a value and pressed the enter button
Description: -- You write a value in the curret zoom field and press enter button
Scribus settings the page zoom
-- Try modified the value of field and press enter button
Oops...
The value is highlighted but cannot be changed, field lost it the focus.
Tags:
Steps To Reproduce:
Additional Information:
System Description Scribus 1.5.x
Attached Files: zoom_field_loses_focus.jpg (4,102 bytes) 2019-12-17 14:52
https://bugs.scribus.net/file_download.php?file_id=10814&type=bug
statusbar.png (12,865 bytes) 2019-12-18 09:08
https://bugs.scribus.net/file_download.php?file_id=10817&type=bug
Xnview_zoom_field.gif (809,596 bytes) 2019-12-18 09:57
https://bugs.scribus.net/file_download.php?file_id=10818&type=bug
Notes
(0047289)
jghali   
2019-12-17 17:46   
Unable to reproduce.
(0047290)
PeterBenedek   
2019-12-17 18:45   
Sorry, I try again step by step...

-- Click on the zoom field
-- Change value for 50% (or any) and press enter button
Result: Scribus settings the page zoom. That's okay
-- Do not click again on the field, only write: 40 % (or any)
 The value is highlighted but cannot be changed, because field lost it the focus.

Isn't reproducible in this case?

If I want to change one after another it several times the zoom, always I have to click in the zoom field.
(0047293)
ale   
2019-12-18 09:06   
... this is one of the things i don't like in scribus: there are at least eight ways to change the zoom level and none of them works really well.

but asking to remove things will hurt the "we don't remove anything" wall.

- we don't have the manpower for maintaining all the different ways of doing each thing,
- the complexity in the code, makes the onboarding of new contributors harder (even for simple tasks!)

in the case of the zoom i would really like to have

- a fast (shortcuts based) workflow (probably mousewheel and +/-/1,0 based)
- a slow (dialog based) workflow (with a new non modal and dockable dialog that can be called directly from the view menu, not from a sub menu)

of course, it's nice to see the zoom level in the toolbar, but, what i really care about is: do i see the details or overview i need.

 and:

- i want to a fast keyboard based way to switch among overviews / details and
- a discoverable, comfortable but slow way for those who do not need speed.

two ways, not eight!

personally, i would welcome it, if scribus could lose some flexibility and -- as a counterpart we could get carefully shaped tools; with one version for the beginners and one for the "pros".

it is possible that some people will not like the way scribus does it, but , at least, the people who like it and actually are using scribus will get tools that are powerful and comfortable to use.

not half baked solution that try to please everyone but mostly fail in the small but important details.

yes, i'm really convinced that if the zoom tool and the zoom widget in the status bar would disappear tomorrow, the users will not lose any real feature (of course, some people would need to change the way theur workflow).
adding a dockable zoom palette would probably empower those users that formerly were using the zoom in the status bar.

personally, i would love a status bar that looks like this:



                                                                                                                            � 100% � 1 ≣ Background ⌖ -47.150, 142.567 mm � ▮▮▮▮▯▯▯▯▯▯

- all right aligned (more place for tips and feebdack on the left)
- the icons would open a non modal dockable palette (zoom, page navigation / creation, layers, units picker)
- except the eye icon which would enable disable a new preview mode that allows editing
- all the values would be read only.
- the progress bar should be removed when no status is being displayed.
- i'm not sure that the mouse coordinates belong down there (i do use them, but every time i do so, it feels so painful...)

this proposal would probably be rather easy to program and this bug would "automagically" be solved ��.
forever.
</rant>

getting back on topic: i can replicate the bug...
(0047294)
ale   
2019-12-18 09:08   
ok, this version of mantis does not like unicode (or emojis) ... here is a screenshot or my carefully shaped artwork...
(0047295)
PeterBenedek   
2019-12-18 09:57   
I checked in Xnview same function and this behaves exemplarily.

What I did:
-- Click on zoom box and select the contetnt
-- Change the value
-- Press enter button
Application sets the zoom value, the zoom box will remain active and accept the new value.
-- Press up/down arrow button
Application sets the zoom value, the zoom box will remain active and accept the new value.

This is great.
(0047296)
ale   
2019-12-18 10:24   
peter, can you ask some xnview programmer to fix this bug in scribus?

no?

that's the problem i was talking about: we don't have the manpower to maintain 8+ ways of setting the zoom.
and each minute we spend on fixing such a bug cannot be used for more important things.
just commenting / reading this is stealing developers time.
i should just shut up.

and, really, scribus offers better ways of zooming than the spinbox in the status bar. fortunately!
(and, no, a feature that is sane in a picture preview application must not be the best way of doing in a DTP program. it can be. but it most not.)

i stick to my point of view: scribus should learn to do things well. and if we cannot do it well in 8 ways, then we should reduce the number of ways we can do it. and improve (to perfection) the remaining few ways. even if some people lose their preferred way of doing. but they get well behaving tools!

jean will probably fix this bug. i'm pretty sure. and what i wrote above makes it even more likely.
but i would prefer that he would put his time into making the character format at the cursor predictable (and sane!) for everybody.
or finally review and accept that damned xyz panel we have been refining for a full week.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15681 [Scribus] Story Editor / Text Frames minor always 2019-05-09 18:13 2019-12-18 01:06
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: 1.5.5.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Crash when deleting text with footnotes
Description: Scribus crashes when deleting selected text that containes footnotes

- Original report is 0011661
- demonstrating file is https://bugs.scribus.net/file_download.php?file_id=6409&type=bug
Tags:
Steps To Reproduce: - open file
- select all contained text
- delete
- see : scribus has crashed
Additional Information: bt says
# 8 0x0000555556157618 in ScribusDoc::setUndoDelNote(TextNote*) ()
# 9 0x0000555555e628a3 in PageItem_TextFrame::removeMarksFromText(bool) ()
# 10 0x0000555555e5812a in PageItem_TextFrame::deleteSelectedTextFromFrame() ()
# 11 0x0000555555e55789 in PageItem_TextFrame::handleModeEditKey(QKeyEvent*, bool&) ()


see full uploaded backtrace
System Description
Attached Files: backtrace (4,905 bytes) 2019-05-09 18:13
https://bugs.scribus.net/file_download.php?file_id=10427&type=bug
Notes
(0046203)
PeterBenedek   
2019-05-11 14:37   
It's very old fault...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
13483 [Scribus] Styles feature always 2015-10-29 22:56 2019-12-17 10:32
Reporter: surcouf Platform:  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Ability to see where in the scribus whole document one style is used
Description: My Scribus version is 1.4.3
I am working with Scribus which is a great product for a non-profit project.

I have created a few styles to harmonize the texts, and I would need to know, while selecting one style, where it is used in the document. I haven't found this feature wyet, hope I haven't overlooked it!
There is an option to look for a text style within a text frame (Menu Edit > Search/replace), but unfortunately not within the whole document.

As a comparison, you can look for one value in an Excel sheet, and there is the option "look for the first occurrence" and "look for all occurences within the sheet / the document". The result is a list of cells having the searched value.

I wish in Scribus a menu option (e.g. Edit > Search whole document) where while selection one style in a drop-down list, the search returns
a) option first occurence : goes directly to the document page where this style is used
b) option all occurences : a list of pages where the syle is used. Clicking on one page of this result would move to this page and highlight the object of the page where the style is used.
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_1.png (91,087 bytes) 2015-10-29 22:56
https://bugs.scribus.net/file_download.php?file_id=7761&type=bug
Notes
(0047282)
ale   
2019-12-16 18:33   
(Last edited: 2019-12-17 10:32)
i don't think that listing all matches is that useful.
the main request is being implemented in the search and replace for the whole document.

<hr>

p.s.: i've linked another ticket that asks for showing the results in the outline palettes... that sounds like a usable solution to this request... so, it might be useful...



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9093 [Scribus] General feature N/A 2010-05-10 20:58 2019-12-17 09:22
Reporter: Thaddeus Platform: x86, 32bit  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 9.11 & 10.04  
Status: new Product Version: 1.3.7svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: New Features for Outline palette.
Description: Display statistics of regular expression search, such as total hits, maximum and minimum page-based counts. (0002332)

Option to hide pages with no hits.

Make it possible to override the case in-sensitiveness by the use of \x41\x42\x43 or [ABC], etc.

Show the color of the layer on the palette: color on the text of frame name, background, underline, tiny square, circle, on the tree lines, etc. (0010568)

Show Frame Attributes as additional child branch with option to hide, perhaps on its own palette, The "Attributes" Palette!
Tags: outline_palette, regex
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1460 [Scribus] Story Editor / Text Frames minor always 2004-12-27 15:35 2019-12-17 09:19
Reporter: jo-hannes Platform: any  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.3.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: search & replace...replace (all) not possible before clicking on search.
Description: replace function works quite slow and no progress bar is shown if there is a longer text.
the tab order of the search part is okay, but in the replace part should be category1-option1 (text- " "), category2-option2 and not, as now: category1...x, option 1...x.
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010483)
mhanski   
2006-04-26 14:17   
confirmed with scribus 1.3.3.1 on kubuntu
(0047287)
ale   
2019-12-17 08:56   
i've moved the progress bar part to 0016013


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1105 [Scribus] User Interface feature always 2004-09-18 13:51 2019-12-17 09:19
Reporter: louisdesjardins Platform: all  
Assigned To: OS: all  
Priority: normal OS Version: all  
Status: acknowledged Product Version: 1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Allow multiple Search values at once
Description: Allow users to do multiple search/replace action at once in a document. For each string we’d be able to access all settings available right now for just one text string. This will add computing power to Scribus, from the UI.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0010473)
mhanski   
2006-04-26 12:33   
Reminder sent to: christoph_s, jo-hannes
your opinions? "nice to have" or "must be"?
(0010474)
christoph_s   
2006-04-26 12:38   
Well, it's not a "must have", but it would provide an extremely powerful tool, especially in connection with 2332 and the scripter. So I'd say: it's a "would be great to have" ;)
(0010477)
cbradney   
2006-04-26 12:47   
Is planned
(0014866)
axelb   
2007-01-18 15:52   
(Last edited: 2007-01-18 15:53)
And please let the search/replace dialog be independent of the story editor so that I can work on the found text there without having to close the search/replace dialog.
http://bugs.scribus.net/view.php?id=5189

(0018950)
louisdesjardins   
2008-02-11 02:03   
This one "is planned" but, at it seems, is not on the Roadmap nor is it on the Roadmap Extras. My concern here is just avoid that it slips through the cracks! I think that when we have this, some people *will* notice! Is it possible to find a little room for it on the Roadmap?
(0018954)
cbradney   
2008-02-11 19:23   
If you reread the roadmap.. its been changed to be all post 135 with no order or selection per version. We will redo the 1.3.6 roadmap once 1.3.5 is done so we wont add anything new now.
(0018958)
louisdesjardins   
2008-02-11 21:12   
Sorry, but I don't see it in here:

http://wiki.scribus.net/index.php/1.3.x_Roadmap#Post_1.3.5

Is there somewhere else to look? Or do you want me to add it there (can I do that?)
(0018960)
cbradney   
2008-02-11 22:09   
No I'm saying that document will not be edited until we decide on our plans for 1.3.6. We want 1.3.6+ to be a lot shorter so we will set exact plans after 1.3.5 is done.
(0047286)
ale   
2019-12-16 19:42   
what exactly does this request want?
(0047288)
ale   
2019-12-17 09:06   
what exactly does this request want?

ok, i got it, do we really want the user to be able to this without regexp?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2332 [Scribus] General feature always 2005-07-31 18:12 2019-12-17 09:18
Reporter: Howard White Platform: an  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: new Product Version: 1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Add regular expression capability to Search/Replace
Description: For experienced users, the ability to use regular expressions in search and replace would be very helpful.
Tags: search
Steps To Reproduce:
Additional Information: regexp capacity using Qt tools already exists and works in Text Filters (Import Text).
Attached Files:
Notes
(0026137)
jirib   
2011-04-22 20:07   
Yes yes yes!!!! This is very needed!!! If would be great to have similar functionality as OpenOffice.org/LibreOffice has. Some text authors are really bad and DTP operator has to replace all spaces with non-breaking spaces in front all prepositions etc... (with regex it is easy).
(0026177)
StefanM   
2011-05-04 14:18   
I second that.

Search and Replace should also work on more than one Element at one. As it is now, you can search just in the selected text Element. You should be able to search through all Elements on a Page, all Elements in a Document.

There should also be Style Search and Replace, e.g. for all possible text features. Some are missing now.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
950 [Scribus] Story Editor / Text Frames feature always 2004-08-08 15:46 2019-12-17 09:17
Reporter: lkaratzas Platform: PC  
Assigned To: OS: Suse  
Priority: normal OS Version: 9.0  
Status: confirmed Product Version: 1.3.4cvs  
Product Build: 8/8/04 Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: non modal search dialog
Description: The search and replace dialogue should not be modal because the way it is now you cannot cut and paste into it.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0002146)
cbradney   
2004-08-08 16:00   
1. Page Up/Down moves the objects up and down the levels
(0003675)
louisdesjardins   
2005-02-09 19:35   
2. At least 1.2.1 allows to cut/paste in the Search/Replace dialog.
(0009727)
jo-hannes   
2006-04-08 21:58   
copy paste yes, but not open dialog, select text, copy into search field, find replace text, copy into replace field
(0040269)
Kunda   
2016-04-18 15:04   
Merging #117722 in to this ticket:
When using the Story Editor search function, in case of a hit it is not possible to run operations on the text found, because the search window stays in focus. Modifying the text is only possible after closing the search window.
This makes work difficult.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3621 [Scribus] Import / Export feature N/A 2006-04-10 21:54 2019-12-17 09:15
Reporter: Tsoots Platform:  
Assigned To: Tsoots OS:  
Priority: none OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [OBSOLETE] Metabug: COSS text importer update
Description: I'll group all the issues related to COSS (http://www.coss.fi/en/) sponsored text import work here + some additional text import related issues I'm gonna work on in the near future. Most of these issues will be resolved in three months starting from the beginning of June. There's the original work plan attached (in Finnish) ps_scribus.pdf. Some more discussion over the ideas can be found from the mailing list thread http://nashi.altmuehlnet.de/pipermail/scribus/2006-April/016854.html
Tags:
Steps To Reproduce:
Additional Information: Project plan
============
============

Foreword
========
bla bla bla

Project outline
===============
bla bla bla

Plugin interface for text importer plugins
------------------------------------------
Plugin interface is ment to be a simple api for coders to build
file format importers for Scribus. It will be acting in between the
plugins and Scribus' core text handling code.

Interface will allow two types of plugins to be written with it.
The most common type of plugin is a regular file format importer
plugin. This type of plugin will convert an external file format
into a Scribus understandable format and will be used for example
when importing text from a text file, OpenDocument Text file...
The second type of plugins, the api will make possible, is plugins
that will work on the formatting and text of the document
that is currently being imported.

To make these two plugin types possible plugin handling system
will need to allow piping of plugins. Ie. one can direct the output
of a file importer plugin to a style/text handling plugin. One
situation where this could be used is for example when removing
all formatting from an ODT file. The flow for such a setup is
presented in the following picture.

ODT -->
  Scribus ODT importer -->
    Style remover plugin -->
      Scribus text frame

Another possible use case for a plugin chain like this is when the person
responsible for the layout wants to remap the styles present in for
example OpenOffice.org document to ones in the Scribus Document.
Then one would direct the output of the ODT-importer to the style
remampping plugin which is presented in the next picture.

[insert pic 2 here]

bla bla bla

Plain text files
----------------
bla bla bla

OpenDocument Text files
-----------------------
bla bla bla

Text and Style Filters
----------------------
Text and style filters will allow search and replace type of
actions on the text and styles of the imported document. This
plugin will only work when piped with a file importer plugin.
The most important features it will offer are search and replace
for text, search and replace for styles and style application
based on user defined tags.

Rich Text Format files
----------------------
bla bla bla

Documentation
-------------
bla bla bla

(most important parts of the work plan in English)

Process
=======

Size estimation
---------------
bla bla bla 6700 loc

Schedule
--------
bla bla bla
Attached Files: ps_scribus.pdf (390,550 bytes) 2006-04-10 21:54
https://bugs.scribus.net/file_download.php?file_id=1881&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
2575 [Scribus] Usability trivial always 2005-09-16 22:37 2019-12-17 09:13
Reporter: intrigeri Platform: ppc  
Assigned To: OS: Debian  
Priority: low OS Version: sarge  
Status: acknowledged Product Version: 1.3.1cvs  
Product Build: 15 september 2005 C-C-T-F-A Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [OBSOLETE?] Search/replace dialog should warn when trying to replace by the same text
Description: It would be nice, when the user tries to search for some text and replace it exactly by the same, to warn him/her.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0006615)
ringerc   
2005-09-17 03:21   
I'm not entirely sure I understand why that's an issue, really.
(0011070)
louisdesjardins   
2006-05-07 20:35   
I disagree with this warning. I don't think it is necessary at all. It can happen we have to change attributes to a certain string... it is then obvious we need to replace that string by the same string. It is expected that when working in that dialog, we have to be cautious, no matter what the change will be.
(0047285)
ale   
2019-12-16 19:37   
why?

if nobody sees a use case, i think that we can close this.
(it's stupid to replace some text by itself, but i don't see why a warning would be needed... the result will be what the user expects.)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16014 [Scribus] Story Editor / Text Frames feature N/A 2019-12-17 09:03 2019-12-17 09:03
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Search and replace: find non-printing characters (spaces, tabs, new lines, etc).
Description: Search and replace various types of spaces, tabs, new lines and other non printing characters.

We can for sure add this in the regexp search, but can it also be a more general feature?
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
1752 [Scribus] Story Editor / Text Frames major always 2005-03-03 06:32 2019-12-17 08:58
Reporter: jo-hannes Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Use selected text in SE search/replace as the basis for the search field
Description: if any text is selected in the story editor and the function
search/replace is called, take that selected text as the basis for the search
field
Tags: search, story editor, text frames, usability, workflow
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0003878)
milan   
2005-03-05 15:29   
I think searches and substitutions should allow the user to choose if he wants them to be global, i.e. they affect all the text frames of the document or of the page.
This is really useful to replace special characters like spaces next to quotes to non-break-spaces, or oe to œ. This is not so complex to implement, do it ? ;-)
(0003879)
ringerc   
2005-03-05 21:07   
milan: While global S&R would be useful, you can do a lot of that at text import time using the get text plugin. You can even use regular expressions for more complex replacement tasks if you need to.
(0004770)
ringerc   
2005-05-25 05:03   
Re the use of text selection, I agree that'd be very useful. So would "search only this frame" vs "search all frames" when not in story editor. It would be very important to have a GUI control for:

Search:
   - The current selection
   - The current frame
   - The whole document

(with "the current selection" on by default if there is a selection, and greyed out if there is not).
(0004771)
ringerc   
2005-05-25 08:52   
Hmm... I think it might be possible to do this, and global S&R, in Python.
(0008847)
lemmit   
2006-02-21 13:57   
Global S&R would make me happy. Sometimes you need to change something _after_ you have imported all texts. In my case I needed to change the model number of a device. Considering the document was a 100-page manual of the same device, there were lots of instances. Using a text editor does the trick, but is somewhat cumbersome. I wouldn't mind if global S&R was a plugin, script or wild magic, as long as it is there :)
(0008848)
louisdesjardins   
2006-02-21 14:37   
Agree we need a better S/R capability.

To [Current frame] option we could add [Current linked frames] to Craig Ringer's options.

Also, a Super Search and Replace would allow to look for many strings "at once". Or a table of automatic substitution, à la Short Words. Readily editable, handy.
(0008851)
cbradney   
2006-02-21 15:03   
This will be helped with the new text system in 1.3.4+ that will store the text for a text chain in one data structure rather than per frame.
(0012387)
axelb   
2006-08-31 20:10   
(Last edited: 2007-01-18 10:28)
And, I might add, if I search for a phrase in the text and find it, then close the search box, I will be brought back to the very beginning of that text, not even is the found text marked (as I think it should be). I have *almost* as much difficulty finding the occurence now as I had before the search :-(

IMHO: The text ought to be editable when the search box is open also. And the program ought to remember my position when I select something somewhere.

(0012391)
jegHegy   
2006-09-01 01:03   
addition: S&R doesn't find non-printing characters (spaces, tabs, new lines, etc).
(0014856)
axelb   
2007-01-18 10:29   
(Last edited: 2015-09-25 18:56)
See also 0005189

(0036375)
Kunda   
2015-09-25 18:56   
Reworded summary
lowered priority to normal since it's been open for years


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16013 [Scribus] Story Editor / Text Frames minor have not tried 2019-12-17 08:54 2019-12-17 08:54
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Search and Replace: no progress bar is shown
Description: if there is a longer text, scribus should show a progress bar.

(extracted from 0001460)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12271 [Scribus] Story Editor / Text Frames major have not tried 2014-04-23 17:06 2019-12-17 08:52
Reporter: Pancho Platform:  
Assigned To: ale OS:  
Priority: high OS Version:  
Status: assigned Product Version: 1.4.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.6 milestone  
Patch: No
Summary: Search & Replace: screws formatting
Description: When replacing a shorter by a longer word, the additional characters adopt the paragraph's basic formatting. This might be fine if a whole word is added but not if a word is altered or corrected.

See the Screenshot:
- first line is status quo ante
- second line: replacing "Scrbus" by "Scribus" leads to the last character not being bold. => certainly wrong
- third line: replacing "Scrbus" by "Scrbus is" leads to the new word not being bold. => possibly correct, however unexpected
- fourth line: replacing "Scrbus" by "Is Scrbus" leads to the first 6 characters being bold. => certainly wrong.

While a really smart solution isn't all to easy without calculating word similarities etc., we would probably be better off when extending the formatting of the matched string (or its first character) itself to the whole replacement string.
Tags: MABs, search
Steps To Reproduce:
Additional Information: This is a problem especially if the user can't undo correctly. Escalating this to 'Major' and 'high'
Attached Files: replace.png (42,052 bytes) 2014-04-23 17:06
https://bugs.scribus.net/file_download.php?file_id=6692&type=bug
Notes
(0035000)
Kunda   
2015-04-30 12:13   
confirmed + assigning to 1.6 milestone


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16012 [Scribus] Story Editor / Text Frames minor always 2019-12-17 07:42 2019-12-17 07:43
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Search and replace: replacing text can't be undone
Description: text replaced with "search and replace" can't be undone.
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3813 [Scribus] Scripter minor N/A 2006-05-13 20:58 2019-12-16 19:43
Reporter: christoph_s Platform: any  
Assigned To: OS: any  
Priority: normal OS Version: any  
Status: acknowledged Product Version: 1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Metabug: Scripter
Description: All bugs related to the Scripter

==PLEASE DON'T ADD ANY COMMENTS TO THIS METABUG==

If you wish to be notified about issues related to the Scripter, please click on the "Monitor Issue" button

Tags:
Steps To Reproduce:
Additional Information: See the whole list of metabugs: http://wiki.scribus.net/index.php/Metabugs
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12272 [Scribus] Story Editor / Text Frames feature have not tried 2014-04-23 17:13 2019-12-16 19:40
Reporter: Pancho Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.4.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Search/replace dialog: Collapse advanced search criteria
Description: The Search/replace dialog is huge and rather complex even though most search criteria usually aren't needed and with the simple string search being the most common use.

Therefore all other search criteria should be collapsed allowing the dialog box to be much smaller, thereby covering less of the document area.
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0031781)
Pancho   
2014-04-23 17:23   
In collapsed state / simple mode, we would also avoid requiring a checkbox to be checked. The checkboxes would only appear in uncollapsed / advanced mode.
Scribus would remember the last state of the search dialog just as it already does.

IMHO, this would help improve the user experience for first-time / basic usage.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12394 [Scribus] General feature N/A 2014-06-14 14:34 2019-12-16 19:40
Reporter: pygmee Platform: x86  
Assigned To: OS: Debian  
Priority: normal OS Version: wheezy  
Status: confirmed Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Add "all document" to "edit > advanced select".
Description: In the "Edit > Advance select" dialog one can choose between 3 options mostly based on active page. For longer document it would be interesting to make the research on the whole document.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0037123)
JLuc   
2015-10-30 16:49   
I think it's not "on active page", but rather "on active text frame".
(0040782)
JLuc   
2016-05-05 10:53   
yes, it would improve "search" for all users working on documents with more than one textframe


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14976 [Scribus] User Interface feature have not tried 2017-09-03 12:39 2019-12-16 19:35
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 14.04  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [OBSOLETE] Enable to search and replace "none" style (for paragraphs)
Description: The "Search and Replace" tool proposes to replace paragraph styles, but it doesnt enable to set a style to paragraphs that have no styles.

Please add a "No style" (Use same langage string as in the PP paragraph style SELECT) option in the paragraph style search SELECT and treat it as a way to set a style to paragraphs that have no styles : replace "No style" with "some style" ("some style" being choosen in the "replace with" style SELECT in right part of "search and replace" dialog).

Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0044395)
ale   
2017-09-03 12:57   
no, if something should be done, remove "No Style".
the default should be to apply the default style, not to apply no style.

please...
(0047279)
ale   
2019-12-16 18:21   
there is no (or should be no) "No Style" anymore.

i think we can close this ticket...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16011 [Scribus] General feature have not tried 2019-12-16 18:31 2019-12-16 19:33
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Search and replace for item properties
Description: We should rename, the "Edit > Advanced Select All" command and extend it to a "Search and Replace"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
4538 [Scribus] User Interface minor always 2006-11-16 14:37 2019-12-16 19:33
Reporter: christoph_s Platform: x86  
Assigned To: Chelen OS: Linux  
Priority: normal OS Version: SuSE 10.1  
Status: assigned Product Version: 1.3  
Product Build: 15 October 2006 Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Add character styles and line styles to the Search and Replace dialog
Description: Would be a nice enhancement...
Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0013429)
mkoren   
2006-11-16 21:14   
Similar to 0003778....
(0028418)
greyscale   
2012-07-10 20:08   
In my opinion, the possibility to search/replace Character Styles would be a MAJOR enhancement:

It would give a good workaround for the recurring problem of losing character styles (bold and italics) of imported documents.

To summarize quickly:

Singular words in italic or bold style can be applied in two ways: manually through the Properties Palette, or with a Character Style.

If we apply a Paragraph Style, all manual styling will be erased, but Character Styles will be preserved.

Therefore, a logical workflow when importing an ODT file that contains *italics* and **bolds** (manual styles) would be to replace them with Character Styles.

The search/replace function would allow to perform this in a few quick steps -- IF it would allow us to select Character Styles. Without that function, we have no other way to preserve those styles than by painfully applying the Character Styles one by one -- a complete waste of time if we handle long documents.
(0047284)
ale   
2019-12-16 19:32   
i guess that the lines part should go into 0016011


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
5189 [Scribus] Story Editor / Text Frames feature always 2007-01-18 10:27 2019-12-16 18:24
Reporter: axelb Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [OBSOLETE] Story editor and Search/replace should be separated
Description: If I search for a phrase in the text and find it, then close the search box, I will be brought back to the very beginning of that text, not even is the found text marked (as I think it should be). I have *almost* as much difficulty finding the occurence now as I had before the search :-(

IMHO: The text ought to be editable when the search box is open also. And the program ought to remember my position when I select something somewhere.

How else am I supposed to edit some text I have searched for? I would find the above an really essential improvement, now searching for something is almost useless (unless there are methods that I am not aware of that solves this).
Tags: search
Steps To Reproduce: 1. Open the story editor
2. Open search/replace
3. Perform a search
4. Close the search box
Additional Information: This was mentioned in bug 0001752
also, but since I got no feedback and this is still a problem in 1.3.3.7 I file this as a separate bug.search
Attached Files:
Notes
(0014867)
axelb   
2007-01-18 16:22   
This also measn that it ought to be possible to have more than one story editor open at the same time and also to have more than one search box (filling out all the different formats takes time), this opens up for a more creative use and lets me work on more than one task simultanously--I think that corresponds to usual human behaviour :-P
(I think they have even made tests that showed people working not just top->bottom thorugh their text, but shifting fokus back and forth, at least concerning translating that is :-)
(0015231)
christoph_s   
2007-02-13 17:23   
The search feature is actually completely useless, if not combined with replace.
(0018949)
louisdesjardins   
2008-02-11 01:36   
Workflow: you sent a hard copy of your document to a proofreader. The copy is returned to you and you now must enter those corrections in the Scribus file.

You can
a) Search visually for the next correction to make or
b) Perform a simple Search to get there quickly, have your cursor placed automatically at this occurrence and enter your correction. Repeat b) for each corrections.

No matter how many corrections there are on the hard copy, the Search alone will save you lots of time and effort. For small typos, you can of course add something in the Replace field. For more complex corrections, at least you're in the right spot in seconds.
(0047280)
ale   
2019-12-16 18:24   
afaict, this is solved in the current SE.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15957 [Scribus] Color Management minor always 2019-11-19 14:23 2019-12-16 17:43
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Embedded ICC color profiles of PNG images are not detected during import
Description: The embedded ICC color profile of an imported raster image is not detected.

I'm attaching the Png that was contained in the .sla uploaded by derAndere1 on Github:

https://github.com/scribusproject/scribus/issues/125

The issue on Github contains a few more details.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: original.PNG (1,685,088 bytes) 2019-11-19 14:23
https://bugs.scribus.net/file_download.php?file_id=10751&type=bug
Notes
(0047107)
jghali   
2019-11-19 15:20   
PNG files are read by using Qt image reading functions which do not allow us to retrieve any embedded ICC profile. The only formats where we support retrieving embedded ICC profiles are JPEG, TIFF and PSD.
(0047108)
ale   
2019-11-20 07:47   
mmm... since PNGs are more and more used for serious work, would it be possible to use a "real" png library for reading them?
(0047109)
jghali   
2019-11-20 08:08   
Yup, but not right now. I would rather see an intermediate solution where we would continue to do as now for reading image data, but have specific function for extracting embedded profile from png using libpng.

Also one tip: I've noticed that the original image is a 16bit image using a linear RGB profile. We have no support for exporting 16bit images to PDF without converting them to 8bit and image color management is anyway performed on 8bit data. So importing an image with an embedded linear RGB profile is asking for trouble.
(0047276)
davidrevoy   
2019-12-16 17:43   
Hey! Just to let you know; I discovered I was affected by this bug too for my Pepper&Carrot "big collection" book project. (Funny to see the PNG reported uses also Pepper&Carrot picture, that's cool). I'll switch my project to another input format to try to workaround.

I have no idea how color convertion behaves without a source profile to target the CMYK profile of my printer in this context and if it can explain the bad color I'm getting once printed so far.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16006 [Scribus] General crash always 2019-12-12 14:56 2019-12-15 16:36
Reporter: reetp Platform:  
Assigned To: cbradney OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.5  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: libpoppler crashes Inkscape
Description: Not sure where best to report this but we recently upgraded desktops to Xubuntu Bionic.

We use both the Inkscape and Scribus PPAs

We experienced instant crashes in Inkscape when trying to import PDFs and EPS files.

After a lot of hunting about we found these bugs:

https://gitlab.com/inkscape/inbox/issues/1215
https://gitlab.com/inkscape/inkscape/issues/255

Its seems this is due to an issue with the version of poppler that you supply in your PPA.

Scribus PPA: 0.74.0-0ubuntu1.2~ppa1
Downgrade to: 0.74.0-0ubuntu1.2~ppa0

We removed the Scribus PPA, downgraded Scribus and poppler, and Inkscape worked perfectly thereafter.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047256)
ale   
2019-12-12 17:26   
the problem is known and the person in charge is notified and is thinking about a solution:

http://lists.scribus.net/pipermail/scribus/2019-December/055874.html

in this specific case, the best place for the report would have been the debian bug tracker, but i don't think that further actions are now necessary.
(0047260)
reetp   
2019-12-12 18:02   
Ah yes - thanks.
(0047261)
jghali   
2019-12-12 18:02   
(Last edited: 2019-12-12 18:03)
>> Its seems this is due to an issue with the version of poppler that you supply in your PPA

The Scribus PPA is not managed by Scribus team, so the debian or ubuntu bug tracker would have indeed been a better place to report this issue.

(0047272)
cbradney   
2019-12-15 16:36   
Resolving per previous comments


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15980 [Scribus] Build System minor N/A 2019-12-01 21:26 2019-12-15 16:35
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] clean up the cmake files
Description: tonight, dakon showed in irc and listed a few issues with our cmake files.

there seem to be checks for cmake < 2.6 (while we're requiring 3.5) and many of the modules we are shipping can be removed and standard modules can be used.

i attache the irc log below.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: cmake-refactoring.diff (42,305 bytes) 2019-12-05 08:35
https://bugs.scribus.net/file_download.php?file_id=10797&type=bug
Notes
(0047184)
ale   
2019-12-01 21:28   
(Last edited: 2019-12-01 21:35)
a user just was over at #cmake to get some assistance building scribus with poppler in a custom location
looks like the modules misuse the include path of it
but it resulted in me looking in cmake/modules and noticing there is a bunch of code for CMake <2.6 in there
I strongly suggest getting rid of that
also the modules that duplicate what CMake has upstream, e.g. FindLibXml2, FindFreetype and so on
you can probably just delete half of that directory with minimal adaption
I suggest using the imported modules that the newer upstream modules provide, e.g. ZLIB::ZLIB, as they bundle all needed things in one call
and for me it looks like all poppler includes are wrong
they use <poppler/*>, while it should be just <*>
the poppler pkg-config file exports the directory as .../include/poppler
this only happens to work if things are in /usr/include/poppler

deleting the pre-2.6 code should be easy, there are several if(cmake_version) things then can just be deleted
just look at the first line of FindPOPPLER.cmake

and for the things you find through pkg-config I suggest to have a look at the IMPORTED_TARGET argument to pkg_search_module()

also passing this whole /usr{local/}?/lib{,64,${CMAKE_LIBRARY_ARCH}) stuff to find_library is totally needless, these are default paths searched anyway

the configreport.cmake can probably be replaced with FeatureSummary.cmake from upstream

(0047185)
ale   
2019-12-01 22:13   
we will need to make sure that the change work on all system (linux, bsd, macos, os/2, ...)
(0047187)
ale   
2019-12-02 09:30   
(Last edited: 2019-12-03 13:22)
here the action taken:

- [x] remove the unused modules
  - [x] LCMS (we're using LCMS2)
  - [x] remove the modules in `old/`
  - [x] remove Zlib (which was only used by the old Png module)
- [x] remove the _duplicate_ modules (cmake already provides better ones)
  - [x] ZLib
  - [x] Freetype
  - [x] LibXml2
  - [x] Fontconfig can't be removed yet since the module is only in cmake 3.14.0+
    - [x] Add a note about it in the main `CMakeLists.txt`
- [x] Replace the Scribus Fontconfig module by the 3.14.0 one
- [x] Get fontconfig to link
- Warning: When compiling on macos, `/opt/local/include` might not be automatically detected anymore
- [x] remove `ScribusFindPackageHandleStandardArgs`
- [x] remove all `CMAKE_MAJOR_VERSION` that target anything lower then the current required minimum
- [x] remove paths from find_library() and friends that are already searched by default (like /usr/lib64 and /usr/local/*)
- [x] line 27 in `FindGMAGICK.cmake` is probably just some noise
- [x] simplify the poppler finding, put it in `_Dependencies`, and remove `poppler/` from the `#include<poppler/....h>`
    - the current includes only work because we have `/usr/include` by default, and stuff is in `/usr/include/poppler`. no way to have poppler in a different path.

(0047192)
ale   
2019-12-03 13:46   
hier ist die merge request...

https://gitlab.com/scribus/scribus/merge_requests/18

don't forget to comment, like, subscribe, hit the notification bell...

... and i'll add a diff as soon it's clear that i'm not getting further hints from the cmake guys...
but you're already welcome to commit the patch as is.

(btw, there were some very helpful people in #cmake . thanks!)
(0047193)
ale   
2019-12-03 13:54   
we could also remove the cairo detection and deprecate `-DPREFIX_CAIRO` in favor of `export PKG_CONFIG_PATH=/path/to/cairo` what do you think?
(0047200)
ale   
2019-12-05 08:35   
ok, i got no feedback from the cmake guys anymore... here is the patch.
(0047216)
cbradney   
2019-12-08 21:45   
I've committed much of this apart from podofo, poppler, fontconfig. For fontconfig, we could just bump the minimum cmake to 3.14
(0047220)
ale   
2019-12-08 22:20   
thanks for the commit!

cmake 3.14 is probably too new.
the newest ubuntu and debian testing do not have it yet.

for podofo, the paths removed are searched by default.
but it's just a small cleanup anyway...

for poppler: the .h names used by the poppler projects are not the best ones. but we cannot change that
but from what i've been told by the cmake guys, the current includes seem to be wrong and only work because /usr/include is in the default path.
what's the reason for not accepting the changes?
do they fail on your computer?
(0047233)
cbradney   
2019-12-09 22:40   
Some more changes committed from the patch.

a project can choose whatever names they want, but using poppler/filename is therefore perfectly ok.

the fontconfig stuff doesnt work here..
(0047238)
ale   
2019-12-10 10:14   
do you have some details about fontconfig?

it might be a mac specific thing (or i did not commit everything correctly).
it seems to work here and on gitlab's CI..
(0047243)
cbradney   
2019-12-10 22:38   
Pending current build is successful, I will commit. It might have been the podofo changes that broke it..
(0047249)
ale   
2019-12-11 15:43   
hi @craig

these lines are missing from the main CMakeLists.txt:

if (TARGET Fontconfig::Fontconfig)
    target_link_libraries(${EXE_NAME}
        Fontconfig::Fontconfig
    )
endif()



https://gitlab.com/scribus/scribus/merge_requests/18/diffs#dc885ce634ee67872a738cd04be761e34dbf0ce3_1298_1297
(0047250)
cbradney   
2019-12-11 23:08   
Added those in now. Builds ok on OSX
(0047251)
ale   
2019-12-12 07:28   
thanks!
(0047266)
ale   
2019-12-14 08:20   
i think that we can close this... or are there further things to be committed?
(0047271)
cbradney   
2019-12-15 16:35   
Poppler stuff still needs to go in


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15869 [Scribus] Usability minor always 2019-10-23 08:14 2019-12-14 08:23
Reporter: PeterBenedek Platform: x64  
Assigned To: ale OS: Linux Mint  
Priority: normal OS Version: 19 (64bit)  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Cursor shape continuously change over elements of canvas.
Description: Tested in Linux Mint 19.x; Scribus 1.5.x

Above frames the cursor it wears strangely. The problem applies to frames.

-- Make TextFrame
-- Move the cursor over the frame
-- Move the cursor slowly
-- Look the cursor: shape of the cursor continuously changes:
* above the frames: white hand --> white arrow
* above the corners: white hand --> white arrow --> black arrow

I slowed the video, but this is happening much faster in reality (unfortunately I could not record the original speed of cursor change).
Extremely distracting behavior.
Tags:
Steps To Reproduce:
Additional Information:
System Description Scribus 1.5.x
Attached Files: CursorShapeChange.mp4 (154,398 bytes) 2019-10-23 08:14
https://bugs.scribus.net/file_download.php?file_id=10647&type=bug
ChursorShapeChange.gif (131,231 bytes) 2019-10-23 08:17
https://bugs.scribus.net/file_download.php?file_id=10649&type=bug
CursorChange_OriginalSpeed.mp4 (1,220,873 bytes) 2019-10-23 08:40
https://bugs.scribus.net/file_download.php?file_id=10650&type=bug
cursor-resize.diff (4,795 bytes) 2019-11-29 13:14
https://bugs.scribus.net/file_download.php?file_id=10778&type=bug
Notes
(0047162)
ale   
2019-11-29 09:41   
(Last edited: 2019-11-29 09:48)
i don't get it on my laptop.
but i got it in a vm on my older desktop computer...

(ah, no it's not the same... i generally got a flickering when hovering an item... but it might be the same issue)

(0047163)
PeterBenedek   
2019-11-29 12:17   
I don't tried in Windows, but in LinuxMint is very unpleasant.

"ah, no it's not the same..." : yes, it's not the same.
(0047164)
ale   
2019-11-29 13:14   
here is a patch for the flickering on the corner handles...
i cannot test, since i don't see the flickering, but the replaced code was setting two times the cursor...


if it passing around the Qt::CursorShape is ok, i'd like to refactor the rest of the function to avoid other flickerings too.
(the idea is to only set the cursor at the end of the function and get all other functions / parts to return / set a Qt::CursorShape .
(0047165)
ale   
2019-11-29 16:39   
now that i re-read the the list above, it's the same.

so this is a partial patch...

it can be applied and if it gets applied i'll create a further patch to more generally solve the issues with the cursor being set multiple times.
(0047172)
cbradney   
2019-11-30 16:54   
Patch applied
(0047176)
ale   
2019-11-30 20:00   
i made a test with a break in the debugger and the patch will not solve the flickering.

i'm taking notes here:

https://demo.codimd.org/0iRU018mRzy7mubMvwflwQ?view

and later i will copy the full analysis in a note in this ticket.

it's a collaborative document and you're welcome to comment in there, here or on irc.
(0047265)
PeterBenedek   
2019-12-14 08:10   
One more thing: the blinking is related to the placement order.

I changed: Document setup -- Guides -- Placement
If the placement:
-- Margins
-- Content object
-- Guides
the cursor doesn't blink over the object

If the placement:
-- Margins
-- Guides
-- Content object
the cursor does blink over the object
(0047267)
ale   
2019-12-14 08:23   
the cursor is set multiple times for each frame.
over dozens and dozens of lines of code.

i'm waiting for 0015976 being reviewed before continuing my jurney in the world of cursors...

i remove the "patch" label from this ticket, since the patch attached has been applied but it does not (yet) solve the full problem.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15983 [Scribus] General minor N/A 2019-12-02 15:56 2019-12-13 17:39
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] thirdparty/pgf: libpgf is packaged for debian and maintained
Description: since libpgf is packaged for debian and maintained, wouldn't it be better to use the upstream libraries?

http://www.libpgf.org/index.php?id=3

or at least update the thirdparty code to the current one

(i've noticed that pgf exist because of warnings popping up while compiling...)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: libpgf.diff (269,637 bytes) 2019-12-13 09:45
https://bugs.scribus.net/file_download.php?file_id=10809&type=bug
Notes
(0047190)
christoph_s   
2019-12-02 23:58   
I suggest option 2, because it needs to be available not only for Debian but also other distros, as well as Windows and Mac OSX.
(0047191)
ale   
2019-12-03 11:03   
- https://software.opensuse.org/package/libpgf
- https://src.fedoraproject.org/rpms/libpgf

- for windows we never use packaged libraries, so it's about providing our own .dll (if upstream does not provide one)
- no idea how the packaging for macos works, but i guess that it will be the same as for the librevenge libraries (as an example)

all in all, i think that we should avoid providing copies of libraries that are maintained and normally distributed through other means.
(0047214)
cbradney   
2019-12-08 21:35   
I can get it from macports, but I am not sure why we've brought it in source. Either it was not maintained for awhile, or we had to modify significant portions of the code to make use of it, or it was a massive library we didnt need all of.
(0047215)
cbradney   
2019-12-08 21:37   
Author: fschmid
Date: Sun Nov 7 09:40:03 2010
New Revision: 15796

URL: http://scribus.info/websvn/listing.php?repname=Scribus&sc=1&rev=15796
Log:
Added the PGF image format, see http://www.libpgf.org for details.



To remove this, we'd need a CMake finder module to start with
(0047217)
ale   
2019-12-08 21:47   
it has been in debian since 2012... so at the time franz added it, it's likely that it was not packaged by the distributions.

i'm not sure that a pgf file has ever been used in a scribus document, but i might try to find out if i can use the debian package...

i might have a look at it...
(0047227)
ale   
2019-12-09 10:58   
ok, i had a look it.

libpgf does not have cmake files. so, before we can use their lib they should probably add support for cmake...
and then wait for the new version of the library to hit most distributions.

i guess that we should copy a new version then... and the next time think about removing support for it... except if it gets traction...
(0047228)
ale   
2019-12-09 11:02   
(Last edited: 2019-12-09 11:03)
... oops... it has a cmakelists.txt file...

... but probably not in the version distributed by debian...

(0047229)
cbradney   
2019-12-09 11:21   
We aren’t removing support for the file format.
(0047262)
ale   
2019-12-13 09:45   
(Last edited: 2019-12-13 17:39)
a patch is here
https://gitlab.com/scribus/scribus/merge_requests/20

and it's also attached.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15990 [Scribus] General feature N/A 2019-12-06 16:55 2019-12-12 17:48
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: StoryText::indexOf(): document what it does and what the plen output argument is
Description: in text/storytext.h, please put a short description of what indexOf() does and please document what plen contains (difference to the int result returned and when to use the one or the other)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047234)
jghali   
2019-12-09 23:51   
The pLen argument is named according to Hungarian notation (https://en.wikipedia.org/wiki/Hungarian_notation). The first lower case letter indicates this is a pointer, the following letters "Len" indicate this variable represents a length.

As this is already documented in storytext.h, the indexOf() methods allows to find specific text in the corresponding StoryText object. The pLen argument enable to retrieve the length of found text. Due to some subtlety in languages such as Arabic, this length may indeed not be the same as the length of searched text. Both indexOf() methods returns, as their names indicate it, the index of found text.
(0047253)
ale   
2019-12-12 15:47   
scribus does normally not use hungarian notation.
in this case i i think that outMatchLength would be a better name.
(of course, after an attentive look at the function i did understand what the function was doing... but it's the goal of good variable names and the docstring to make the life of the developers easier...)

if the function, the arguments and the variables are carefully named, i think that we can often avoid docstrings.
on the other side, if we have a function that has the same name as the "parent" one but does not just forward to the original implementation, it's imo important to list the differences and allow new contributors to understand what happens.

with a signature like

int indexOf(const QString &searchString, int from = 0, Qt::CaseSensitivity cs = Qt::CaseSensitive, int* outMatchLength = 0) const;

we could remove from the docstring what is now obvious and edit it to say what is so special to this indexOf() that we can't simply use QString::indexOf().
(0047254)
jghali   
2019-12-12 17:07   
>> in this case i i think that outMatchLength would be a better name.

In this case, there is no need to even look at the variable name to know that it is an output argument because there is not much reason to pass an int pointer to a function other than to retrieve an output value...
(0047255)
ale   
2019-12-12 17:24   
in modern c++ (and in in qt for many years) it's not common to have output arguments.

it's sometimes necessary, sometimes handy, but i would always always clearly document such cases.

of course, people with a c background and people having many years of c++ on their shoulders will recognize it immediately, but not programmers that come from other languages like java or python... or have been learning c++ during the last few years.

if we want new contributors, i think that we should make their life as easy as possible...
and not all of them will be seasoned c(++) programmers...
(0047258)
jghali   
2019-12-12 17:48   
>> in modern c++ (and in in qt for many years) it's not common to have output arguments.

Complete bullshit. You just have to look at Qt documentation to see that output argument are regularly used when needed. And doing so is in fact usually more efficient than returning a tuple or a structure/class, especially when you deal with vectors or other STL containers... Before C++17 and structured binding, using tuples as return values is also rather inconvenient.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16005 [Scribus] General crash always 2019-12-12 14:00 2019-12-12 17:28
Reporter: A_Menn Platform:  
Assigned To: OS: Windows 10  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scribus crashes after Start
Description: Error "Scribus ist wegen der Ausnahme EXCEPTION_ACCESS_VIOLATION abgestürzt"
scribus-1.5.6.svn-snapshot-191205-x64
Tags:
Steps To Reproduce: Start Scribus
Additional Information:
Attached Files:
Notes
(0047257)
jghali   
2019-12-12 17:28   
I cannot reproduce such crash here.
1) Crashes at startup are often caused by bad installed fonts. You can get more information where loading process stops by starting Scribus with the "Scribus 1.5.6.svn (console)" shortcut created in Start Menu.
2) If you had installed another version of Scribus previously, you might want to delete Scribus preferences located in C:\Users\Your_UserName\AppData\Roaming\Scribus
3) We have also seen the Dell Backup and Recovery Tool conflicting with Scribus (see 0013252). If you have that tool, you may want to uninstall it as a last option.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16000 [Scribus] Scripter minor always 2019-12-10 09:26 2019-12-12 15:21
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Scripter: behavior of setCharacterStyle() depends on the frame name being defined
Description: setCharacterStyle() applies the style to the whole frame when no frame name is passed as argument and to the current selection when a frame name is passed.

this the actual behavior and the documented one.

the behavior should be changed to always apply the style to the current selection if one is defined.

using character styles in the scripter is a rather new thing, and i don't think that there is anybody relying on this behavior to set the charstyle of the full frame.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scripter-setstyle.diff (7,652 bytes) 2019-12-12 15:20
https://bugs.scribus.net/file_download.php?file_id=10808&type=bug
Notes
(0047252)
ale   
2019-12-12 15:20   
i've patched both the setStyle and setCharacterStyle to behave in a new way:

from the new docstring:

- Apply the style named "style".
- If name is not specified, the current selected item is used.
- If the current item has a text selection, the style is applied to the selection.

this corresponds -- as an example -- to the behavior of getStyle().

i can't think that somebody is relying on the current behavior, where -- despite a selection being defined -- the style is applied to the frame if no name is defined for the current item.
in such a ca case, a sane script will make sure that there is no text selection before applying the style to the item.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16008 [Contributor Builds] General minor have not tried 2019-12-12 15:16 2019-12-12 15:16
Reporter: HairyW Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Icons on the top menu bar appeared grayed out in scribus-1.5.5.dmg
Description: I recently installed scribus-1.5.5.dmg on an iMac with macOS 10.15 Catalina. The tool icons on the top menu bar appear grayed out. Only the red cross delete button is visible (screenshot attached)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screen Shot 2019-12-12 at 9.12.03 AM.png (294,665 bytes) 2019-12-12 15:16
https://bugs.scribus.net/file_download.php?file_id=10807&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15989 [Scribus] User Interface feature always 2019-12-06 11:40 2019-12-11 11:35
Reporter: rsevero Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: Yes
Summary: Enable Ctrl+Click to select objects below guides
Description: If I have an object below a guide (a line below a single line), I can't click-select it if I using the default "guides above" objects setting.

As Scribus already has a method of selecting objects that are below other objects (repeatly Ctrl-clicking it), I believe that, for the sake of uniformity and consistency, this same method should also work if the desired object is below a guide.

There are several ways for an user to select an object in the situation described but all of them require special knowledge and completely different actions to select an object. The same Ctrl-cliking method should work also here.
Tags:
Steps To Reproduce: 1. Create a guide line.

2. Draw a line snaped to the guide line.

3. Click somewhere else to unselect the line

4. Try to select the line clicking on it, pressing or not the Ctrl key

You only manage to select the guide line, not the line.

Additional Information:
Attached Files: guides-item-ctrl-select.diff (2,017 bytes) 2019-12-08 21:33
https://bugs.scribus.net/file_download.php?file_id=10799&type=bug
Notes
(0047205)
ale   
2019-12-06 13:12   
on my computer i don't even have to click the ctrl...
no way to select a guide when it's above a shape border, when the shape is selected.
(0047207)
rsevero   
2019-12-06 13:48   
ale, after the object has been already selected, I believe it happens exactly how you described.

But I'm talking about the cenario where there is no object selected at all. In this situation I can't simply click (or Ctrl-click) on the object behind a guide line to sleect it like I can for objects elsewhere.
(0047208)
ale   
2019-12-06 14:27   
a "normal" item cannot be completely behind a guide...
just click in the middle of it... you don't need to click on the border.

i've tried on a different computer and the ability to click on an item below a guide might depend on he resolution of the screen
if i zoom in and pay attention how the cursor changes i can click on any line or handle below the guide...

but, indeed, we could change the code for the guides to not react when the ctrl key is down...
(0047209)
rsevero   
2019-12-06 18:20   
I've experienced this possibility. It's a little bit tricky but it works many times.

But making the guides not react when Ctrl pressed seems much more user friendly to me as it capitalizes on a metaphor already present in Scribus interface.
(0047210)
ale   
2019-12-07 13:40   
@rsevero , if you have issues with real world cases, please post a .sla showing it.
i'm pretty sure that in (almost) every case there is an easy way to select an item (except a long line that is exactly under the guide).

... until somebody takes the time to check for ctrl when the user clicks on a guide...
(0047213)
ale   
2019-12-08 21:33   
attached, a patch that prevents the selection of guides, when ctrl is pressed.
(0047246)
jghali   
2019-12-11 11:25   
I committed a somewhat different and improved patch : ctrl-click can now be used not only to select objects below guides, but also to select guides below objects.
(0047248)
rsevero   
2019-12-11 11:35   
jghali, it sound's great. I will give it a try. Thanks!!


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15973 [Contributor Builds] General minor have not tried 2019-11-28 17:06 2019-12-10 15:29
Reporter: jpascualripa Platform: Mac  
Assigned To: OS: MacOS Mojave  
Priority: normal OS Version: 10.14.1  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scribus 1.5.5 Editing window appears blank
Description: The editing window still does not work the letter appears to be black but no text is visible in the window nor can the color of the text be changed. You can change the background color and then you can read the text. In the left column of the editing window you can not see anything, although clicking at the level of any paragraph you can see the style in which it is written and apply another style of those defined by the user. I would like to send a screenshot.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Captura de pantalla 2019-11-27 a las 11.52.42.png (14,426 bytes) 2019-11-28 17:06
https://bugs.scribus.net/file_download.php?file_id=10777&type=bug
Notes
(0047241)
jpascualripa   
2019-12-10 15:25   
The problem of seeing the editing window blank was due to the dark mode in which you can work with Mac OS 10.14 Mojave. There are several solutions for this problem.
First.– From System Preferences > General go to clear mode when working with Scribus 1.5.5
Second.– Open in Applications > Utilities > Terminal and write in the Terminal window "defaults write -g NSRequiresAquaSystemAppearance -bool Yes" without the quotes. Only the menu bar, the dock and certain parts of the system will appear in the dark mode, but not the applications, including Scribus 1.5.5 and the contents of the editing window will be displayed correctly. To eliminate this way of working, simply write to the Terminal window "defaults write -g NSRequiresAquaSystemAppearance -bool No".
Third.– There is a small free application called NightOwl very useful to make all these changes with one click.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
16001 [Scribus] Scripter feature N/A 2019-12-10 09:33 2019-12-10 13:29
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Scripter: add getCharacterStyle()
Description: add getCharacterStyle()
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: get-character-style.diff (4,746 bytes) 2019-12-10 09:33
https://bugs.scribus.net/file_download.php?file_id=10802&type=bug
get-character-style-2.diff (4,560 bytes) 2019-12-10 10:03
https://bugs.scribus.net/file_download.php?file_id=10803&type=bug
get-character-style-3.diff (4,696 bytes) 2019-12-10 13:29
https://bugs.scribus.net/file_download.php?file_id=10805&type=bug
Notes
(0047235)
ale   
2019-12-10 09:38   
i will propose a second version that does not require a selection...
(0047236)
ale   
2019-12-10 10:03   
here is a new patch that also works when there is no selection
(0047239)
ale   
2019-12-10 13:29   
feedback from jean in irc: cursor is not (really) defined when scribus is not in edit mode.

third patch...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15994 [Scribus] Guides minor always 2019-12-08 21:21 2019-12-10 02:38
Reporter: ale Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: resolved Product Version: 1.5.6.svn  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version: 1.5.6.svn  
    Target Version:  
Patch: No
Summary: If guides are behind items, cursor still changes to guide moving
Description: - set the guides to be behind the items
- draw a filled shape and put a guide in the middle of it
- move the mouse over the guide
- the cursor will change to the "move guide" one (wrong)
- when clicking, the item will be selected (right)

it's only a rendering thing, the behavior is correct
(CanvasMode_Normal::SeleItem, called by CanvasMode_Normal::mousePressEvent has more complex logic than CanvasMode::onMouseMovement)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15997 [Scribus] PDF feature N/A 2019-12-09 08:04 2019-12-09 17:02
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] move the export to PDF to the main file menu
Description: we keep on experiencing people that fail at printing with scribus (most of all with landscape documents).

it's tiring to tell all those people that scribus is made for producing PDFs that will be printed at a print shop and not for direct printing on an office / home printer.
and many people have a hard time accepting this fact.

this patch moves the "export to pdf" to the main file menu, just before the print command.
and renames it to "Produce PDF", to make it clear that it's not just one export among many others.

if you don't feel like renaming the command (or have a better label than "Produce PDF") feel free to revert that part to the current label.
the important part is to move the exporting Pdf at the root of the "File" menu. before the printing.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: pdf-produce.diff (4,944 bytes) 2019-12-09 08:05
https://bugs.scribus.net/file_download.php?file_id=10800&type=bug
Notes
(0047225)
JLuc   
2019-12-09 08:33   
That makes sense


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15976 [Scribus] General minor N/A 2019-11-30 19:46 2019-12-09 10:00
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] slightly simplify the cursor setting in canvasmode_*.cpp
Description: while working on 0015869 i'm trying to find out how setting the cursor works and i stumbled upon this:

does this loop do anything?

https://gitlab.com/scribus/scribus/blob/master/scribus/canvasmode_drawcalligraphic.cpp#L151

            for (int i = 0; i < m_doc->m_Selection->count(); ++i)
            {
                currItem = m_doc->m_Selection->itemAt(i);
                if (currItem->locked())
                    break;
                setModeCursor();
            }

except setting the same cursor n times?

why does it break on the first locked item?

does the attached patch change anything?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: cursor-mode-calligraphic-loop.diff (569 bytes) 2019-11-30 19:46
https://bugs.scribus.net/file_download.php?file_id=10784&type=bug
canvasmode-cursor-use-pageitem.diff (16,986 bytes) 2019-12-09 09:59
https://bugs.scribus.net/file_download.php?file_id=10801&type=bug
Notes
(0047175)
ale   
2019-11-30 19:55   
this loop can be found in several canvasmode_*.cpp files and i really wonder why it contains a break and not a continue when a locked item is found in the selection...
(0047177)
jghali   
2019-11-30 20:08   
The "m_doc->m_Selection->isMultipleSelection() block" located above this loop guarantee that this loop is executed only if n=0 or n=1. It is a trick to handle both cases while reducing the number of if blocks. Given the possible value of n when this code is executed, the "break" instruction is totally appropriate.
(0047179)
ale   
2019-12-01 11:10   
yes, but what is this loop doing?

it calls n time setModeCursor(), which only depends on appMode, without changing the appMode...
and if one of the items is locked it stops doing that.

why?

wait... what?

        PageItem *itemAt(int index=0) { return itemAt_(index); }
        const PageItem *itemAt(int index=0) const { return const_cast<Selection*>(this)->itemAt_(index); }

how does it work?

two functions with the same signature, only difference is the constness of the return value.
the second function is marked as const but it is not const!

and itemAt() does not just return the item but also deletes it from the list? the name is imo very misleading...

i'm more and more puzzled about what this part of code is doing...

can somebody explain it?
please...
(0047180)
ale   
2019-12-01 13:36   
(Last edited: 2019-12-01 14:44)
ok, got a chat with jean in irc...

so first, does this

    if (GetItem(&currItem))
        {
               [....]
            if (!(m_doc->m_Selection->count() == 1 && currItem->locked()))
                setModeCursor();
     }

do the same as:

            if (m_doc->m_Selection->isMultipleSelection())
            {
                setModeCursor();
                return;
            }
            for (int i = 0; i < m_doc->m_Selection->count(); ++i)
            {
                currItem = m_doc->m_Selection->itemAt(i);
                if (currItem->locked())
                    break;
                setModeCursor();
            }

?

the rationals:

- "if (GetItem(&currItem))" already ensures that at least one item is selected
- "GetItem(&currItem)" already puts selection.at(0) into currItem
- so we update the cursor except when only one item is selected and it's locked
  "(count() > 1 || item->locked())" looks nicer to me, "(!(n == 1 && item->locked()))" is imo more semantycally...

then: jean explained that itemAt() only removes null items (since the items are pointers that might be otherwise be deleted, that's useful and not dangerous...
i really think that a comment is needed.
oh, there is a comment, but imo at the wrong place.
in PageItem *Selection::itemAt_(int index), the commented out line should be removed and the other comment should be converted into a "javadoc"

\brief return the item if it's not a nullptr. remove the item and return nullptr, if the item we point to has been deleted by other parts of the code.

(0047226)
ale   
2019-12-09 09:59   
in the effort to simplify the cursor changes and slowly get to a streamlined path where we can avoid the flickering, i'm proposing a patch that:

- removes the whole "if (getCurrItem) ... else ..." for the files that have the same code has the calligraphic tool:
  - the first part (discussed above) does not make a visible difference
  - the second part is never activated (or at least i could not activate it)
- in CanvasMode_Edit::mouseMoveEvent(), use the pageItem from the top level if (in edit mode, a multiple selection does not really make sense and removing the check does not make a visible difference)
- i did not modify CanvasMode_Rotate::mouseMoveEvent() since:
  - it's rather (uselessly?) complex but fails at setting the new cursor (0015999)
- i also removed dead code (out commented or "if falsed") that did not have any comment on the reason why it has been left there and did look harmless to remove


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15999 [Scribus] General minor always 2019-12-09 09:50 2019-12-09 09:50
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Activating the rotating tool does not change the cursor to the rotate one
Description: Activating the rotating tool does not change the cursor to the rotate one.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15998 [Scribus] Graphics / Image Frames minor always 2019-12-09 09:30 2019-12-09 09:30
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: inconsistent editing a locked image frame
Description: if an image frame is locked

- if i double click on it (or press E) i can enter its edit mode
- once i'm in edit mode, i can't move the content with the mouse or the arrows
- but i can move it with the content palette
- if i press the shift key, i can rotate with mouse
- alt arrow does not allow me to resize the content (but i can do it in the content palette)
- the mouse cursor does not change (at first, but once i've rotated with shif-mouse it stays to the rotation cursor)

as a reference, for a text frame, i can edit its content even if it's locked.
the same behaviors are already in scribus 1.4

so the big question:

when a frame is locked, should its content of be editable or not?
i can work on this, if i get an answer to this last question...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15987 [Scribus] General feature N/A 2019-12-05 09:32 2019-12-09 07:43
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] settings: enable / disable optional features
Description: currently we have a few experimental features that should not be exposed by default in the UI.

i suggest that we should create a "optional features" section in the preferences to activate features that are not activated by default.

soon, i plan to propose a patch that shows how it would work with the tables.

i propose three sections:

- Optional features
  - For features that work correctly but are misleading for many users (file > print preview? hiding single items, editing in preview mode)
- Experimental features
  - Tables
  - Marks (footnoes, ...)
- Deprecated features
  - i don't know of any right now... but we might be able to use it to remove things after a few years as deprecated...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: optional-tables.diff (44,583 bytes) 2019-12-05 16:14
https://bugs.scribus.net/file_download.php?file_id=10798&type=bug
Notes
(0047202)
ale   
2019-12-05 16:14   
here is a merge request with appimage:

https://gitlab.com/scribus/scribus/merge_requests/19

the patch is attached.

- there is a new panel in the settings
- for now, the only option is "tables"
- by default, the table menu is disabled and the user can enable the feature in the settings
- when enabling the tables, a warning is shown, that scribus must be restarted before the "new" menu will be active
- there is a tooltip with some more details (i've tried to add a label below, but i failed to add the correct indend; i've left the code if somebody wants to give it a try again... or for a future me...)
- tables are not disabled and the content panel still works.
- if you think it's useful, we can add an alert if the user opens a document with tables and tables are disabled. (probably, it's useful... i can add this alert when i implement the alert for the missing images...)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3096 [Scribus] OS-Win32 feature always 2006-01-25 11:47 2019-12-08 23:44
Reporter: joolsr Platform: Windows 2000  
Assigned To: jghali OS: Win2000  
Priority: normal OS Version: SP4  
Status: assigned Product Version: 1.3.2  
Product Build: Resolution: fixed  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.6 milestone  
Patch: No
Summary: Network shares unavailable on file open/save dialog
Description: I cannot access network shares when using the Scribus File Open/Save dialog.
With drive letters this is fine.

Many companies now use network shares rather than drive mappings. Unless I map a drive I cant access the server even when entering \\servername in the dialog.
Tags:
Steps To Reproduce: When trying to save or load an export a file, cannot access networked files shares, even when typing in \\servername\path
Additional Information: This is also a problem with the Gimp and programs that use the Win32 GTK interface. There is a Gimp file open/save plugin buts its not ideal by any means.
Attached Files:
Notes
(0008338)
jghali   
2006-01-25 13:50   
(Last edited: 2006-01-25 13:51)
First Scribus is not a GTK application, it's a Qt application :)

The described behavior is a limitation of the Qt file dialog and on which our file dialog class is based. One possibility is to use the get*Name static methods where possible. On Windows, these methods are using the native Windows file dialogs instead of the qt one. Will have a look asap.

(0011835)
joolsr   
2006-07-10 15:33   
Hi

Is there any chance at having another look at this Jean?

There is a bigger problem, that if you save a file with the linux version and then try and open it with the Windows port that the paths are different, and images do not show up, as the path created under Linux doesn't mean anything to Windows.
I tried mapping network drives, but this is messy; exactly the reason we now use network shares instead on our samba server to windows clients.
But we still have a lot of difficulty accessing scribus files properly.
(0011838)
jghali   
2006-07-10 18:09   
Solving this issue requires a network enabled file dialog class. Considering the amount of work needed, i have no time for that now. Using QFileDialog static methods is not a solution for consistency and functionnality reasons.

When saving files scribus uses whenever possible relative paths, so if you have properly organized your files, opening a linux document with the Windows port should not be a problem.
(0011850)
joolsr   
2006-07-11 08:23   
Thank you for your quick response. I do appreciate and fully understand your time constraints. I'm sure it wouldnt be straightforward to get network shares working natively with qt.

But, other programs such as the Windows port of the Gimp, has a plugin that allows you to use the std windows open/save dialog boxes. This of course allows me to use network shares.
Inkscape (Windows) again has the same problem.

I do appreciate that Scribus is primarily designed as a Linux application, but I do know the developers are keen to offer Mac and Windows versions.
Is there any way that a combined, improved Windows file open/save dialog could be developed for the good of the many Windows ports of Linux applications that have the same issue?

Please understand that I am a Linux user through and through, I have been using it as my only OS at home since 2000, but at work Windows is more prevalent, and without the means to open or save files, its going to be difficult to offer it as a solution to many people.
(0022124)
joolsr   
2009-07-06 14:45   
Just a note, in 1.3.5 RC3 on Windows, you cannot browse a Network Neighborhood or any such thing, BUT typing in \\server\share works fine.

This in itself is quite a help
(0027917)
vmurmann   
2012-04-11 06:31   
(Last edited: 2012-04-11 06:34)
workaround windows:
1. Open scribus file on network-share with doubleclicking the file
2. Make "save as"
>> the networkshare is shown
3. Now the networkshare will be shown in other dialogboxes like import picture etc. too

(0034419)
Kunda   
2015-02-02 01:13   
Reminder sent to: jghali
Is this still an issue?
(0034436)
Kunda   
2015-02-04 13:16   
According to this tester (https://plus.google.com/u/0/b/109612024486187515483/109612024486187515483/posts/ZtUvDDfshpW) this is non-issue

"Once I type in "\\servername" in the filename field, I can access the network share to open and save files.
Tested with Scribus 1.4.5 on Windows 7 64bit.?"
(0034437)
Kunda   
2015-02-04 13:17   
Marking as resolved with the intention to close
(0034440)
Kunda   
2015-02-04 13:46   
Needs to be tested on 1.5svn as well
(0034443)
JimmyVolatile   
2015-02-05 09:00   
* I can confirm that 1.4.5 on Win 8 64-bit can access typed in network share paths i.e. "\\servername\folder".

* I can not access mapped drive letters: "H:\"

* I can not access paths containing $ as in "\\servername\folder$"

Scribus Version 1.4.3
20 July 2013
Build ID: C-*-T-*-C1.8.6-Windows-64bit
Using Ghostscript version 9.10
(0034444)
Kunda   
2015-02-05 12:45   
Reopening, thanks JimmyVolatile
(0037919)
kahu   
2015-12-15 00:44   
Seeing this too still.

Scribus Version 1.5.0svn
19 May 2015
Build ID: C-*-T-*-C1.12.18-Windows-64bit
(0037920)
Kunda   
2015-12-15 02:05   
jghali, is this a qt file dialog issue ? (Ref 0008724:0023198)
(0037928)
Kunda   
2015-12-16 21:01   
added a relationship to 0007663


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15992 [Scribus] PDF feature always 2019-12-07 21:23 2019-12-08 12:12
Reporter: davidrevoy Platform: Linux  
Assigned To: OS: Kubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [Export PDF] Allow more adjustments for JPEG compression quality
Description: Hi,

== Context ==

I'm doing a big book project (a large 8.5x11'' 200 pages high quality color, big size hardcover for the POD service Onebookshelf (of the fame for DriveThruRPG and DriveThruComic). The project has 200 A4@300ppi CMYK pictures and a Lossless ZIP-compression export weight 2.8GB. While uploading the file on the service, I discovered the publisher had a hardware limit of 800MB for book project. With sadness, I decided I'll have to use compression at export. I wrote "sadness" because a lot of comic speechbubble being raster black text on white background; any small JPG compression even 95% produces a slight unperceptible gray pixels that do not print well and produce slight fuzzy fonts and not perfect crisp text as I like (a flaw I see often from other publishers, especially webcomic on paper coming from online JPGs ). Unfortunately, taking the compression route was hard because Scribus doesn't propose a lot of options, or I should say, "doesn't expose to the user" a lot of option...
Tags: compression; pdf; jpeg; jpg; lossy; export; x-1
Steps To Reproduce: == Problem ==

As now in 1.4x or 1.5x; One can set [Compression Method] in various presets and get info about what they do reading a tooltip (nice).
"Maximum" = 95%, "High" 85% (outch! really destructive) while "Medium" goes to not usable 75% ( meh... really printing JPGs at 75% compression, who want that?).

This wasn't helpful for my project. 95% compression still produce a too big file for the filesize budget of my printer (not by much, around 900MB); while the option under 85% are all too destructive and produces way too much noises for my art and text (and also start to decimate the color palette)...

If I could set it to 93%, I'm almost sure I would fit the budget and keep a reasonable amount of compression artifact. Also, I really think Maximum should be 100%, and then propose only from 100% to 90% (JPG starts to decimate color palette and really have perceptual issue under 90%, I personally would think that's too dangerous for a printed project)
Additional Information: == Proposal ==

I would sincerely appreciate a slider widget here from 0 to 100 as one can find on JPG export of almost all apps (or a numeric field, 95% is a sane default, imo and according to a study I ran about JPG and perception of noise. Article: https://www.davidrevoy.com/article532/file-maintainance-optimising-the-hi-res ).

== Workaround ==

If I read correctly, the value array are stored in "int qual[] = { 95, 85, 75, 50, 25 };" in /scribus/scimage.cpp at line 1208. One can still change the hardcoded values here, compile and export. Not really convenient, I couldn't test because my printer wants 1.4x and I have also proofreader and betatester opening the file with 1.4x...

The things I did: export lossless (2.8GB) at first and then run ghostscript to recompress all pictures inside the PDF; but this is dangerous because it might change subtle bit in the PDF compliance (eg: PDF X-1 standard, my printer complained my file wasn't PDF X-1 standard, but complained also for the cover of my book that was exported directly from Scribus so I'm not sure I should blame Gs here).

Here is my oneliner after many trial and error that compressed the result to 768MB for JPG 97% compression:

gs -sDEVICE=pdfwrite -dPDFX -dCompatibilityLevel=1.3 -sOutputFile=out.pdf -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -dPDFSETTINGS=/prepress -c ".setpdfwrite << /ColorACSImageDict << /VSamples [ 1 1 1 1 ] /HSamples [ 1 1 1 1 ] /QFactor 0.13 /Blend 1 >> /ColorImageDownsampleType /Bicubic /ColorConversionStrategy /LeaveColorUnchanged >> setdistillerparams" -f

QFactor 0.13 manages the CMYK JPG compression around 97% (0.15 is roughly similar to imagemagick 95% or Scribus "Maximum" and down 0.08 is almost JPG imagemagick 99%/100%: I extracted the picture from the PDF with libpoppler-utils CLI tools and then compared the noise with Imagemagick to get this results).

So with this workaround I was able to get better compression (less artifact) while getting smaller file-size. ( I think this test, and the documentation https://wiki.scribus.net/canvas/Reduce_the_size_of_Scribus_generated_PDFs reveals a problem with too gigantic PDF size, but that's another issue).

That's all, sorry if it was long. but I thought it was better to tell the full story maybe and share all I tried and experimented around this issue, hoping to see a fix for that in future generation of Scribus! :-)
Attached Files:
Notes
(0047211)
ale   
2019-12-08 12:00   
salut david

i've created a scribus branch in my repository where you can test different jpg values.

https://gitlab.com/a.l.e/scribus/tree/pdf-jpg-compression-playground

you need to set a value in file > preferences (not the document settings) and that value will be used by the pdf exporter to create the jpgs.

i've tested the two values 0 and 100 on a .sla with 1 single jpg image in there and the difference was very visible.
you can do the same test to see if the patch also works on your images.
if it does not, can you please send me a .sla with one image of yours so that i can adapt the patch?

the patch is not meant as a solution, but as a playground for you to test different compression levels, see if it's worth to ask scribus to have more, more flexible or different compression levels.

for the next week you will be able to download an appimage with the patched branch at this address:

https://gitlab.com/a.l.e/scribus/-/jobs/372751691/artifacts/file/Scribus-nightly-x86_64.AppImage
(0047212)
davidrevoy   
2019-12-08 12:12   
Merci ale!

That's so cool for the Appimage (and presence on Gitlab! even if I understand it is not official and your account only). I'll test it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
10868 [Scribus] Story Editor / Text Frames minor have not tried 2012-07-12 13:13 2019-12-06 17:47
Reporter: JLuc Platform:  
Assigned To: Chelen OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: 3states selectors for search dialog
Description: if searching for text with some glyphstyle characteristics like bold or italics,
it is (or would be) usefull / powerfull to use 3-state selectors (buttons or checkboxes).
For example a 3 states search bold caracteristics can have 3 type of search behaviour :
- yes = found text has to be bold
- no = found text has to be not bold
- not active or grayed = dont mind bold state during the search

This is because when not having that grayed inactive selector state it is sometime not possible to search desired text sometime unless this third (grayed = not active selector) state ability exists.

Tags: search
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14862 [Scribus] Typography feature always 2017-06-12 08:52 2019-12-05 16:20
Reporter: KrasnayaPloshchad Platform: Windows 10  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Graphite layout does not works
Description: SIL produced Awami Nastaliq font (http://software.sil.org/awami/) for Nastaliq-style Arabic script, this font require Graphite support fot text layout, but when I try use it in Scribus, the font does not works as expected.
Tags:
Steps To Reproduce: 1. Open Scribus & create new document
2. Insert a text box
3. Right click to edit with Story Editor:
4. Insert a paragraph from Urdu UDHR
5. Set font as Awami Nastaliq Beta 3 Regular
6. Done
Additional Information: After I exit Story Editor, no letters joined.

To fix this bug, you have to intergrate Graphite2 engineinto Scribus, and making Graphite features works in the document.
Attached Files: Urdu UDHR.sla.gz (4,217 bytes) 2017-06-12 08:52
https://bugs.scribus.net/file_download.php?file_id=9675&type=bug
Screenshot.PNG (119,463 bytes) 2017-06-12 08:52
https://bugs.scribus.net/file_download.php?file_id=9676&type=bug
Notes
(0044029)
KrasnayaPloshchad   
2017-06-12 08:54   
On this page SIL provided resources related to adding Graphite support to Scribus.
http://scripts.sil.org/cms/scripts/page.php?site_id=projects&item_id=graphite_devApp
Also, HarfBuzz is allowed to build with Graphite2 engine.
(0044030)
jghali   
2017-06-12 09:51   
(Last edited: 2017-06-12 09:53)
We have already made test with Harfbuzz graphite support. There are currently some difference on how Harfbuzz graphite engine provides results compared to the Opentype engine and amongst other things this triggers issues with OpenType fonts which contains both OpenType and Graphite features. As of now Graphite support is completely disabled in Scribus and Harfbuzz explicitly instructed not to use its graphite engine.

(0044031)
KrasnayaPloshchad   
2017-06-12 09:58   
Is there anyway to enabling Graphite in Scribus? Firefox has an option to enable Graphite at about:config page: gfx.font_rendering.graphite.enabled
(0044032)
jghali   
2017-06-12 09:59   
Notice also we have not advertised Graphite support in 1.5.3 release note, only OpenType is mentionned:
https://wiki.scribus.net/canvas/1.5.3_Release
(0044033)
jghali   
2017-06-12 10:03   
(Last edited: 2017-06-12 10:05)
>> Is there anyway to enabling Graphite in Scribus? Firefox has an option to enable Graphite at about:config page: gfx.font_rendering.graphite.enabled

There is none because, as mentionned in my previous notes, we completely disabled Graphite in Scribus as it cause issues with some OpenType fonts. And as of now the layout would be incorrect anyway if we were to use Harfbuzz Graphite engine. We have to make code changes before we can use Harfbuzz Graphite engine.

(0044037)
KrasnayaPloshchad   
2017-06-12 14:31   
So what’s wrong with Graphite layout?
(0044040)
jghali   
2017-06-12 16:07   
See for eg 0014523. With recent Harfbuzz and same font, Graphite layout triggers different issues like bad line alignment, unexplained indentation.
(0047039)
munzirtaha   
2019-11-09 00:20   
Since harfbuzz bugs are fixed, shouldn't Graphite support be enabled now?
Any thing remaining?
(0047040)
jghali   
2019-11-09 02:23   
That has to be tested, however this harfbuzz commit might have indeed fixed quite a few of our problems:
https://github.com/harfbuzz/harfbuzz/commit/731b13e4e9190a45e51f855f19e88869a7718d43
(0047198)
mjames   
2019-12-04 19:34   
I just started using Scribus for the express purpose of using Awami Nastaliq, and eventually ended up at this bug report.

I'd be quite interested in testing a new build for bugs if some can re-enable graphite or explain to me how to do it.
(0047199)
Fahad   
2019-12-05 05:30   
If there is a tab for experimental features in preference dialog it will be great. So we can flag all non-complete or not well-tested features there and give people the option to enable them.
(0047203)
ale   
2019-12-05 16:20   
0015987 is proposing a new preferences section for enabling experimental features


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14721 [Scribus] Typography text always 2017-04-06 19:55 2019-12-05 09:22
Reporter: Eneen Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.3.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Orphan control doesn't seem to work.
Description: Widow control works fine, but orphan doesn't seem to. Take a look @ screenshot
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: window_orphan_bug.jpeg (211,435 bytes) 2017-04-06 19:55
https://bugs.scribus.net/file_download.php?file_id=9547&type=bug
window_orphan_test.sla (22,066 bytes) 2017-04-06 19:55
https://bugs.scribus.net/file_download.php?file_id=9548&type=bug
Notes
(0047201)
Fahad   
2019-12-05 09:22   
I tried to understand what is the problem. As far as I understood the code, there are two functions dealing with Orphan & Widow which are:
moveLinesFromPreviousFrame() => this only for frame to frame
adjustParagraphEndings () => called at the end of a frame or column

to fix this problem we need a new function moveLinesFromPreviousColumn() and introduce a new var maxColumnChars to store max chars in one column and works similar to m_maxChars to text frame. Then copy moveLinesFromPreviousFrame()'s logic in moveLinesFromPreviousColumn().

Unfortunately, my laptop takes almost one hour for any change in pageitem_textframe header file and I don't have free time these days. I wrote this analysis hoping somebody can implement it since it is a handy feature.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14121 [Scribus] Story Editor / Text Frames major always 2016-05-30 12:51 2019-12-04 18:29
Reporter: SimonL Platform: 64 Bit  
Assigned To: OS: Windows  
Priority: normal OS Version: 7  
Status: confirmed Product Version: 1.5.2  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: Future Release - High Priority  
Patch: No
Summary: VariableText-Marks get repeated on linebreak
Description: When using Variable-Text-Marks, linebreaks behave wrong (see attached screenshot).

1. When there is enough horizontal space, everything is fine.
2. When the text textframe is horizontally smaller than the text, the text gets repeated over and over
3. When the current textline is mostly used by other text (but the next line has enough space) the linebreak appears correctly, but aditionally, the variable text is shown partly in the old line
Tags: #please_test, marks
Steps To Reproduce: Create a new document, insert a textframe. Enter it and add a variable text mark
(Insert->Marks->Variable Text) with some text.

Make your textframe smallen and bigger to see behaviours 1) and 2)

Insert some normal text before the textmark to see behaviour 3)

Additional Information: There are also no linebreaks on whitespaces in textmarks (if intentional, please add a checkbox to make this optional)
Attached Files: 2016-05-30 14_34_09-Scribus 1.5.2 - [Document-1_].png (38,924 bytes) 2016-05-30 12:51
https://bugs.scribus.net/file_download.php?file_id=8915&type=bug
BugDemo_VariableTextMarkGetsRepeated.sla (16,453 bytes) 2016-12-20 17:51
https://bugs.scribus.net/file_download.php?file_id=9334&type=bug
variable-text.sla (14,663 bytes) 2019-12-04 18:29
https://bugs.scribus.net/file_download.php?file_id=10796&type=bug
Notes
(0043104)
Kunda   
2016-12-19 13:41   
@SimonL to expedite this ticket, can you upload a sample SLA for the devs to check? Thanks!
(0043115)
SimonL   
2016-12-20 17:53   
@Kunda Hope this demo-file helps. Just drag the right side of the top text-field between the two marked positions to see the problem.

File Created in Scribus 1.5.2 (64 bit)
(0043133)
FirasH   
2016-12-21 21:00   
Confirming the issue. With the provided file:

1.5.1) Does not show any text
1.5.2) Gets repeated vertically
1.5.3.svn) Part of the text is placed on one line and the other on the latter (also splitting the same word between the two)
(0047197)
ale   
2019-12-04 18:29   
on top of it, line breaks inside of the variable text are not correct.

in the attached document ,the text should say "this is a very long variable text which does not break correctly." ...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15724 [Scribus] Story Editor / Text Frames feature N/A 2019-06-26 13:49 2019-12-03 17:45
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.5.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: make the unlink tool a single click one
Description: currently, the unlink tool is only active when at least a text frame is selected.
for the action to take place, one need to click on a second frame.

i did not test the behavior when multiple text frame are selected but it's a rather awkward situation.

i suggest that the behavior to be changed in the following way:

- the tool is inactive when no text frame is selected
- when one single text frame is selected, the link to the next frame is removed (if any)
- when multiple text frames are selected, the link between the selected frames are removed
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047088)
ale   
2019-11-16 09:30   
we could even keep it enabled when no item is selected and it will unlink the next tool you click on from its next item.
(0047194)
ale   
2019-12-03 17:45   
if multiple text frame are seleted, enabling the tool could simply link all the selected items, starting from top left.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15984 [Scribus] User Interface minor always 2019-12-03 09:48 2019-12-03 09:48
Reporter: Vynce Platform:  
Assigned To: OS: MacOS  
Priority: normal OS Version:  
Status: new Product Version: 1.5.4  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Hatch angles restricted
Description: The hatch angles are restricted to range 0 to 100 degrees. This is silly, since obviously that means that there are some angles that cannot be attained. Also, really, angles in general should be able to range from at least -180 to 360 just so that people can use whatever format makes the most sense for their situation.
Tags: #easyhack
Steps To Reproduce: create a shape.
choose fill - hatch
type 135 into the angle box
it is truncated to 100

Additional Information: editing the underlying .sla file yields the expect results (ie., setting the angle to 135 draws what i expect to see)
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
13978 [Scribus] User Interface minor always 2016-04-23 21:04 2019-12-01 19:44
Reporter: PeterBenedek Platform: x86 and x64  
Assigned To: cbradney OS: Linux Mint  
Priority: normal OS Version: 17.3 (64bit)  
Status: assigned Product Version: 1.5.2.svn  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version: 1.5.3.svn  
    Target Version: 1.5.5  
Patch: No
Summary: Regression: Docked palettes position is not saved between sessions (0011544)
Description: Antecedent: 0011544

- Open three docked panel (Windows -- Properties, Laers, Align and Distribute)
- Open Windows -- "Arrange Pages" panel
- Dock "Arrange Pages" panel
- Close "Arrange Pages" panel
- Close Scribus
- Open Scribus (New empty document)
- Edit -- Master pages

"Arrange Pages" panel cause confusion
Tags: indigodock
Steps To Reproduce:
Additional Information:
System Description Scribus 1.5.x
Attached Files: ArrangePages.png (19,759 bytes) 2016-04-23 21:07
https://bugs.scribus.net/file_download.php?file_id=8597&type=bug
output.gif (648,691 bytes) 2019-12-01 19:21
https://bugs.scribus.net/file_download.php?file_id=10793&type=bug
Notes
(0040416)
Kunda   
2016-04-24 00:01   
Perhaps related to 0013808 ?
(0040467)
Kunda   
2016-04-25 12:09   
punting to Franz since seems related to 0011544
(0040756)
Kunda   
2016-05-04 05:31   
0009719
0009707
0010623
are all related to this ticket.
(0040814)
fschmid   
2016-05-06 07:24   
Made some improvements, but these require you to build with Qt-5.6.x
(0040868)
Kunda   
2016-05-07 13:17   
Franz, does r21295 have any affect on 0009719 / 0009707 / 0010623
(0040892)
Kunda   
2016-05-09 03:29   
Peter, please retest with latest trunk. Thanks!
(0040894)
PeterBenedek   
2016-05-09 07:44   
(Last edited: 2016-05-09 07:47)
Tested: r21298

Umph...!

Two problem:

1)
- Must be open 3 tab
- Close Scribus
- Open Scribus

Comment: Scribus forgot window last setting. If was exiting full screen, the window on startup too high, and not fullscreen!


2)
- Open Scribus
- Must be open 3 tab
- Add new tab (e.g. Action History, Outline, etc.)
- If new tab so far was not included tab list: Scribus forgot window last setting. Scribus window too high, and not fullscreen!

(0043597)
cbradney   
2017-03-14 21:14   
Please test now. Seems ok here on Ubuntu 16/17/Windows/OSX
(0043606)
PeterBenedek   
2017-03-15 09:04   
Unfortunately does not work.

Look: https://youtu.be/IJBKYfjy7K4
(0047181)
PeterBenedek   
2019-12-01 19:21   
(Last edited: 2019-12-01 19:22)
I did the tests again. I can't reproduce the original question, but in one case the scribus still does not work properly.

-- Unpin all windows in Scribus window
-- Close all Windows in Scribus (Properties, Content Properties, Action History etc.)
-- Open Properties, Content Properties, Outline
-- Pin the Properties and Content Properties
-- Close Content properties
Now...
-- Pin Outline above the Properties window
-- Click: Windows menu -- Contet Properties

Result: Disappear the "full screen" scribus window controller and the scribus window will be larger than the vertical size of the screen.

(0047183)
PeterBenedek   
2019-12-01 19:42   
(Last edited: 2019-12-01 19:44)
Perhaps can solve the problem if the Scribus does not allow in docker the resizable window to be placed above the fixed window.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15979 [Scribus] User Interface minor always 2019-12-01 17:55 2019-12-01 17:55
Reporter: herzenschein Platform:  
Assigned To: OS: Linux  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: List in Preferences is too small for localized strings with Breeze and Oxygen themes
Description: The Preferences dialog contains a list of settings on the left side and their respective settings on the right.
The list on the left should be larger by default so that localized text does not break or fail to show fully when using a not-so-compact theme like Breeze or Oxygen.

Strings do not break under Fusion or Windows, Oxygen only has Table of Contents broken, Breeze has both Table of Contents and Image Cache.
See attachments. Note how just by resizing the window a bit and consequently widening the list, both Breeze and Oxygen render correctly.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: OxygenCorrect.png (96,331 bytes) 2019-12-01 17:55
https://bugs.scribus.net/file_download.php?file_id=10791&type=bug
BreezeCorrect.png (77,843 bytes) 2019-12-01 17:55
https://bugs.scribus.net/file_download.php?file_id=10792&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15978 [Scribus] User Interface minor always 2019-12-01 17:44 2019-12-01 17:44
Reporter: herzenschein Platform:  
Assigned To: OS: Linux  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Item Tools color QComboBox does not have enough width for strings
Description: Regardless of theme or icons as well as the tab (text, images, lines), the QComboBox field for defining fill and line colors display the names incorrectly due to having less width than the size of their respective strings.

See attachment.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: ItemToolsColors.png (91,133 bytes) 2019-12-01 17:44
https://bugs.scribus.net/file_download.php?file_id=10790&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15977 [Scribus] User Interface minor always 2019-12-01 17:36 2019-12-01 17:36
Reporter: herzenschein Platform:  
Assigned To: OS: Linux  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: QComboBox in Startup Dialog does not extend properly with Breeze/Oxygen theme
Description: The Startup Dialog's QComboBox field for "First page is:" does not have full width, which means that long localized strings do not display properly when using Breeze or Oxygen as application theme. It works correctly with the Windows and Fusion themes.

See attachments for clarification.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: BreezeStartupDialog.png (84,468 bytes) 2019-12-01 17:36
https://bugs.scribus.net/file_download.php?file_id=10786&type=bug
FusionStartupDialog.png (82,623 bytes) 2019-12-01 17:36
https://bugs.scribus.net/file_download.php?file_id=10787&type=bug
WindowsStartupDialog.png (76,598 bytes) 2019-12-01 17:36
https://bugs.scribus.net/file_download.php?file_id=10788&type=bug
OxygenStartupDialog.png (94,876 bytes) 2019-12-01 17:36
https://bugs.scribus.net/file_download.php?file_id=10789&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15970 [Scribus] User Interface minor always 2019-11-28 13:02 2019-11-29 08:24
Reporter: medmedin2014 Platform: Ubuntu  
Assigned To: OS:  
Priority: normal OS Version: 19.10  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Status bar combobox are not following dark theme
Description: When using breeze theme the combobox inside status bar are not following the dark theme
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20191128_135957.png (67,000 bytes) 2019-11-28 13:02
https://bugs.scribus.net/file_download.php?file_id=10768&type=bug
Notes
(0047160)
utnik   
2019-11-29 03:57   
i can confirm at least a part of the problem under macOS 10.14.6:
the actual layer and unit are visible. but the actual page i can't see here as well.
…and with the basepoint indicator in 'preferences' → 'x, y, z' it's the same. i can't see wich point is selected.
(0047161)
ale   
2019-11-29 08:24   
... there is a patch hanging with a new widget for the basepoint...

PPPINNNNNNGGGGGGG : - )


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15956 [Scribus] Scripter feature N/A 2019-11-18 14:39 2019-11-28 17:08
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Letting the scripter access more / all EXIF fields of an image
Description: Scribus does read the EXIF fields of images. But it only reads a few selected fields.

This is ok for the "more info" command, but a user is asking filling the caption of an image with the content of "other" EXIF fields.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scripter-getexif.diff (4,353 bytes) 2019-11-18 14:46
https://bugs.scribus.net/file_download.php?file_id=10749&type=bug
hiker-playmobil.jpg (299,038 bytes) 2019-11-18 14:46
https://bugs.scribus.net/file_download.php?file_id=10750&type=bug
Notes
(0047101)
ale   
2019-11-18 14:40   
Now, that this would be easy to add if Scribus would read all EXIF field.

Is there good reason why Scribus does not read the whole EXIF information?
(0047102)
ale   
2019-11-18 14:46   
for my future self:

- exif.cpp contains the code that reads the EXIF information. with an (out-commented) list of all possible EXIF fields
- in order to find where the data is stored / read, one can start from "context menu > image > more info"
- i attach the diff that adds the getimageexiffield() scripter command
- i also attach an image that can be used to check the extended fields
(0047137)
cbradney   
2019-11-25 21:15   
Patch applied in r23378
(0047139)
jghali   
2019-11-26 01:13   
@cbradney, have you noticed that the new scripter function currently only returns dummy data?
(0047142)
ale   
2019-11-26 13:07   
yep, the patch was just for me so that i did not lose the previous work...

i shortly talked with jean about this and it's not clear why only part of the info is read... probably because it's that part that scribus uses.

adding a "real" libexif would add a bigger dependency (at least for windows and macos), so i can have a look at exif.cpp and see if i can use it to return the other fields too...
(0047158)
ale   
2019-11-28 13:59   
(Last edited: 2019-11-28 17:08)
i will propose a "new" ExifData class.

for the review, here are the main changes:

- rename "ConvertAnyFormat" to "anyAsDouble
- fixed most spacing around the parenthesis
- use a QMap<QVariant> instead of the long list of specific fields
- introduce a getField(QString name) for the scripter (it can also be used by imagedataloaders/scimgdataloader_jpeg.cpp (so that we can remove the many specific functions)
- use floats instead of doubles

to be checked:

- is a QMap<QVariant> fast enough?

tbc



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15972 [Scribus] User Interface minor always 2019-11-28 14:19 2019-11-28 14:19
Reporter: medmedin2014 Platform: Ubuntu  
Assigned To: OS:  
Priority: normal OS Version: 19.10  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Contents of colors and lines and fonts in combobox is not visible in dark mode
Description: When using breeze theme the content of color and line and font combobox in not visible and foreground color is black and should be white.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20191128_151822.png (82,586 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10770&type=bug
Screenshot_20191128_151758.png (63,064 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10771&type=bug
Screenshot_20191128_151742.png (62,507 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10772&type=bug
Screenshot_20191128_151708.png (60,839 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10773&type=bug
Screenshot_20191128_151634.png (151,479 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10774&type=bug
Screenshot_20191128_151556.png (125,292 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10775&type=bug
Screenshot_20191128_151509.png (141,933 bytes) 2019-11-28 14:19
https://bugs.scribus.net/file_download.php?file_id=10776&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15969 [Scribus] User Interface minor always 2019-11-28 12:59 2019-11-28 14:09
Reporter: medmedin2014 Platform: Ubuntu  
Assigned To: OS:  
Priority: normal OS Version: 19.10  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Some icons are not visible in dark mode
Description: In preferences window two icon are not visible when we use breeze theme with dark icons
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20191128_135732.png (91,012 bytes) 2019-11-28 12:59
https://bugs.scribus.net/file_download.php?file_id=10767&type=bug
Screenshot_20191128_150537-1.png (24,814 bytes) 2019-11-28 14:09
https://bugs.scribus.net/file_download.php?file_id=10769&type=bug
Notes
(0047155)
ale   
2019-11-28 13:30   
thanks for the report

it's the only two icons concerned?
(0047159)
medmedin2014   
2019-11-28 14:09   
In properties of objects the arrow is too much black, I think when the item is enabled the arrow shoud be white and when disabled the arrow should be black grayed


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15971 [Scribus] Import / Export minor always 2019-11-28 13:36 2019-11-28 13:45
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: preflight verifier: do not or differently warn when the target is PDF x-1a and there are RGB images / colors
Description: currently, if the target is PDF x-1a and the preflight verifier detects an RGB color it shows an error.
but -- since the color management must be enabled -- scribus will correctly take care of the conversion to CMYK during the export to pdf.

of course, the color will be changed during the export, but this is to be expected, when the color management is enabled and the color space of color or images does not match the output one.

if we really want to warn the user, the message should rather be that the item might not look the same in the output.

the current message is for sure wrong (or misleading) and the user will think that the pdf created will be invalid. which is not true.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047157)
JLuc   
2019-11-28 13:45   
This also happens even if PDF output is PDF1.4
IMO there are 2 sorts of warning :

1) when scribus will convert
a) Warning should only be there when scribus converts the RGB to CMYK, which happens only for some PDF versions (not sure which one : at least pdfx1a).
b) Warning text should warn that "image color space conversion is required by the choosen output PDF version and some colors could be altered"

2) when scribus will not convert
maybe scribus could warn that depending on the later press workflow, some color could be altered ?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14436 [Scribus] General feature N/A 2016-12-09 00:59 2019-11-28 13:43
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: improve the link between the pdf version choice and the preflight verifier
Description: - by default the preflight verifier has a "pick one" default that blocks and
does not show any warnings.
- the choice is remembered and used in the pdf dialog (the two choices should be
synchronized / they should be only one setting).
- when the verifier is launched for pdf creation, only pdf versions are shown.
(not sure if the ps preflight verfifier is really of any use...)
- one can pick in the preferences which pdf version is the default one. then,
that version is used by default instead of asking to pick one.
  (but not in the document settings? it's already in the preflight dialog and in
the pdf export dialog!)

that way, the user would notice that the preflight verifier is something
important and not a nasty window she should click away as fast as possible...

even betterer:

after having picked a version, the list is not directly shown but first comes a
text (in the same place) that explains the restrictions related to the specific
pdf version and ask the user to say ok (with an option to say: do not show
anymore (for this version)).
only after that step the user is shown the list of warnings and can click on
"ignore"... (that way we could avoid some of the "why is x/1-a disabled"
questions... yes, i am a dreamer...)
Tags: PreflightChecker
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047156)
ale   
2019-11-28 13:43   
a few later we are discussing the same problem.

the fact that the preflight verifier is shown before the pdf dialog is an issue.

personally, i really love it, that it's shown the way it is now. but in some cases, it will give useless, misleading or even wrong warnings / errors.

a further idea that has raised: if the setting in the pdf export have changed in a way that it affects the preflight verifier, the dialog could be shown again after the "export" button has been clicked.
the user can ignore and proceed with the export, or cancel and get back to the pdf export dialog.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15968 [Scribus] User Interface minor always 2019-11-28 12:54 2019-11-28 13:30
Reporter: medmedin2014 Platform: Ubuntu  
Assigned To: OS:  
Priority: high OS Version: 19.10  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Disabled and enabled icon in dark mode look the same
Description: When using Breeze theme with dark icon, the disabled icon on toolbar look the same as the enabled ones which makes the work disturbing and I should hover my mouse on each icon to see if it's enabled or not.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20191128_134814.png (58,556 bytes) 2019-11-28 12:54
https://bugs.scribus.net/file_download.php?file_id=10766&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15966 [Scribus] Scripter minor always 2019-11-26 19:05 2019-11-27 15:32
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scripter: copyObject(itemName) only copies from the current page
Description: in the scripter, if you copy an item by using its name, copyObject() will silently copy nothing, if the item is not on the current page.

we should

- document this
- give an error if no item is copied

or, better, allow copying items from any page....
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047154)
ale   
2019-11-27 15:32   
i've dived a little into this...

the issue seems to happen when scribus_copyobject does

currentDoc->m_Selection->addItem(i);

from there it goes to sendSignals() and i would dare to guess that the issue happens when the selectionChanged() signal is received by some part of scribus.

of course, it's sane to check if the item is on the page in the UI... maybe not alwys perfect when it's done from the scripter... : - )

i will try to further dive into that...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15855 [Scribus] PDF minor always 2019-10-16 00:04 2019-11-27 08:50
Reporter: Gibbz Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.5  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: PDF import errors
Description: Import the attached pdf. Notice there are several issues with the import.
It imports fine in inkscape.
Tags:
Steps To Reproduce: import to a new blank document.
Additional Information:
Attached Files: Option 5(1).pdf (1,946,534 bytes) 2019-10-16 00:04
https://bugs.scribus.net/file_download.php?file_id=10634&type=bug
1911.sla (386,738 bytes) 2019-11-25 20:07
https://bugs.scribus.net/file_download.php?file_id=10757&type=bug
colors.svg (49,065 bytes) 2019-11-25 20:07
https://bugs.scribus.net/file_download.php?file_id=10758&type=bug
image.png (419,297 bytes) 2019-11-25 20:07
https://bugs.scribus.net/file_download.php?file_id=10759&type=bug
image2.png (745,124 bytes) 2019-11-25 20:07
https://bugs.scribus.net/file_download.php?file_id=10760&type=bug
image3.png (584,091 bytes) 2019-11-25 20:07
https://bugs.scribus.net/file_download.php?file_id=10761&type=bug
image-2.png (116,461 bytes) 2019-11-27 08:50
https://bugs.scribus.net/file_download.php?file_id=10765&type=bug
Notes
(0046789)
ale   
2019-10-16 06:56   
when opening the pdf, i get a full white wide item.

if i start ungrouping the item, the content starts showing up, one part at a time.

most of the items are there, but they're all a bit screwed...
(0047081)
Gibbz   
2019-11-14 22:20   
I have just found that if I change the fill rule from "Non Zero" to "Even-Odd" on the text shapes, this fixes the fill issues on the text which is curves.
Looks like this may be all that is wrong....
(0047135)
venclj   
2019-11-25 20:07   
I got this error on 1.5.5 and have some new hints.
1) I imported svg to file with a content. Some colors are replaced with one of them (5 browns, see the screenshot, previous colors are in color name) in entire document.
2) Color "None" got brown too. All surfaces and line "without color" are brown.
3) Error did NOT occur when used drag&drop to import svg.
4) The error does not depend on fill rule (mentioned by @Gibbz).

Reproduce:
1) Have a file with some content and colors in it.
2) Import there a svg file with colors. Ungroup it, metge and replace old colors with the imported onces (my way to define new palette).
3) Import the same file once again (I have made several changes in the file, though).
4) Colors are damaged.

Attached screenshots
image.png - second svg just imported. The content and color palette reflect damaged palette state. Colored rectangles are formely imported svg, on the screenshot are not changed yet (not know why, not yet rendered?)
image2.png - little bit later. Even svg content changed to brown.
image3.png - in colors dialog you can see None color as brown.

P.S.: There may be some incorrectness in terminology. I am using Czech locale
P.S.2: Scribus version 1.5.5; 31st July 2019; Build ID: C--T-*-C1.16.0-Windows-64bit; Ghostscript version 9.27
(0047151)
venclj   
2019-11-27 08:50   
Update for #c47135:
After this the brown color passed as default color for fill and stroke instead of None. On a screen there is a new created text frame:


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15967 [Scribus] Scripter feature N/A 2019-11-26 21:11 2019-11-27 07:16
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scripter: add a command for moving an item or the selection to a different page
Description: I could not find any command for moving an item from a page to a different one.

This is an ok workaround, though:

scribus.gotoPage(1)
copyObject('Text1')
scribus.gotoPage(2)
pasteObject()
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
990 [Scribus] Plug-ins feature N/A 2004-08-23 18:12 2019-11-26 21:21
Reporter: walter Platform: NA  
Assigned To: ale OS: NA  
Priority: normal OS Version: NA  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: Future Release - Nice to have  
Patch: No
Summary: Mail-Merge (update: Scribus Generator)
Description: Hello:

None of the info I have read or demos I have seen indicates SCRIBUS has an out-of-the-box simple mail-merge capability - for letters or adress labels (many records per single sheet of paper). I really need this feature - badly. I can do all the pre-filtering with a database product or etc, so the capability only needs to be reasonably simple. I also really don't want to have to learn Python to do this myself -- will take me far too long.

thanks a lot

-Walter
WCMOZART@AOL.COM
Tags:
Steps To Reproduce:
Additional Information: Update (see 0000990:0036128)
https://www.youtube.com/watch?v=kMsRn38TOiQ

Fork of Scribus Generator by berteh on Github:
https://github.com/berteh/ScribusGenerator
He is collaborating with bjarnesvanderberg on Scribus-Data-Merge
https://github.com/bjarnesvanberg/Scribus-Data-Merger

Attached Files:
Notes
(0002196)
subik   
2004-08-23 18:34   
Walter,
that sounds like a job for e.g. openoffice.org (to me).
Maybe one day we will have an_universal_database_connector in scribus but today is the only way the Python Scripter.

I cannot speak in the name of the others but I think you will wait very long time to this ;)

Try to ask at the mailing list - maybe somebody will write script you need exactly for you.
(0002217)
walter   
2004-08-24 20:41   
Hello:

In answer to 'maybe this is more suitable for e.g. OpenOffice' - I have used a very old but truly excellent DTP program - PublishIT Easy (PIE) on my Mac (this is totally different from a PIE which is available on a PC) which many readers may be familiar with. PIE as a company died around 1994, but I still use the program almost every day.

It contains a simple but very very useful GUI-driven mail-merge capability, which I have found invaluable - the input file is nothing more than a simple flat text file, where the first line contains the field names (comma or tab separated), and the other lines contain data. One can do mailings with one record per document/letter, or many records per document/letter (for address labels). One can also step through the records to see what the document/letter looks like when the data is plugged in, and print particular pages accordingly. [Note that the flat file can be easily produced as a result table/simple report from any decent database program, or as a simple export from an Excel spreadsheet.]

I would greatly apreciate this as a plug-in, but do not have the programming experience to pull it off easily - someone really skilled in Python could probably put something quite useful together in 16-24 hours

thanks

Walter
(0002373)
packetbell   
2004-09-14 02:20   
Mail Merge (or database merge, 'cause its pretty useful for a lot of things) would still be nice as a direct feature of Scribus. It could help in generating print catalogs from a database, and it *is* very handy if you use Scribus for any kind of newsletter. I reboot to Windows just to print a monthly newsletter with PageMaker 7, because the layout is too involved for OpenOffice.

BTW--Mailmerge in PageMaker 7 is handled by a (default) plugin. It works like a charm, but it cannot do the merge at print time. Instead, it creates a new document with the merged records. If you have a fairly complex layout, it consumes quite a bit of memory to produce, say, 500 merged records.

So what we want is :)

- Integrated database-merge, with the option to merge to individual pages in a new document, to merge to seperate documents or to merge at print time.
(0005098)
ringerc   
2005-06-23 07:24   
I did a primitive mail merge script in Python a while ago. Now that there is support for PyQt and frame annotations in Scribus, I think a fairly solid mail merge feature could be done in Python.
(0011656)
porter235   
2006-06-17 04:23   
database merge to create new documents or new pages, would be great for some of my projects as well, such as designing playing cards. If I could specify the image to go into the image frame, and the text to go into each text frame, as well as colours etc in a database it would make this type of project much faster, easier, and more precise.
(0012935)
zapletal   
2006-10-12 10:29   
One of my students is considering writing this plugin as bachelor project. Could you help me with more formal specification of the project? Please provide your requerements: functional, not functional or design.

My points: create genral source input for various sources (XML, CSV, SQL database), ability to read Scribus document templates, ability to read information from these sources and print documents (printer, PDF), configuration dialog with source configuration (file, database connection + definition of fields to read + some basic conversions for all fields - e.g. uppercase, lowercase, replace, trim, strip.

Non functional requirements: Python + PyQT for dialogs, the datasource API to be general (to allow use in other plugins or Scribus some day).

Please comment this, thank you.
(0012937)
subik   
2006-10-12 10:57   
Just for terminology:
* "plugin" is C++ code called by dlopen() etc. Dynamically loaded into scribus in start phase.
* "Python script" or "scripter script" is Python script or more files called by "Scripter plugin" (yep, written in C/C++) when scribus is running.

I'm afraid there will be some issues with PyQt due the limitations of the Python sub-interpreters.

I suggest the student should start with "backend" - creating mail-merge from various formats. GUI can be added a little bit later. There is a lot of to do with various RDBMS support.
(0013180)
cbradney   
2006-10-29 21:22   
Proper mail merge *requires* the new text engine. Mail merge has been discussed and will be supported better in 1.3.5 or 1.3.6.
(0013182)
subik   
2006-10-30 07:10   
no problem Craig ;)

Bohuslav Ječmen (the student mentioned above) is working on "scribus independent" python "data getter". We expect a bag of classes to get the data from various sources transformed into documented format (some kind of dictionary or whatever). The scribus integration part will follow and it should be very simple today - with the easy way to replace with something more exact (depending on the NLS).

I think it will be great ;)
(0013276)
jeffz   
2006-11-04 23:36   
subtik,

What do you think about http://bugs.scribus.net/view.php?id=4467
(0025016)
ahappyday   
2010-12-10 14:38   
hey walter,
i missed the Mail Merge functionality in Scribus as well. i have implemented an extension script in Python called SRIBUS GENERATOR which could fit your need. it replaces text with data and it is easy to use with a self-explanatory UI. have a look at: http://www.ekkehardwill.de/sg/
cheers
(0036128)
Kunda   
2015-08-31 12:08   
Update:
Fork of Scribus Generator by berteh on Github:
https://github.com/berteh/ScribusGenerator
He is collaborating with bjarnesvanderberg on Scribus-Data-Merge
https://github.com/bjarnesvanberg/Scribus-Data-Merger

Perhaps these scripts will one day be distributed through Scribus or available through the download manager


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11791 [Scribus] Graphics / Image Frames feature always 2013-10-15 21:52 2019-11-26 19:04
Reporter: pygmee Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.5.4  
Patch: Yes
Summary: [PATCH] Choose directory for missing image
Description: this patch is grabed from cezayece code and display a window to select a directory when a missing image is found on opening file, and allow to relink all image found in the same directory.
Tags: patch
Steps To Reproduce:
Additional Information:
Attached Files: diff_lost_images_on_open.patch (5,974 bytes) 2013-10-15 21:52
https://bugs.scribus.net/file_download.php?file_id=6402&type=bug
Notes
(0030734)
cezaryece   
2013-10-16 19:57   
Wow!!! Thx Pygmee!!!
(0032126)
Kunda   
2014-06-13 00:45   
Added to http://wiki.scribus.net/canvas/Most_Desired_Features#Most_Desired_Features_candidates
(0047128)
ale   
2019-11-24 10:38   
do we really want this or is the recursive search in "manage images" + an error in the preflight verifier renough?

personally, i'm fine with the status quo...
i've never heard of anybody who would have produced a pdf without noticing that the image links were broken.
(0047144)
pygmee   
2019-11-26 17:55   
the purpose is not when producing the pdf, but when open the sla. Of course, we can think the user will check for missing images before producing PDF. I guess the use case is more when people get file without them being collected. Detecting missing image and say "hey! do you want to manage this now ?" or launch the manager can be helpful.
I also know may people not using the verifier because they just don’t understand it.
But it is not the most important feature, just that other DTP software have it :-)
(0047145)
ale   
2019-11-26 19:04   
ok @pygmee i will see if there is an easy way to do it...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15960 [Scribus] General minor N/A 2019-11-22 22:48 2019-11-25 16:45
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: keep the name of items when importing pages
Description: when importing pages from other documents, scirbus should try to keep the same item names..
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047133)
ale   
2019-11-25 16:31   
following the path between the point where the command is given to import a page and the point where the new item is created (with a new name...) gives little chances that the behavior can be changed...

- bool ScribusMainWindow::slotPageImport()
  - loadPage(dia->getFromDoc(), pageNs[0] - 1, false);
- bool ScribusMainWindow::loadPage(const QString& fileName, int Nr, bool Mpa, const QString& renamedPageName)
  - if (!fl->loadPage(doc, Nr, Mpa, renamedPageName))
- bool FileFormat::loadPage(const QString & fileName, int pageNumber, bool Mpage, const QString& renamedPageName) const
  - bool success = plug->loadPage(fileName, pageNumber, Mpage, renamedPageName);
- Scribus150Format::loadPage()
  - success = readObject(m_Doc, reader, itemInfo, fileDir, true, masterPageName);
- bool Scribus150Format::readObject(ScribusDoc* doc, ScXmlStreamReader& reader, ItemInfo& info, const QString& baseDir, bool loadPage, const QString& renamedPageName)
  - PageItem* newItem = pasteItem(doc, attrs, baseDir, itemKind, pagenr);
- PageItem* Scribus150Format::pasteItem(ScribusDoc *doc, ScXmlStreamAttributes& attrs, const QString& baseDir, PageItem::ItemKind itemKind, int pagenr)
  - z = doc->itemAdd(pt, PageItem::Unspecified, x, y, w, h, 1, doc->itemToolPrefs().imageFillColor, doc->itemToolPrefs().imageStrokeColor, itemKind);
- int ScribusDoc::itemAdd(const PageItem::ItemType itemType, const PageItem::ItemFrameType frameType, double x, double y, double b, double h, double w, const QString& fill, const QString& outline, PageItem::ItemKind itemKind)
  - newItem = createPageItem(itemType, frameType, x, y, b, h, w, fill, outline);
- PageItem* ScribusDoc::createPageItem(const PageItem::ItemType itemType, const PageItem::ItemFrameType frameType, double x, double y, double b, double h, double w, const QString& fill, const QString& outline)
  - newItem = new PageItem_TextFrame(this, x, y, b, h, w, CommonStrings::None, outline);
- PageItem::PageItem(ScribusDoc *pa, ItemType newType, double x, double y, double w, double h, double w2, const QString& fill, const QString& outline)
  - int nameNum = m_Doc->TotalItems;
    m_itemName += tmp.setNum(m_Doc->TotalItems);
(0047134)
ale   
2019-11-25 16:45   
the main question: when duplicating / copy pasting an item, do we want to get a new number or the "current item (2)"?

for scripting, the question is only partially relevant (we can always find out what the name of the current / created item.

so, the main use case is when you import a page from a different document and you want the items to have a specific name (that you can use in your script)... or when you duplicate a page...
in such cases, with the current way of simply increasing the number, i don't see a way to know how the single items have been renamed...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15873 [Scribus] Fonts feature N/A 2019-10-24 15:55 2019-11-24 10:32
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Manage moved font files
Description: (among other things) 0011776 asks for scribus to manage moved font files in a similar way as it should manage moved image files.

i clone here that half of the ticket, so that it can be closed when and if a better image management is in place.

the original ticket asks for a way for the user to define where the fonts are placed.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0046853)
ale   
2019-10-24 16:03   
As far I can tell the current status is:

- Scribus will detect on start up the fonts placed in the system's standard paths (~/.fonts, ...)
- Scribus will detect on start up the fonts placed in the pats defined by the user in the preference
- When opening a document Scribus will detect the fonts that are in the same directory as the .sla file or in its subdirectory "fonts" (those fonts are only available for the specific document).
- Collecting for output will place the collected fonts in the "fonts" directory close to the .sla.
- The local fonts are also there for IDML files (but there might be a bug there)

From my perspective there is nothing much to add, except that we might make it possible to configure the name of the "fonts" directory close to the .sla for each document.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12253 [Scribus] Graphics / Image Frames minor N/A 2014-04-21 22:54 2019-11-23 13:27
Reporter: JLuc Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [WIP PATCH] Importing image in non empty frame should preserve scale and position
Description: As of today, scribus resets some image frame properties when importing an image inside an image frame. It does so even if there is allready an image in it, with a scale and other altered properties.
- scale x
- scale y
- X
- Y

Scribus should not reset the properties and shoult at least keep the specified scale.

Beside, as a consequence of this behaviour, preset values for image frames (Preferences > tools> Images) are useless because image frame are created with specified scale, but since they are created empty, they ought to be filled, and scale and xy are reset to 100% and (0,0) when importing an image in it.


Tags: patch
Steps To Reproduce:
Additional Information:
Attached Files: load_image.diff (2,849 bytes) 2014-08-02 12:25
https://bugs.scribus.net/file_download.php?file_id=6840&type=bug
clear-scale.png (58,739 bytes) 2018-09-28 15:32
https://bugs.scribus.net/file_download.php?file_id=10243&type=bug
Notes
(0031755)
JLuc   
2014-04-22 07:21   
(Last edited: 2014-09-02 08:59)
Some more thoughts :

Most of the time, when replacing the content of an imageframe with another image, it's because the 2nd one is felt better, but it has to go roughly in the same place, it is often the same type of image, and the frame properties that were used for the first one are also good for the 2nd one, or, at least, are the best possible base to start with more editing and finetuning.

Preferences provides a way to set default value or behaviour for some options of the various tools. It does this "application-wide" or "document-wide".
---> In an image frame, not reseting (= keeping as is) the scale of the previous image, when replacing this image with a new one, provides a kind of improved "frame-wide" default value for the properties of the frame that are not related with the image file itself. That is meaningfull.

The most required remembered properties are all the related-to-scale properties.
Then there is the rotation : IMO it logicaly should be remembered too. (all the more since it's so much easier to create a new frame from scratch with empty properties than to set all properties to some allready set desired values !)

Note : As for now, the effects are not deleted or reset when importing a new image into a frame. It should be the same for other frame-related properties.

[EDIT :] Other most required to-be-remembered property is offset X and Y.
Other possible one is image effect.

(0033146)
ale   
2014-08-02 12:22   
attached a patch that removes the initialization code from loadImage().

i suggest that we switch the default behavior and if people show that there is a need for (partially) re-initialization of the frame, we can implement it.

jluc is proposing a "cleaning brush" button that would act in a similar way as the same button for text...

but, maybe, no initialization is ever needed... if you want the default values, isn't it easier to create a new frame?
(0033155)
JLuc   
2014-08-02 21:15   
I fully agree with ale.
(0033205)
ale   
2014-08-08 09:21   
any thoughts?
(0033455)
Kunda   
2014-09-02 12:23   
+1
If there is a need (because it makes sense for ones workflow) to set a reset or default settings button I'm +1 for that as well. If that day comes, I suggest that it appear .on-hover over the image a small 'reset' icon in the upper top right or left of the image.
(0041690)
ale   
2016-06-19 16:44   
time flies so fast...
(0041694)
kahaus   
2016-06-19 20:40   
+1

here is my use case scenario ...

Lets say I am taking pictures of a house interior and want to present different moods by switching or dimming different lights in the scene. I put my camera on a tripod. Now I keep taking pictures from exactly the same point with the same perspective. Between the shots I just change (switch, dim, move ...) the various lights. Finished the photoshooting. I got 10 identical shots, just the lighting differs.
Lets make a simple layout for the photos in Scribus. I properly place, scale and crop the first photo in an Image Frame. Now the next photo should be cropped and scaled the same way as the previous one (it has the same point of view and perspective, just the illumination is different). Finally now it would be cool to copy the Image Frame and just replace the image without caring about scale and position.

This is just one example. It applies for any situation, where you want to present various minor changes of otherwise same image. It can be diagram, technical drawing, 3D design and so on.

So for me the default behavior would be that Image Frame remembers the properties of the image and there is a possibility to reset the settings (could be a button in the properties panel or on-hover button on the Image Frame)

... my two cents :)
(0042246)
JLuc   
2016-10-31 17:12   
(Last edited: 2016-10-31 17:15)
AMOF, *some* settings are preserved :
- all image effects are preserved
- scale values are not preserved, but scale X-Y link mode IS ! (that is : the chain/notchained that sets whether X changes should impact Y changes or not)

That is not consistent and should be fixed.

(0042278)
ale   
2016-11-01 12:58   
@kahaus: a sensible use case but...

... but, i wonder if your case is that common...

i mean: putting much effort on getting a big bunch of picture to be "the same" and then not edit them in Gimp to all have the right crop?

if you are preparing your work that carefully you're very likely to have the right size of both the frame and image (and they will be matching :-)

but we should definitively keep your use case in mind!
(0042286)
kahaus   
2016-11-01 18:49   
yeah i see ... it is very likely, that my use case could be sort of rare. it was just an idea.

i do not do a hard crop of the images i put in the layout - some space for maneuvering is usually needed in case the page layout changes later a little bit. it often happens (like changing page borders and so on). if the image has a precise crop and page layout changes, i need to go through all of the images in Gimp, crop them again and insert and scale them again in Scribus. that means basically layouting the images from scratch. doing all the cropping in Scribus (without fiddling in some other software) is very convenient and time saving.

anyway, i am very thankful for your response and very much appreciate what all of you have achieved so far - big respect. keep up the good work!

Thanks! K.
(0043372)
brewsky   
2017-01-17 15:46   
+1
At the architects office I work we use this workflow all the time.
We make many different versions(frequently updated) of the same image (mostly views of 3d-models) that are cropped on the page.
Opening every single image for editing in gimp takes much time.
This is the only reason that indesign is still partly used.
(0045486)
ale   
2018-09-28 15:32   
scribus should not the position and scale when loading an image...
i'm not sure if there is ever a need for clearing those values (on top of being able to zero them with a few clicks and keystrokes in the properties palette)...
... but, to be sure, let's do a button for it.

i will soon upload a new revision fo the patch above that:
- does not clear the position and scale when loading a new image
- clear them when the button is pressed.

please, review and -- possibly -- accept the patch as soon as it is uploaded... don't let it rot for four more years...
(you've even been warned in advance...)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15133 [Scribus] Properties Palette minor always 2018-02-06 07:43 2019-11-22 08:05
Reporter: u ltd. Platform: amd64  
Assigned To: ale OS: alike debian  
Priority: normal OS Version: 9  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: Stress-free duplicate name handling in xyz-propertiespalette (and explicitely allow - as part of name.)
Description: When you enter a duplicate name in the name field of the XYZ properties palette, you get a MessageBox and then the focus is set back to the field, but eventually the new wrong name is set back to the old unique name.

This is annoying for complex names when you made some small typo. After the field got set back you start from the beginning.

Solution: (Patch attached) Set the background color of the wrong name field to red, but leave the wrong name. This way you can fix the typo and you are done. If you don't know what the old name was, you can "escape" by deselecting and selecting the object.
Tags: gui, UI
Steps To Reproduce:
Additional Information:
System Description Consisting of packages from debian Jessie, debian Stretch and debian Sid.
Attached Files: scribus-20180205-095552-jonas-nameproperty.patch (2,418 bytes) 2018-02-06 07:43
https://bugs.scribus.net/file_download.php?file_id=9969&type=bug
Notes
(0047111)
ale   
2019-11-22 08:05   
i've been changing a few similar situation in scribus by simply adding a (1) at the end.
no warning or other complex handling.
it's easy enough to replace the (#) at the and fix the name to be unique.

as soon as the xyz and advanced section patches are in, i will make a patch for this.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15958 [Scribus] - feature N/A 2019-11-20 13:21 2019-11-20 13:21
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Get "Group clips content" to work with imported vectors and the "Crop to" option
Description: When importing a Pdf, I can choose to crop it to a few different page boxes.

But this seems not to have any effect on what Scribus will be showing on the page.

Playing with the the group shape and "Group clip content" seems to suggest that Scribus is using the correct box, but then it scales the full content to the box. Instead of leaving the marks outside of it.

Currently, there is no way to "correctly" resize a group so that "Group clips content" will show some specific area of the group. Finding a way to do so, will probably solve the import issue.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8056 [Scribus] Import / Export major always 2009-05-18 00:34 2019-11-18 09:47
Reporter: renm Platform: Linux  
Assigned To: ale OS: Ubuntu x86_64  
Priority: normal OS Version: 9.04  
Status: assigned Product Version: 1.3.5svn  
Product Build: C-C-T-F-C1.8.6-64bit Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.5.4  
Patch: Yes
Summary: [WIP PATCH] Import pages with linked text frames breaks the links
Description: Try to import the pages from other sla file (create new pages in current sla) and find out the result pages do not look exactly like the original.

After imported, the linked text frames lose the link at the page boundary. The original 'indent' paragraph breaks between pages, and at beginning of the 2nd page, the text will start with 'indent' style text as a new paragraph (the original would be continue text flow).

Workaround is to relink all of them manually. For 1.3.3.x, you have to change the first paragraph on each of the following pages to 'non-indent' style to mimic the original layout since there is no way to relink the filled frame in version 1.3.3.x.
Tags: #rottenpatch
Steps To Reproduce:
Additional Information:
Attached Files: 2page with linked frames to import.sla (17,562 bytes) 2014-02-23 13:18
https://bugs.scribus.net/file_download.php?file_id=6572&type=bug
jl_importlinks_2.diff (6,060 bytes) 2014-02-25 11:33
https://bugs.scribus.net/file_download.php?file_id=6576&type=bug
import-textchain-secondstep.diff (12,169 bytes) 2019-11-18 09:45
https://bugs.scribus.net/file_download.php?file_id=10748&type=bug
Notes
(0027015)
JLuc   
2011-10-13 10:34   
(Last edited: 2014-02-23 13:19)
I dont get that 'Indent' problem.

http://bugs.scribus.net/view.php?id=10316 (Fixed) describes in details various faulty SLA Import behaviours. Beside unlinking of text frames, 2 phenomenons happen in some cases : - loss of elements in the masterpage (not imported) - all linked frames are imported twice : once linked but empty, 2nd not linked but with text in first frame.

(0029770)
JLuc   
2013-01-27 16:56   
Same with 1.4.3 : linked text frames are not linked in the document where they have been imported.

Besides, it seems that masterpages elements are not imported neither.
(0031294)
JLuc   
2014-02-09 14:47   
(Last edited: 2014-02-23 12:44)
Same with 1.5

0011408 is also related to restoring links between text frames, but when undoing some page delete.

(0031375)
JLuc   
2014-02-23 13:04   
(Last edited: 2014-02-23 13:04)
I upload a sample 2 pages document, with 2 textframes on each page, all of them linked in a 4 frames chain. As a consequence, there is a link on each page and a link that crosses the page boundary.

When imported with "Page(s) > Import" into another document, all frames are imported, the links on each page is imported, but not the link across page boundaries. That's because Scribus150Format::loadPage loads ONE page at a time, with no view of the global job being done.

(0031380)
JLuc   
2014-02-25 01:18   
I upload patch that fixes the issue.
Please test and merge when possible.
(0031382)
JLuc   
2014-02-25 11:32   
(Last edited: 2014-02-25 11:45)
I upload improved version of patch.
It shouldnt change now.

Some explanations :

- a new unknownLinks variable is added to Scribus150Format class. This variable of class QMap gather the links where the destination doesnt exist yet when the link is imported.
Later on, when that frame is imported, it is recognised and the link is created.

- when importaing many pages (for "Page Import" menu action) pageLoad is first called with PageNumber set to -1 so as to clear the unknownLinks set.
When the pageLoad action is finished it is called once more with PageNumber set to -1 : it enables to display a warning message when some links that could not be imported are left (because theyr destination has not been imported). And it clears the unknownLinks that are now useless.

How to test :
- create doc1
- import all pages of doc2 having linked links across pages : links should be imported too (that's the fix !)
- import only one page of doc2 : link can not be imported since destination frame is on not imported page. A nice warning is issued.

(0031404)
JLuc   
2014-02-26 08:56   
(Last edited: 2014-03-06 10:34)
In loadPages, the first call with -1 is meant to be sure to initialise unknownLinks. Since it should be allready empty normally ATM, this "begin" init is not strictly required (but IMO it's not bad to have that "begin" because it balances the "end" -1 call. for example, it might later be usefull for some other loadplugin or some other import page feature to be managed ?).

(0032355)
FirasH   
2014-06-28 14:43   
Same here with 1.4.5.svn (19285) and 1.5.0.svn (19288).
(0032891)
JLuc   
2014-07-21 19:49   
The proposed patch for scribus 1.5 fixes this bug. The proposed patch does not fix the same bug that occur when scribus 1.5 imports some 1.4 document.

IMO This patch should be taken as it is and be merged in trunk as is.
(0033457)
Kunda   
2014-09-02 13:04   
So the proposal with this patch is to implement it for 1.5svn without backporting. Probably will break backward compatibility functionality, right?
(0033460)
JLuc   
2014-09-02 15:31   
(Last edited: 2014-10-11 16:05)
1.5 SLA can not be opened into Scribus 1.4. That's not an issue. There is no backward compatibility issue.

The proposed patch fixes the described issue when importing 1.5 SLA into scribus 1.5. It's not backportable to scribus 1.4 because scribus 1.4 only opens 1.4 SLA and the fix doesnt tackle the import of 1.4 SLA.

(0033503)
Kunda   
2014-09-04 23:23   
(Last edited: 2014-09-04 23:24)
fixed typo in bug summary
Question: Will this patch fix 0011240 ?

(0033976)
JLuc   
2014-10-11 16:06   
(Last edited: 2014-10-12 07:47)
@kunda : This patch fixes the import bug regarding broken links. That's all. It doesnt improve any not-related crash behaviour.

(0035289)
JLuc   
2015-05-30 07:54   
Please merge this patch.
(0047084)
ale   
2019-11-15 10:46   
when reviewing, please make sure that

if (it.key() < m_Doc->Items->count())
    Its = m_Doc->DocItems.at(it.key());

can be converted to

if (it.key() < m_Doc->DocItems->count())
    Its = m_Doc->DocItems.at(it.key());

and please document in scribusdoc.h what's the difference between DocItems and Items...
(0047085)
JLuc   
2019-11-15 11:12   
ale, have you tested the patch ?
Can you confirm it works well ?
(0047086)
ale   
2019-11-15 12:55   
no, jluc, i did not test the patch.

i skimmed through it and noticed that it makes things even more complex.

i've now refactored the Scribus150Format::pageLoad() to be easier to read and changed it to support importing multiple page at a time.

i'm now trying to sort out what are the dependencies in scribus.cpp.

you patch was very useful to find out where i should look at, but adding one more list, that persist among calls (i guess...), did not look like the right solution to me...
(0047087)
ale   
2019-11-15 12:58   
ScribusMainWindow::loadPage() is used by

- ScribusMainWindow::slotPageImport(): we need to add a callback that shows the counter and updates the screen.
- plugins/scriptplugin/cmdpage.cpp: we probably need to have importPage() and importPages()...
- plugins/scriptplugin_py2x/cmdpage.cpp:
(0047100)
ale   
2019-11-18 09:45   
(Last edited: 2019-11-18 09:47)
first part of a new patch:

https://gitlab.com/scribus/scribus/merge_requests/17/diffs

please review it, before i go on with the second part.

- this patch does not change scribus behavior.
- there is some refactoring.
- it adds a "loadPage" that accepts a list of pages instead of a single page.
- before accepting the patch, you need to correctly indent the for loop! in the last commit i've reduced the indent to allow a review of the patch (otherwise, all lines are marked as changed...)

it's loosely inspired by jluc patch.

i also attach the diff for the next step:
- it does not correctly work, yet
- THE ATTACHED PATCH IS NOT THE SAME AS THE ONE IN THE MERGE REQUEST LINKED ABOVE
  and needs the first patch to be accepted.



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15206 [Scribus] General minor have not tried 2018-03-20 14:26 2019-11-18 07:09
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 17.10  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Stronger drop shadow with larger blur
Description: Drop shadow UI proposes a "width of blur" setting.

Problem is :
The wider the blur, the less the shadow's opacity.
As a consequence, a large blur shadow is so thin it's allmost not visible (or not at all visible).

There is no reason why user wouldnt want a strong opacity shadow with a large blur
It should be possible to have large blur AND shadow with strong opacity.

- Do not thin the shadow when blur size increase
- or allow to have more than 100% opacity when it has to be divided by the blur size ?
Tags: drop shadow
Steps To Reproduce:
Additional Information: Uploaded test document :
- with 18mm blur, shadow disappear
- with 4mm blur, max shadow is very thin
- workaround having 2 or 3 same text frame on same position
- with 1,8mm, shadow
System Description
Attached Files: dropshadow and workaround.jpg (54,066 bytes) 2018-03-20 14:53
https://bugs.scribus.net/file_download.php?file_id=10014&type=bug
drop shadow.sla (23,325 bytes) 2018-03-20 14:53
https://bugs.scribus.net/file_download.php?file_id=10015&type=bug
Notes
(0045062)
JLuc   
2018-03-20 14:53   
test document :
- with 18mm blur, shadow disappear
- with 4mm blur, max shadow is very thin
- workaround having 2 or 3 same text frame on same position
- with 1,8mm, shadow
(0047099)
JLuc   
2019-11-18 07:05   
(Last edited: 2019-11-18 07:09)
So as to circumvent this restriction (max value is 100%), i duplicate the shadowed element once, twice, thrice as needed.

Please provide ability to set opacity value up to 1000%.
Of course, maximum resulting opacity would be 100%. A >100% opacity effect would only change <100% opacity value.

Eg 200% effect would result in same rendering as duplicating the element.
resulting (200% of 10% opactity) = 20%
resulting (200% of 60% opacity) = 100%



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15955 [Scribus] General minor have not tried 2019-11-16 15:16 2019-11-17 11:57
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: 1.5.5.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: DEL on a frame that is listed in the preflight checker
Description: Pressing DEL on a frame listed in the preflight checker
(for example because this frame is outside viewport)
shoud delete it.

I thought it was so, but it isnt (anymore)
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
Notes
(0047090)
jghali   
2019-11-16 20:28   
That is still the case, however not for text frames as the action when clicking item in preflight verifier for text frames is now to enter edit mode. In edit mode, DEL will not delete frame. The preflight verifier has never handled such key actions by itself.
(0047091)
JLuc   
2019-11-16 20:58   
(Last edited: 2019-11-16 20:59)
True.
I'll remember that.
But shouldnt text frames maybe behave as image frames do in preflight result list ?
<Click> selects the frame, which enables to move it or DEL it
<Enter> enters edit mode and enables to edit text as now (and could also enable to move an image inside its frame, but that doesnt seem related to preflight checker...)

(0047098)
ale   
2019-11-17 11:57   
entering edit mode when clicking on a text item in the preflight verifier is weird.

i guess it has been changed that way for warnings that need the cursor to go to a specific position in the text frame, but it's still weird...

not a big annoyance, just an astonishing behavior... it's nice, if we can improve that with a simple change, otherwise i can live with it...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15954 [Scribus] User Interface minor have not tried 2019-11-16 11:10 2019-11-16 17:08
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version: 1.5.5.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Improve link/unlink tools usability
Description: The link or unlink tools are confusing because when using them, i never now whether it will work as intended.
There are several various possible behaviours and it's not possible to guess which one scribus developpers have choosen to code, because the UI doesnt show / give hints about it. 2 possible behaviours are : act on link TO clicked frame /or/ act on link FROM clicked frame.

A strong and clear hint would be to highlight what will be done before doing it. E.g. highlight to-be-created-or-deleted link

Proposition :
- Once link or unlink button is clicked, scribus enters link or unlink mode.
- In such a mode, scribus detects on which text frame the mouse cursor hovers and shows which link will be created or destroyed when the user clicks. So as to show which link would be created-or-destroyed, it could simply highlight it. Or mark with some "preview" color .
- when user clicks, the highlighted link is created or destroyed for real.
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15952 [Scribus] General minor N/A 2019-11-15 11:15 2019-11-15 11:15
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: importing a page into a master page?
Description: the code in scribus.cpp

https://gitlab.com/scribus/scribus/blob/master/scribus/scribus.cpp#L3289

seems to be able to import a page into a master page:

    if (doc->masterPageMode())
     {
         if (nrToImport > 1)
             loadPage(dia->getFromDoc(), pageNs[0] - 1, false);
         doIt = false;
     }

but if i look at the UI, importing a page is disabled in master page mode.

i'm fine with removing the code, since one can always import the page in the document and then convert it to a master page.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15951 [Scribus] General feature N/A 2019-11-15 09:40 2019-11-15 09:40
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: preselect the first item when importing from list of master pages
Description: in the dialog for importing master pages, automatically select the first entry.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15939 [Scribus] General feature N/A 2019-11-13 08:14 2019-11-14 19:50
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] apply master page to pages with a given master page
Description: add an option in "apply master page" to apply it to all pages with a specific "master page" (replace master page)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: masterpage-replace.diff (41,323 bytes) 2019-11-14 19:49
https://bugs.scribus.net/file_download.php?file_id=10746&type=bug
Notes
(0047079)
ale   
2019-11-14 19:49   
here is a patch:

- renames ui/applytemplatedialog.* to ui/applymasterpagedialog.* to match what it does *and* the name of the class inside.
- adds masterpage.* with the master utils function i've introduced in 0008115 (so that they can be used by both dialogs; please give feedback in 0015942 so that i can further improve this new file.. and maybe remove a few things from scribusdoc.cpp
- adds an .ui file for the dialog
- do not update the translation for a modal dialog (am i correct that we can extract the translations from the ui file?)
- use a scoped enum class for the page selection types (instead of int)
- allow to apply a master page only to pages with a specific master page

here is the merge request with appimage (soon):

https://gitlab.com/scribus/scribus/merge_requests/16


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15944 [Scribus] General minor N/A 2019-11-14 07:19 2019-11-14 19:35
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: optionally allow the user to replace the current master pages by imported master pages with the same name
Description: when importing master pages it should be possible to ask scribus to replace the current master pages with the same name.

this might not work for the default master pages.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047072)
ale   
2019-11-14 07:26   
somehow, i'm only willing to implement this as a temporary feature until we have a master document mode that keeps resources in sync among documents.

personally, i don't think that it's a good feature, but it might be a useful "hack" until we can do better.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15948 [Scribus] Usability feature always 2019-11-14 13:35 2019-11-14 16:39
Reporter: aliB Platform:  
Assigned To: OS:  
Priority: low OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: versioncontrol integration / collaborativ work
Description: When multiple writers work on the same project, it is very difficult to collect all work and to merge that work into one final document.
In this case git helps a lot. So every writer has its on copy of the doc and he can merge/pull/push.

Unfortunately most writers have difficulties using git. A direct Integration of git (or even github / gitlab et cetera) would result in an outstanding workflow (no other dtp software has this feature)

This is just a very basic idea and maybe worth a further taught.
Tags:
Steps To Reproduce:
Additional Information: feature set:
notify if HEAD has new content
pull, merge, push, commit, revert to head ...
Attached Files: s1.png (93,902 bytes) 2019-11-14 13:35
https://bugs.scribus.net/file_download.php?file_id=10745&type=bug
Notes
(0047078)
ale   
2019-11-14 16:39   
... we haven't migrated scribus itself to git yet...

it would probably be hard to make sure that a git pull cannot scramble your files... and automatic merges can be very difficult... so there should be a think layer that can catch all common conflicts...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15851 [Scribus] Styles minor have not tried 2019-10-13 14:38 2019-11-14 14:54
Reporter: JLuc Platform: Linux  
Assigned To: OS: Ubuntu  
Priority: normal OS Version: 18.04  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Importing character style doesnt import character style
Description: Importing a character style doesnt import the font size correctly, nor some other font's characteristics.

Situation is :
- destination file has no style with imported style name
- imported style depends on default character style (which is not imported)
- imported style is a "medium italic" version of default font

Imported style (in destination file)
- has no "depends on" style
- has 20pt size. When "depends on" is set to "default character style", the size changes to default character style's font size.
- doesnt use the "medium italic" variant, which is strange
Tags:
Steps To Reproduce:
Additional Information:
System Description
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11420 [Scribus] Import / Export major always 2013-02-13 19:31 2019-11-14 14:54
Reporter: JLuc Platform:  
Assigned To: OS:  
Priority: high OS Version:  
Status: confirmed Product Version: 1.5.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: 1.5 style management during page import
Description: [EDIT] The same issue exists when
- copying an object in a document and paste it in another document
- placing an object in the scrapbook and paste it in another document
- importing some page(s) from some other document (0011814)

1.4 tried to cleverly manage styles during a page import - but code was not finished and functionnality was buggy. 1.5 is different but does not better at it.

Uploaded pageimport.sla is a document featuring 3 paragraph :

- 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 correct.

- A paragraph with "default par style" and some local inline character formating (not using style definitions) : this is perfectly imported.
This paragraph includes also a bit of text styled with a named char style : "UserCharStyle". This part of text cannot be read once imported : all letters appear as big squares. + The named style has not been created in the importing document. There must be some big mismatch in the styles defintion and uses.

- A paragraph with a pure user defined paragraph style : UserParStyle, that does not formerly exists in the importing document. It includes both character properties : color, font, effects and paragraphe properties : lineheights.
Strangely, the paragraph looks partly well : color , lineheight, font and font size are ok but "uppercase" text effect has been lost.

- At first it looks like the imported styles have not been created in the document since they dont appear in the style window, but its only a display refresh issue because 2 newly created styles appear sooner or later in the style dialog : a new "default paragraph style" (that make 2 styles with same name; that's a problem) and the imported "UserParStyle".
The defined and used character style has not been imported at all.

- When looking more closely at the UserParStyle, it looks like
1) some of its properties have been copied truthfully (font, lineheight...)
2) some of its properties have been totally ignored (uppercase)
3) for the color of the font, its more complex. At first it appears to NOT have been copied into the style definition, but into the text itself, as inline formatting. But then later on, after some operations, it seems to appears that the style definition sometime changes itself to reflect the original style value.

That's a big lot of important issues that make the functionnality rather hazardous to use.
Tags: MABs, styles
Steps To Reproduce:
Additional Information: - When testing the uploaded docs you'll notice that the import does not position the imported content at its right place : that's 0011411

- this issue was reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778 [^]
Attached Files: pageimport.sla (26,698 bytes) 2013-02-13 19:32
https://bugs.scribus.net/file_download.php?file_id=6133&type=bug
originating.png (202,730 bytes) 2013-02-13 19:34
https://bugs.scribus.net/file_download.php?file_id=6134&type=bug
once imported.png (185,960 bytes) 2013-02-13 19:34
https://bugs.scribus.net/file_download.php?file_id=6135&type=bug
Notes
(0029837)
JLuc   
2013-02-13 20:02   
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.
(0030133)
JLuc   
2013-05-07 19:56   
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.
(0030244)
JLuc   
2013-06-05 15:43   
(Last edited: 2013-06-06 05:08)
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...

(0034350)
JLuc   
2015-01-05 10:00   
(Last edited: 2015-01-05 10:01)
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) ..."

(0035127)
Kunda   
2015-05-14 14:37   
Think we should confirm this bug and set it for 1.5.1
(0036683)
JLuc   
2015-10-16 12:58   
(Last edited: 2015-10-16 12:58)
Also reported by Gary Dale in debian bug system : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800778

(0036684)
JLuc   
2015-10-16 13:00   
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


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
11111 [Scribus] Styles minor have not tried 2012-10-09 16:58 2019-11-14 14:54
Reporter: JLuc Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.4.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Style managing when importing pages
Description: When importing SLA pages into an existing SLA, all used styles are duplicated as "copy of".

However this is not the desired behaviour : sometime the styles are the same and should keep the same so as to enable further editing.

Hence, the import dialog should propose the same options as the "Import Style" dialog : "In case of existing style with same name : rename or overwrite ?"
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0029028)
JLuc   
2012-10-09 17:17   
its a bit more complicated since
- as explained some styles are imported with "copy of" prefix in their name added
- some styles are imported *with the same name* but are *not merged*
- some styles are renamed with "imported from ..." as a prefix (not "copy of...")

so there are 3 different possible naming behaviours !
(0029954)
JLuc   
2013-03-03 22:21   
This bug is related to and more acurately and completely described
in 0011420


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15947 [Scribus] General minor N/A 2019-11-14 09:39 2019-11-14 10:04
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] refactor the master pages import: .ui, file open dialog, separate from page import
Description: - create an ui file,
- file open is triggered before the dialog,
- separate page / master page import

here is the merge request with link to the appimage:

https://gitlab.com/scribus/scribus/merge_requests/15

as soon as this patch is accepted, i would do the same for the page import and remove mergedoc.h|cpp
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: masterpages-fileopen.diff (9,344 bytes) 2019-11-14 09:39
https://bugs.scribus.net/file_download.php?file_id=10742&type=bug
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15943 [Scribus] General minor N/A 2019-11-14 06:55 2019-11-14 06:55
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: use the "name (#)" patter when duplicating things
Description: my proposition is

- replace usage of the getUniqueName() in styles by the one in utils.h.
- replace all usage of the old getUniqueName() in utils.h by the new one.
- track all usages of "Copy of" in the code and use the new getUniqueName() instead.

of course, if the change makes sense in the specific contexts (but i'm comfortable that it will...)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15942 [Scribus] Build System feature N/A 2019-11-13 12:52 2019-11-13 12:52
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: create a new masterpage.h|cpp
Description: the logic for the master pages is currently spread accross scribusdoc.h|cpp and ui/pagepalette_masterpages.h|cpp.

we should create a new masterpage.h|cpp that would contain the logic from both other classes.

this ticket depends on 0015941 being accepted.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8602 [Scribus] Usability tweak have not tried 2009-11-26 23:14 2019-11-13 08:44
Reporter: timClicks Platform: Linux  
Assigned To: OS: Ubuntu 9.10  
Priority: normal OS Version:  
Status: confirmed Product Version: 1.3.5svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.5.4  
Patch: No
Summary: Master Pages don't respect linked text frames
Description: Hi there,

I may be the bug here. Oh well, we'll see what happens.

I created a master page via the Page > Convert to Master Page menu. It was set up with text frames that were linked, so that I could have a regular flow between articles.

The links were not preserved. Instead, the text within the first frame was duplicated over all three.
Tags: linked frames, masterpage
Steps To Reproduce: Create Page w/ text frames
populate text frame
link text frames
convert to master page x
create a new page
apply master page x
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8005 [Scribus] Import / Export major have not tried 2009-05-04 01:31 2019-11-13 08:32
Reporter: Mike Buckley Platform: PC  
Assigned To: OS: Vista Home Premium  
Priority: normal OS Version: 32-bit  
Status: new Product Version: 1.3.3.12  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [OBSOLETE] Page > Import of several SLA files to an existing SLA messes things up
Description: I am not sure this is actually a bug and am reporting it only because Christoph_S thinks it is. He asked me to report it.

I had several SLA files. I used the Page >> Import function to append the second file to the end of the first file. Using the same function, I appended another file to the newly created file. I repeated the process until I had about four files combined into one file. When I reviewed the combined file, features that had been in the original files were messed up when displayed in the combined file.

My hunch is that the problem is <strike>related to the fact that there were several layers that were not common to all of the files.</strike> (later testing shows the bug doesn't seem to be related to layers by OP, see updated comment below)

Problem 1) Text frames that were in the Master Pages of some of the original files were mostly omitted in the combined file.

Problem 2) Many of the text frames that were not in the Master Pages did not display properly in the combined file. I could see the outline of the frame but no content within the frame was displayed. I had to manually click on each frame to display the content.

Problem 3) This is related to Problem 2. When I clicked on the frame to get it do display the content, I had to find the layer it was in because it was not in the same layer as in the original file. It was pure guesswork trying to find the layer that it had been moved to.
Tags: #please_test
Steps To Reproduce:
Additional Information: The files I used are currently proprietary and cannot be submitted for your review at this point in time. However, I may bring this particular project to a halt soon. If so, I will be happy to submit the files at that time.

Update (2009-05-05 05:29): I have now reproduced this issue several times. My above notes indicate that the problem might be rooted in the fact that there are several layers that are not in all files. However, after modifying all of the files so the layers and their order are consistent from file to file, I still can't import files without having a LOT of stuff messed up.

This is so severe that the software is rendered useless when working with a lot of small files that are intended to be combined into one large final product.
Attached Files:
Notes
(0021681)
Mike Buckley   
2009-05-05 03:29   
Update: I have now reproduced this issue several times. My above notes indicate that the problem might be rooted in the fact that there are several layers that are not in all files. However, after modifying all of the files so the layers and their order are consistent from file to file, I still can't import files without having a LOT of stuff messed up.

This is so severe that the software is rendered useless when working with a lot of small files that are intended to be combined into one large final product.
(0037984)
Kunda   
2015-12-24 13:18   
(Last edited: 2015-12-24 13:20)
updated report to not autolink irrelevant mantisbt issue numbers + added OPs updated comment in to summary

(0037985)
Kunda   
2015-12-24 13:25   
Mike, can you by chance provide the SLAs you used to reproduce this issue?
(0047060)
ale   
2019-11-13 08:32   
i'm marking this ticket as obsolete, since it does not list any exact bug nor provide anyway to reproduce anything.

we need specific tickets for each of the suggested issues...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8636 [Scribus] Canvas feature N/A 2009-12-12 23:07 2019-11-13 08:28
Reporter: t8xt Platform: Intel, PPC  
Assigned To: OS: Linux, Mac, Windows  
Priority: normal OS Version: 9.10, xp/vista  
Status: new Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Drag and Drop content placement with media browser
Description: Being able to drag and drop images and text into Scribus with the new Media Browser.
Tags: drag-n-drop
Steps To Reproduce: 1. Create a new document in Scribus
2. Create text and image frames position and size them to your liking
3. Open the Media Browser by going to the menu item Windows > Media Browser
4. Navigate the directory tree in the Media Browser to find the text or images you wish to use.
5. Drag and drop images or text into the frames you have created from the right side window pane. These element will then be inserted into the frames.

Also you will find the "Scrap Book" in the "Media Browser" where you can keep elements you have created in Scribus to quickly drag and drop them in to your documents.

Optionally you can set text to be styled before being inserted into a text frame by setting this feature in the Scribus preferences panel, "File > Preferences > Tools click on the Text button and check Style before Import this will cause the Story Editor to open when you import text from the Media Browser, File menu or by right clicking the text box and selecting "Get Text" from the context menu.

Note that you can right click on any directory in the "Media Browser" and add it to the bookmarks list so that you can quickly navigate to it in the future.

Printing at a outside print house:
If you are having your Scribus publication printed at a commercial service bureau, you will need to collect all elements used in your design by going to the menu item "File > Collect for Output" choose and existing directory or make a new directory to hold all images, fonts and elements used in your publication, Scribus will then copy all these elements to the destination folder you have chosen. Copy this new folder onto CD or and external storage device and take it to your commercial service bureau for printing. You may also want to create a PDF version for printing that will allow elements in your publication not to be altered, check with your commercial service bureau for specification for creating a PDF for printing
Additional Information:
System Description
Attached Files:
Notes
(0022955)
t8xt   
2009-12-13 10:01   
Compiled Scribus version 1.5 tonight. The Picture Browser looks much like what I'm describing above. I would like to encourage the team to take it the rest of the way and make the picture browser handle any media that can be imported into Scribus text, pictures, pdf, styles, pages, master pages .etc. A way to drag and drop styles onto text and image frames from the browser to elements on the canvas would be something very unique, a place to keep user defined style presets and a way to import and export these presets.

I read two Scribus reviews in Linux magazines, Ubuntu magazine being one of them, interesting read. http://www.ubuntu-user.com/Magazine/Archive/2009/2

Awesome work Scribus team!
Have a great weekend
(0047059)
ale   
2019-11-13 08:28   
personally, i'm rather for removing the picture browser from scribus.

to me it looks like a poor man image and file browser.
with an over complex UI.
since i can already drag and drop files from image and file browsers into scribus i never open it.

i don't find anything in there that cannot be done with one of the many existing browsers and the few scribus actions that it contains can do be done better with other "new" scribus features.

of course, it would be wonderful to have a perfect media manager inside of scribus, but other "browsers" have set very high standards and i fear that scribus cannot compete with programs that have browsing and managing has their sole focus.
the scribus development should focus on the interactions with external browser, not in "badly" copying their features inside of scribus.

for sure. if we remove the picture browser, we have to make sure that every action in it can can still easily be done with other tools.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9767 [Scribus] Usability feature N/A 2011-02-22 18:38 2019-11-13 07:55
Reporter: chovynz Platform: windows  
Assigned To: OS: xp sp3  
Priority: normal OS Version:  
Status: new Product Version: 1.4.0svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Master pages - Apply page size toggle
Description: I would like to see a toggle on the Apply Master Page UI.
Check box. Apply page size and margins.

You should be able to choose the default value in your scribus preferences for default behaviour.

Use Case: I have a master document .sla that I import the master pages from. I apply those pages to the current document. I would like the page size to be as the master pages, instead of having to separatly change page properties each time.

Changing page properties is ok for 1 - 5 pages, where this feature is not needed. Changing page properties is not ok for -/+ (20 - 100 documents( x (3-6pages, x (# of master pages)); even if I use Document Setup and apply settings to all pages and master pages, that is still 20 - 100 actions x # of master pages, that I need not do.

Please consider making the toggle. It would greatly save time for and help us large-document-peoples, while still being flexible as now.


Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0025646)
ale   
2011-02-22 22:53   
imo, no neecd for a tgoggle.

applying a MP should also apply its page size' orientation and margins.
(0047057)
ale   
2019-11-13 07:55   
afaict applying a master page does apply the page size...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15935 [Scribus] Properties Palette minor always 2019-11-12 13:37 2019-11-13 01:38
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: the content palette has "huge" minimal height
Description: the content palette has a way to big minimal height.

i cannot shrink to a height which is less than half of the screen.

in an older scribus i can shrink both the properties and text palette (almost) at will...
... any idea where the minimal could comes from?

i did not much more than moving and copying around panels...
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047053)
jghali   
2019-11-13 01:38   
The use of stacked widget in content palette may trigger a difference of behavior. It is likely that the stacked widget will refuse to have its size reduced below the size of the widget it currently shows. At least here, the content palette minimal size varies depending of whether it shows the image properties or text properties.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15933 [Scribus] Properties Palette minor N/A 2019-11-09 19:48 2019-11-10 13:34
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: what to do with the "empty" content palettes?
Description: if the current item does not have a panel in the content palette (or there is no item), scribus shows now a message telling the user what she should.

personally, i feel like scribus is shouting at me.

seeing the current pannel disappear and a text replace it, pulls my attention to it. but there is "nothing" to see.

i suggest that we change the behavior in the following way:

- use the text panel as the default one. it's the most important one in scribus. show it deactivated.
- so, if there is not document active, show the text palette deactivated. as soon as we have content in the page / document panel we can show that palette instead (still deactivated).
- as long as no item has been activated, show the text palette. deactivated (in future the page / document panel as soon as a page is active)
- when there is no item active or the current item does not have a matching panel, keep the latest panel. deactivated.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Snap_to_.gif (434,290 bytes) 2019-11-10 06:51
https://bugs.scribus.net/file_download.php?file_id=10732&type=bug
ContentProperties.jpg (65,272 bytes) 2019-11-10 07:53
https://bugs.scribus.net/file_download.php?file_id=10733&type=bug
Notes
(0047046)
PeterBenedek   
2019-11-10 06:51   
Hi ale

"Manage page properties..." full content of window and a button to the "Manage Guides" window...
.. and would make the job more comfortable the "snap to guides" and the "snap to item" box too.

If are many element in the page, from the popup menu this feature may not be available in all cases or difficult to use.
(0047047)
ale   
2019-11-10 09:31   
(Last edited: 2019-11-10 09:34)
@peterbenedek, can you please move your proposal to 0015879 (Indigo UI: Add a page / document pane to the Content Palette)?

this ticket is about what to show when no matching panel is available and not about what to put in the page / document panel...
(p.s.: you proposal looks sane and i like it, but since it's sooooo hard to remove things from scribus once they have been added, i prefer not to rush adding new meanings to the content palette...)

(0047048)
PeterBenedek   
2019-11-10 10:07   
"this ticket is about what to show when no matching panel is available and not about what to put in the page / document panel..."
I understand this, but...
If no item is available, then the available item is the page. That's why I suggested this.
Content Palette can also mean for me, that the content of the document (a page).
So, my suggestion is not about having a new palette, but what to show when no matching panel (or there is no selected item).

A more useful solution than showing the deactivated text property.
But this is just a suggestion...
(0047049)
ale   
2019-11-10 13:34   
at least for now, there is no panel available when you have multiple items selected.
or one of the different "shape" tools, the bezier curves and lines (will come soon), the calligraphy, the measurement...

you're welcome to leave your suggestion in here. but if the new behavior i suggest is accepted, we will close this ticket and i will not see it when implementing the page panel.

i've been working yesterday with the messages enabled and it was really disturbing. since the text is in the middle of the palette, each time it shows up it draws my attention to it.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15926 [Scribus] Shape Drawing feature N/A 2019-11-07 15:56 2019-11-09 11:36
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: make the node editor slimmer and use it as a toolbar placed at top the shape
Description: the palette should have fewer buttons and become a slim horizontal toolbar.

it should be automatically placed above shape. starting above the top left corner (like the text edit toolbar in gimp) but the user should be able to move it to a different place.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: nodes-toolbar.png (14,667 bytes) 2019-11-07 16:46
https://bugs.scribus.net/file_download.php?file_id=10724&type=bug
Notes
(0047017)
ale   
2019-11-07 16:46   
(Last edited: 2019-11-07 16:47)
some propositions that still need to be discussed:

- RTL people will want it to the top right by default
- we can probably remove the four "shear" buttons (it's trivial to obtain the same effect by selecting two nodes and moving them (with the arrow keys))
- remove the "move nodes" buttons (this should be the default action if nothing has else is active)
- remove the % and absolute resizing of the path (replaced with a widget in the shape panel with left, top, right, bottom margin for the contour (only available if the shape has not been modified))
- add and remove nodes as a single button (by default adding nodes, removing nodes when a mod (shift?) is down)
- remove the rotation widget (use the normal rotation in the xyz panel)
- remove the x, y pos
- delete selected nodes by pressing the del, backspace key
- removing the mirroring of the path (the feature is in xyz, too)
- two and not three buttons for moving the handles symmetrical or not
- progressive ESC (if a node is selected, it should not exit the editing mode, but deselect the node)

some possible feature changes:

- if multiple nodes are selected, it should be possible to move them at once with the mouse (it's already possible to do so with the arrow keys)
- clicking on a line segment to select the neighbor nodes
- moving a line segment bends it (and creates the handles)
- add an option to make the grid start at the top left corner of the shape (local grid)
- allow the creation of closed paths (highlight the starting node, when hovering it; + button for closing the path)


some nice things i've discovered:
- nodes snap! even to items...


i've attached a "quick mockup" of what could be possible...

(0047020)
ale   
2019-11-07 17:40   
from 0009099 (i just discovered but my homonymous basically has already listed most of the points above)

- just edit the handles when clicking on them (no need to activate the tool; we will probably need to change the buttons in the mockup above to actions that create the handles and "makes the node curved")
- remove the ok / cancel button in favor of undo
- adding nodes by double clicking? (i still think that an explicit button is ok to have)

and now i see that scribus can become a bit more friendly : - )

we also need

- a way to delete handles (the del key?)
(0047024)
ale   
2019-11-07 19:55   
currently, double clicking in the edited area will exit the node edit mode. we will have to remove that and replace it by the node creation.
(0047028)
ale   
2019-11-08 06:17   
no need for the "show node coordinates" check box.
just use the x and y of the xyz when one single node is selected.

we "simply" have to add to the xyz pannel:

- a way to only activate x,y and disable w,h
- deactivate the default signal connect
- add a custom connect
- reactivate the default connect when done.

something like

XYZ->activateOnlyXY(this, &xHandler, &yHandler)
XYZ->restoreXYWHDefault()
(0047029)
ale   
2019-11-08 06:20   
the "hide nodes" can also be removed

no need for a special treatment for the nodes.

hiding nodes should simply rely on the "preview mode" being enabled or not.
(and of course, WE WANT TO BE ABLE TO EDIT THE DOCUMENT WHILE BEING IN PREVIEW MODE!!!)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
10409 [Scribus] User Interface feature always 2011-11-27 16:30 2019-11-09 11:35
Reporter: JLuc Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Improve access to contour editing
Description: Adding an Edit button on the right of the "Contour" radio button would easyen the access to the contour editing.

Tags: #easyhack, #rottenpatch, HOST-Oman, patch_tested_ok
Steps To Reproduce:
Additional Information: See proposed UI in attached file.
Attached Files: PP.JPG (49,578 bytes) 2011-11-27 16:30
https://bugs.scribus.net/file_download.php?file_id=5547&type=bug
contourEditBox.diff (25,264 bytes) 2012-03-31 00:18
https://bugs.scribus.net/file_download.php?file_id=5711&type=bug
contourEdit.diff (26,013 bytes) 2012-04-03 12:13
https://bugs.scribus.net/file_download.php?file_id=5714&type=bug
noError.diff (25,808 bytes) 2012-04-11 20:05
https://bugs.scribus.net/file_download.php?file_id=5720&type=bug
ubdated_patch.diff (25,808 bytes) 2015-10-22 07:15
https://bugs.scribus.net/file_download.php?file_id=7685&type=bug
Notes
(0027292)
ale   
2011-11-28 12:47   
imo better than the current checkbox solution... (even if sometimes it can be interesting to switch back and forth between the contour line and the frame's shape
(0027833)
pygmee   
2012-03-20 14:48   
The UI_IV_UI team has already proposed to to simplify the workflow about contour line. One of the most important thing was :
1.have a modify button and auto check the "contour line" box in the Points window (something similar to your proposal)
2.have a value field near to the option to set a simple margin around the frame without having to go through the point window
(0027883)
baazigar   
2012-03-31 00:43   
The contourEditBox.diff file that I uploaded resolves the feature to add the an edit(modifier) button aside contour radio button to improve the access to contour editing by reducing a mouseclick.

1)made a new toolbox in propertiesPalette_shapebase.ui named editCont using qtDesigner and set it right to contour radio button.

2)made a click handler to this button in propertiesPalette_shape.cpp which is similar to handleShapeEdit(used when edit button is clicked)

3)modified this handler to give access to contour editing by checking EditContour checkbox of nodeeditpalette through use of docs class.

I also tried to resolve the feature by making another mode(modeContEdit) but this would have led to big changes in structure of code(changing scribus.cpp ,new canvas class for this appmode , etc )so tried out the easier way.
(0027891)
baazigar   
2012-04-03 12:26   
latest patch added with slot handleContourEditEnded - it can handle bad behavior(as reviewed by pygmee)

if you get an error while patching the diff file,

add
QToolButton *editContour;
on line 52 of ui_propertiespalette_shapebase.h

This is because svn diff command cannot diff ui_propertiespalette_shapebase.h
- it is not a part of repository.
(0027913)
cbradney   
2012-04-10 18:29   
the ui_*.h files are generated from the .ui files. If your patch doesn't work, then maybe you need to look there? If it doesn't apply or doesn't build then please don't randomly add the pointer to attempt to fix it.
(0027919)
baazigar   
2012-04-11 19:57   
The patch works perfectly fine for me:
I followed these steps:

1) command patch -p0 < /filepath/EditContour.diff
2) on qt creator click run button.

if you use terminal,
command make -j2
command make install
command cd ~/bin/scribus/bin
command ./scribus
(0027920)
baazigar   
2012-04-11 20:05   
since the older patch file is on another revision revert back to older version on which patch has been made, else patch may not work.(17405)
I am adding a new patch with latest revision 17429
(0027921)
JLuc   
2012-04-11 20:56   
Yes !
noError.diff applies well and runs as requested.
(0036806)
Dawoodalbadi   
2015-10-22 07:17   
hello guys
I slightly modify the old patch to be compotable with the new version 1.5.1
please check it
thank you
(0036831)
JLuc   
2015-10-22 16:17   
I tested and confirm it works OK.

It brings ease in the use of contour.
(0036833)
Kunda   
2015-10-22 16:56   
Haven't tested it but I like the idea
(0036852)
Dawoodalbadi   
2015-10-23 08:48   
(Last edited: 2015-10-23 08:49)
I hope you try the new feature kunda
Its very nice if they add it in
Official version of scribus

(0036914)
Kunda   
2015-10-25 14:04   
Jean, thoughts ?
(0037008)
Kunda   
2015-10-27 23:44   
Per jean:
<Kunda> jghali, quick question: what are you thoughts on: 0010409
<jghali> makes GUI ugly, a better solution would likely to have a drop down menu on modify button to allow editing contour directly
<Kunda> where would the dropdown be triggered from in the gui ?
<jghali> Kunda, the drop down would be in the "modify" button at the top of PP shape tab
(0037049)
ale   
2015-10-28 16:03   
please no dropdown...

i still think that this is not a good solution, but better what we have now.

i would accept this patch until something provides a better solution.
(0037054)
JLuc   
2015-10-28 18:52   
"Ugly ??? How dare you ?"

Plz Look at today's shape tab in the PP !
(0037125)
Kunda   
2015-10-30 20:44   
I agree about accepting the patch till a better solution appears.
(0037135)
Kunda   
2015-10-31 13:07   
bumping issue to top of queue for decision by the devs
(0037225)
christoph_s   
2015-11-04 21:16   
The proposed solution looks ok to me. Not perfect, but better than it is now.
(0037384)
Kunda   
2015-11-10 15:43   
Developers, Craig and Jean, don't seem pleased by the idea proposed in this patch. Perhaps we could offer this an option to set in preferences that we could turn on and off depending on taste ?
(0037604)
JLuc   
2015-11-23 11:53   
no kunda. Dont increase the complexity of the preferences for such a trivial UI improvement.
(0037774)
Kunda   
2015-12-01 16:04   
Jluc, for example, we could have an experimental tab in Preferences where we'd add all sorts of new functionality that we could test drive. If we don't like it we get rid of it ?
(0037785)
JLuc   
2015-12-02 09:54   
A 'test and report' preferences tab.

I like that idea.
(0038862)
Vladimir Savic   
2016-02-22 17:36   
What if all this gets implemented as QPushButton but with ::setMenu() method? That way we could treat it as a simple button, but, because an arrow will appear on Button itself, it would be obvious that there is another option - "Edit Contour line..." could appear. It's the same approach we use for changing shape, for example, and it works well.
(0046770)
JLuc   
2019-10-13 09:48   
8 years later...
(0046778)
ale   
2019-10-14 07:17   
0015811 might help implementing this.

i need two icons: one of editing the shape, the other for editing the contour.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15893 [Scribus] Graphics / Image Frames feature N/A 2019-10-31 12:03 2019-11-09 11:34
Reporter: jhmtv Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Margin for images
Description: It would be nice, to have a feature to set a margin around i.E. images easily.

Currently I have to set form to contour line border and move the points manually.
Would be nice to have a feature to do this more simple. Like setting a margin in
CSS a dialog / properties would be nice to simple set margin-top, margin-start, margin-end,
margin-bottom. Finally the result can be the same, moving the contour points internally
by the specified amount.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0046887)
ale   
2019-10-31 17:38   
I'll try to add it to my proposal for a new shape pane in the properties palette...

See 0015811


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15898 [Scribus] User Interface minor always 2019-11-02 09:55 2019-11-09 11:32
Reporter: PeterBenedek Platform: x64  
Assigned To: ale OS: Linux Mint  
Priority: normal OS Version: 19 (64bit)  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: PP -- Shape: radius of corner function in every case becomes active, if you use the default shapes (square) tool
Description: -- Make two shape or frame.
-- Select the both items
-- Use the Group function
-- Click Shape -- Default Shapes -- square
Look the radius of corner function: function is active
-- Write in it: 10 and enter
Look the radius of corner function: function is inactive, but it did the operation, only it is malfunctioning.
Tags:
Steps To Reproduce:
Additional Information:
System Description Scribus 1.5.x
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15889 [Scribus] Scripter feature N/A 2019-10-30 13:35 2019-11-09 10:30
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scripter: allow insertText, loadImage & co to act on items in a group
Description: from the gui we can act on item that are part of a group... this should also be possible from a scripter.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: scriter-group-items-partial.diff (1,082 bytes) 2019-11-09 10:30
https://bugs.scribus.net/file_download.php?file_id=10730&type=bug
Notes
(0047043)
ale   
2019-11-09 10:30   
i had a look at it but had stop...

attached a partial patch for later use.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15915 [Scribus] Properties Palette feature N/A 2019-11-05 13:43 2019-11-08 17:57
Reporter: ale Platform:  
Assigned To: ale OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Indigo UI: refactor the Color and Line panels
Description: Martin's proposal is to create a Fills panel (most of the current color panel) and a Line one (the line panel plus the stroke color selection).

On top of that I'd suggest:

- Using the XYZ basepoint (it can already indirectly be used... and with the new widget it's "trivia" to only show two or three base points)
- Moving the arrow properties to a new content panel for lines (and beziers)
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: indigo-martin-lines.png (6,158 bytes) 2019-11-06 21:04
https://bugs.scribus.net/file_download.php?file_id=10716&type=bug
indigo-martin-lines-advanced.png (6,005 bytes) 2019-11-06 21:04
https://bugs.scribus.net/file_download.php?file_id=10717&type=bug
custom-type-of-line.png (4,848 bytes) 2019-11-06 21:07
https://bugs.scribus.net/file_download.php?file_id=10718&type=bug
cp-lines.png (12,966 bytes) 2019-11-08 17:57
https://bugs.scribus.net/file_download.php?file_id=10728&type=bug
pp-lines.png (12,788 bytes) 2019-11-08 17:57
https://bugs.scribus.net/file_download.php?file_id=10729&type=bug
Notes
(0046973)
ale   
2019-11-05 13:48   
one question: what is the use of "basepoint: end points"?

i see that it changes the width and height in x2 and y2...
is it all?

then i would suggest that for lines we replace the width chain button by a new button that switches between the width and x2, y2
the button would show "x2" in the normal state and "w" when checked.
(0046975)
ale   
2019-11-05 13:56   
0003765 has an interesting proposal for allowing 5 basepoints for lines.
(0047002)
ale   
2019-11-06 21:04   
martin is defining two widgets for the line panel.

since the arrow heads are moving to the content panel, and the "basepoint" drop down will be a button in the xyz panel, the advanced part shrinks to three buttons that we should integrate in the main panel.

now, one big issue i have in martin's proposal are the labels below and above the fields.

i think that the proposals i've created for the xyz and do well with less labels than martin did plan.

for the lines panel is a bit harder. does anybody want to make suggestions for improved layouts based on the considerations above and the screenshots down here?
(0047003)
ale   
2019-11-06 21:07   
p.s.: martin has forgotten, that when the line type is custom, then a further widget popsup:
(0047035)
ale   
2019-11-08 17:57   
friday evening... status report:

- the arrow heads are now in the content panel for the lines
- the easy part of the properties panel is done
- two screenshot attached and an appimaged linked: https://gitlab.com/a.l.e/scribus/-/jobs/345940624/artifacts/file/Scribus-nightly-x86_64.AppImage
- the color square shows the current color of the stroke but no pop up for setting the colors is there
- basepoint will go to the xyz panel
- the styles will be a fancy combobox...

one big question: i think that all fields are very clear... only for the shade (the 100%) i wonder if we can find an icon to put in front of it...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
579 [Scribus] Styles feature always 2004-05-02 19:24 2019-11-08 06:26
Reporter: linuxlingam Platform: AthlonXP  
Assigned To: ale OS: Fedora  
Priority: normal OS Version: Core 1  
Status: assigned Product Version: 1.3  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] right-click paragraph, save as paragraph style
Description: typesetting for body, headline, etc, usually done by hand initially. so once done, wanna right-click and save it as a paragraph style. should prompt for name.
Tags: #rottenpatch, discussion
Steps To Reproduce:
Additional Information:
System Description This Fedora is a custom distro, with some updates towards Core 2 as well.
Attached Files: style_from_cpos.patch (12,081 bytes) 2011-05-23 13:39
https://bugs.scribus.net/file_download.php?file_id=5275&type=bug
style_from_cpos_v2.patch (13,331 bytes) 2011-05-25 09:17
https://bugs.scribus.net/file_download.php?file_id=5277&type=bug
style_from_cpos_v3.patch (12,961 bytes) 2011-05-26 11:10
https://bugs.scribus.net/file_download.php?file_id=5280&type=bug
stylesFromCPos.patch (17,344 bytes) 2012-01-18 10:49
https://bugs.scribus.net/file_download.php?file_id=5630&type=bug
CreateNewStyle.gif (260,624 bytes) 2019-09-04 16:04
https://bugs.scribus.net/file_download.php?file_id=10590&type=bug
Notes
(0001319)
cbradney   
2004-05-02 19:28   
To be considered with 1.3+
(0016115)
christoph_s   
2007-05-06 21:05   
Should also be available for other styles, if possible.
(0018965)
louisdesjardins   
2008-02-14 19:04   
I take this opportunity to explain further what I have in mind when I talk about a button named "Create style".

While it is very efficient to test various type settings from the PP and immediately see the result in the real text frame of your job (as opposed to the sample text that is in the Edit > Paragraph Styles dialog) it is clumsy to have to go to the Edit > Paragraph Styles dialog to enter again those values when you're satisfied with the result and want that as a Style. The trip to this dialog is time consuming and not very efficient. What I suggest is this button that would allow to immediately create a Style from the settings of the PP (provided as mentionned in an earlier bug report that we harmonize the PP and the Edit > Par Styles dialog). Once hit, we would be offered a small dialog asking for a Style Name and a Keyboard Shortcut (as an option) and voilà!

I sincerely think this would be a great plus for productivity and creationness! Not a gadget, a real plus in the PP. Consider the fact that afaik Scribus is alone in its category to allow such mousewheel settings combined with ctrl and shift keys to make the finest settings at your fingertip, including changing fonts, typesize, linespacing, kerning... etc. Given all those goodies that are really super-efficient, I am incline to think that a "Create Style" button would be in fact the cherry on the cake, the final touch to the text tab in the PP! Am I too enthusiastic?
(0024210)
louisdesjardins   
2010-06-25 01:52   
I completely stand by what I was writing. I agree with the poster that we need that. That was back in 2004, May 2. Wow!

I wonder how difficult is it to implement since we have all the settings available. We only want a button, or a right-click, with a dialog so small... prompt for a name and a keyboard shortcut.
(0026230)
cezaryece   
2011-05-23 13:39   
My patch solving this issue, I hope...
(0026231)
cbradney   
2011-05-23 20:53   
My initial concerns with this lie with the code added to the ScribusMainWindow.. I will review and see if we can get that out of there (we want to remove all function document code from the main window)
(0026234)
cezaryece   
2011-05-24 05:15   
Tell me where and I will move it for you...
(0026250)
cbradney   
2011-05-24 21:27   
Looking again, I think they should at least be in ScribusDoc, at least, it is a better place than the main window. You can connect actions dynamically to the doc.. see actionmanager.cpp and functions like connectNewSelectionActions()
(0026253)
ale   
2011-05-24 21:44   
basically: it works :-)

just one thing: the labels in the context menu are too long... i would create one single context menu with submenus

style >
  create from selection (paragraph)
  update from selection (paragraph)
  create from selection (character)
  update from selection (character)

i'm still not really happy...

i wonder it would not be better to have a button "from selection" in the style manager...

or adding it to the PP...

i guess i'll ask claudia if she has better ideas!
(0026257)
cezaryece   
2011-05-25 06:34   
In PP ok, but invoking style manager for such simply task is against rule "smallest number of clicks".
For me context menu is good place, maybe all these entries should be in submenu "Styles" in there.
(0026258)
cezaryece   
2011-05-25 09:36   
New version of my patch
- functions moved into ScribusDoc as cbradney was suggesting
- in UI all functions are in submenu "Styles from selection" in context menu
- add function for saving current style as Default Paragraph/Character Style

Remember to add option -l (small L) while applying my patches (QtCreator has problem with spaces and tabs)
(0026262)
cbradney   
2011-05-25 21:30   
Cezary.. looks good, I think.. I guess my next observation is.. how does this run programmatically, or via scripter or headless.. void ScribusDoc::setChStyleCPos() calls for GUI interaction. Perhaps such functions could take a string paramter for the name if the GUI is not in use.. or to force a name (and if a duplicate, then just append _s until it is unique or similar)..

I am asking Jean to review too
(0026265)
cezaryece   
2011-05-26 05:37   
(Last edited: 2011-06-02 05:15)
It calls GUI interaction because styles name changes need update in PP and SM. Maybe it should be splited into function for headless operation and separately into function for GUI updates.
I will try to do it...

And done in v3...

(0026486)
StefanM   
2011-06-27 10:29   
This feature would be gold. "typesetting for body, headline, etc, usually done by hand initially. so once done, wanna right-click and save it as a paragraph style. should prompt for name." +1
(0026490)
ale   
2011-06-27 11:45   
stefanm, just apply the patches, test it and give feedback...
(0026527)
StefanM   
2011-07-04 10:07   
@ale

patching didnt work, dont know why: hunk errors etc. I checked out svn trunk and 2 older working copies from within QT Creator and tried
patch -p1 < style_from_cpos_v3.patch
(0026529)
cezaryece   
2011-07-04 11:04   
(Last edited: 2011-07-04 11:07)
Adding -l (small L) option may help, but major problem is that in the meantime CPos field of PageItem is no longer used, and patch need refactoring it to itemText->cursorPosition() method.
When I end current work I try to prepare new version of patch for latest revisions.

(0026532)
ale   
2011-07-04 11:27   
use the "-l" parameter for patch (this is an el and not an one...)
(0026823)
StefanM   
2011-09-02 09:28   
@cezaryece

Is a patch available for testing?
(0027007)
cezaryece   
2011-10-12 05:26   
and what about that patch commit?
(0027009)
StefanM   
2011-10-12 07:17   
@cezaryece

I see only patches from May here, in (0026529) you said "When I end current work I try to prepare new version of patch for latest revisions."

I'm waiting patiently :-) Thank you very much for your work with scribus.
(0027010)
cezaryece   
2011-10-12 11:41   
ups.. my fault... will try today what I promise
(0027554)
cezaryece   
2012-01-18 10:51   
Sorry for late, but bettter late than never.
stylesFromCPos.patch is new version with solution for 1.4.1.svn
Enjoy!
(0042327)
StevenD   
2016-11-06 04:12   
Here it is 2016 and I'm wondering if this feature request is likely to be added? As a designer I have found this feature to be very helpful in other similar applications.
(0046501)
ale   
2019-08-20 12:11   
2019, i will work on this and update the patch to the current code.

but i will avoid using the context menu, since it's already a mess.
one must be using the text palette anyway for formatting.
we can add context menus, once we have sorted out how to make those usable again.

my target implementation is:

- a button next to the styles list in the text palette
- a small input dialog asking for a new name.
(0046503)
PeterBenedek   
2019-08-20 17:36   
(Last edited: 2019-08-20 17:37)
ale, only a proposal
There is a "Edit" button in the style window.
The "Edit" button has no meaning (opens and closes the window). What's the point? Please consider removing this button and the style window let it be always full size.

(0046505)
ale   
2019-08-20 18:31   
hi peter
that's a different matter. personally, i would avoid changing the current style manager, the goal being to create in the future one new manager where you can see and edit multiple styles at a a time. on top of it paragraph style should not have character formatting, but link to a paragraph style (that's the main reason why you will need to have multiple style open at the same time).
for now, it's about creating a style based on the current selection : - )
(0046506)
ale   
2019-08-21 15:20   
i got some working code (i can create a new style based on the current selection), but 0015781 is bugging me...

it's heavily based on cezary's code, just much simpler (at least for now)
(0046531)
ale   
2019-08-24 09:34   
i'm almost there... it's a bit harder than i thought to get everything right... but i'm almost there : - )
(0046617)
serve_chilled   
2019-09-03 07:31   
So happy, that this gets picked up again in 2019. Thank you @ale for your work. This feature would be tremendously helpful!
(0046623)
ale   
2019-09-04 14:08   
here is the pull request:

https://gitlab.com/scribus/scribus/merge_requests/4

jean, this time i think that we really should the review on gitlab:

- the insert seems to work ok to me
- but the update does not work...

can you look at it and give me hint how to fix it? (you can give comments inline...)
(0046624)
ale   
2019-09-04 15:25   
an appimage with the patch can be downloaded here:

https://gitlab.com/a.l.e/scribus/-/jobs/287538744/artifacts/file/Scribus-nightly-x86_64.AppImage
(works on most linux computers)
(0046625)
PeterBenedek   
2019-09-04 15:52   
HI ale

Update button don't work. Is it intentional?
(0046626)
PeterBenedek   
2019-09-04 16:04   
...and there are other problems.
(0046627)
ale   
2019-09-04 16:40   
thanks peter for checking it.

it's written above that the update does not work yet and i need jean's feedback / help : - )
i will have a look at the very long style name and see what i can do there... (i must admit that i've mainly tested with "red" and "abc" and "def"...)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15929 [Scribus] Build System minor N/A 2019-11-08 05:46 2019-11-08 05:46
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: a few warnings about unused variables...
Description: ../scribus/scribusdoc.cpp:14544:10: warning: unused variable ‘oldX’ [-Wunused-variable]
14544 | double oldX = currItem->xPos();
      | ^~~~
../scribus/scribusdoc.cpp:14545:10: warning: unused variable ‘oldY’ [-Wunused-variable]
14545 | double oldY = currItem->yPos();
      | ^~~~
../scribus/scribusdoc.cpp:14546:10: warning: unused variable ‘oldW’ [-Wunused-variable]
14546 | double oldW = currItem->width();
      | ^~~~
../scribus/scribusdoc.cpp:14547:10: warning: unused variable ‘oldH’ [-Wunused-variable]
14547 | double oldH = currItem->height();
      | ^~~~
../scribus/scribusdoc.cpp:14548:10: warning: unused variable ‘oldgW’ [-Wunused-variable]
14548 | double oldgW = currItem->groupWidth;
      | ^~~~~
../scribus/scribusdoc.cpp:14549:10: warning: unused variable ‘oldgH’ [-Wunused-variable]
14549 | double oldgH = currItem->groupHeight;

this is due to the commented out lines on 14575.

i would be glad if code could be simply deleted before the commit and not left in commented out...
and if you must leave inactive code around, there should always be a remark with the conditions for removal (after some time, after some other changes).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
14365 [Scribus] User Interface minor have not tried 2016-11-13 13:02 2019-11-07 18:54
Reporter: ftake Platform: Linux  
Assigned To: OS: openSUSE Leap  
Priority: normal OS Version: 42.2  
Status: new Product Version: 1.5.3.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: Yes
Summary: [PATCH] Style Manager Dialog is too big to show on 1280x800 display
Description: Font size of Scribus UI got bigger recently and now the height of style manager dialog is too big to show on normal laptop display (1280x800 or 1366x768). So I cannot click OK or Cancel button.

DPI value configured with KDE System Settings is 96 and Migu 1C is used as an UI font.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Screenshot_20161113_213504.png (125,801 bytes) 2016-11-13 13:02
https://bugs.scribus.net/file_download.php?file_id=9206&type=bug
Screenshot from 2017-05-11 10-43-58.png (570,883 bytes) 2017-05-11 14:44
https://bugs.scribus.net/file_download.php?file_id=9620&type=bug
StyleManagerfix.patch (116,437 bytes) 2019-10-10 11:31
https://bugs.scribus.net/file_download.php?file_id=10627&type=bug
Notes
(0042413)
Kunda   
2016-11-14 02:30   
+1 will post an example soon
(0043897)
ftake   
2017-05-07 07:16   
Well, the explanation about the screen shot is not enough. There are OK and Cancel at the bottom of the window, which are hidden under the KDE panel.

We need scroll bar for this text-style window or move some components to a new tab.
(0043905)
Matt234   
2017-05-11 14:44   
+1, also happens on HiDPI screens with 3200x1800 resolution.
(0046761)
Fahad   
2019-10-10 11:31   
It seems that no more space left in SMPStyleWidget & SMCStyleWidget
after we added advance text properties [font features ..etc].
To fix this I put them in scrollarea so all properties can fit in one
place. The patch is attached.
(0047013)
ale   
2019-11-07 11:52   
hi @fahad
thanks for the patch.

i had a look at the result of the patch.

personally, i don't like that it also allows an horizontal scrollbar in the right panel.
is it really needed?
(my screen is too big to check it...)

it also feels a bit strange that so little vertical shrinking is allowed.
it just hides the colors and stops...

would it be possible to change those two behaviors?
(0047021)
Fahad   
2019-11-07 17:43   
@ale: the first suggestion to make horizontal scrollbar fixed is easy to implement just change horizontalScrollBarPolicy to ScrollBarAlwaysOff.

the second suggestion is not related to this bug but it should be fixed in another commits because it relate to StyleManager dialog. Its current design allows little vertical shrinking.
(0047023)
ale   
2019-11-07 18:54   
@fahad, can you check if it shrinks enough for you when horizontalScrollBarPolicy is off and then please post a new patch?


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15927 [Scribus] User Interface feature N/A 2019-11-07 17:45 2019-11-07 17:46
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Indigo UI: Metabug
Description: link to ticket that will be implemented through Indigo UI and that do not have yet a corresponding Indigo ticket (or are broader than one ticket).
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047022)
ale   
2019-11-07 17:46   
0003766 is partially already implemented and will completely be implemented as soon as indigo is there.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3766 [Scribus] User Interface feature N/A 2006-05-08 08:11 2019-11-07 17:46
Reporter: pingu Platform: all  
Assigned To: OS: all  
Priority: normal OS Version: all  
Status: feedback Product Version: 1.3.3.1  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: UI improvement proposals to reduce the number of clicks
Description: I know the UI is changing heavily, I'll post a few suggestions based on 1.2/1.3 anyway.
I suggest group together what belongs together:

1) The tabs "colour" and "line" should be combined to one. For space, make colour-selection only a two-line selection-list (None and Black displayed as they are the most common, other colours in drop-down list).

2) &nbsp "XYZ" and "shape" should be combined to one. At least for me, if needed for space remove the Level and Locking-controls.

Two other small things that would drastically reduce the amount of mouse-clickings needed:
3) Working with one frame, today clicking on another only unmarks the first frame. Must click twice to select new frame. Once shold be enough.

4) Text-mode and frame-mode should be kept - buttons functioning like an on/off switch.
Tags: indigodock
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0011114)
christoph_s   
2006-05-08 21:19   
(Last edited: 2006-05-08 22:06)
>>>1) The tabs "colour" and "line" should be combined to one.

Why? All objects can have colours and lines (outlines). "Lines" is used for properties of diffent kinds of lines (including, but not restricted to outlines).

>>>For space, make colour-selection only a two-line selection-list (None and Black displayed as they are the most common, other colours in drop-down list).

See 612. This will solve the issue. I agree, however, that "None", "Black" plus "White" and "Registration" should always stay on top.

>>>2) &nbsp "XYZ" and "shape" should be combined to one. At least for me, if needed for space remove the Level and Locking-controls.

I don't see any need to change things that way. Let's wait until tsoots has rewritten the properties palette, and then make suggestions.

>>>Two other small things that would drastically reduce the amount of mouse-clickings needed:
3) Working with one frame, today clicking on another only unmarks the first frame. Must click twice to select new frame. Once shold be enough.

Not here. Are you sure? If so, that might be a bug. Or do you mean changing the focus while in the edit mode? In this case I agree.

>>>4) Text-mode and frame-mode should be kept - buttons functioning like an on/off switch.

Can you explain this further? I'm afraid I don't understand what you mean.

(0011117)
mkoren   
2006-05-08 22:46   
1) I agree the color tab doesn't make sense by itself. Actually it's not applied to anything but the frame/shape as far as I can tell, and is overridden by a line style's color. The text tab has its own color settings in compact comboboxes; how about doing the same for lines and anywhere else colors are applied?

While we're at it the line tab could be made more compact by putting the line style selections in a combobox like for text. The preview could still be shown with the style in the drop down list, like for the "type of line" box. Of course, Tsoots has probably already changed all this anyway. :)
(0011249)
pingu   
2006-05-12 08:53   
Why I want to combine tabs is simply because I feel there are too many.
Reducing the amount of tabs will make it easier and faster to work with Scribus.
But maybe you're right, "Let's wait until tsoots has rewritten the properties palette, and then make suggestions."

> 3) Working with one frame, today clicking on another only unmarks the first
> frame. Must click twice to select new frame. Once shold be enough.
>
> Not here. Are you sure? If so, that might be a bug. Or do you mean changing
> the focus while in the edit mode? In this case I agree.

Ahh, yes now I notice! That's correct, it'only happens in edit mode.

> 4) Text-mode and frame-mode should be kept - buttons functioning like an on/off switch.
Let me illustrate what I mean:
You mark a frame, select "edit text". Then you mark next text-frame: now I mean I still should be in text-editing mode in the new frame as I once selected that mode. It shall stay that way until I specifically turn edit-mode off by pressing button again.
(0011253)
PLucAuclair   
2006-05-12 13:59   
You mean you want edit text and frame selection states to be kept? Like you enable it and you do your stuff in text editing then click again?

If that's it then a big NO-NO. A switch for this is suicidal!

To me what could be done would be that when you double-click in a frame, you still have the tool if you click in other text, and it stops editing when you click in nothing. This is probably what you meant, but to me a _switch_ for this is **NOT** a good idea.
(0011254)
christoph_s   
2006-05-12 14:45   
I agree with PLucAuclair. There are plans to enable switching to the editing mode with a single click in the frame as in Quark. But leaving other frames in editing mode at the same time doesn't make any sense at all.
(0011255)
louisdesjardins   
2006-05-12 15:48   
So we have 4 bugs on that particular subject.

0000168
0001114
0001293

Plus the current one.

The last 2 have been set as duplicates of the first one and are currently closed. Nonetheless, the issue is still there.

Quark behave as follow :
1. Selecting the content tool is a permanent selection. You have to click on another tool to pick it up. Unless doing so, you keep the Content tool.
2. When on a page where there are unselected text boxes you must select the Content tool and then click on the frame. This selects the frame and put the cursor at the last position where it was. You have to click again to any specific area to the text to get there.
My opinion on this behaviour is it is very easy to work that way. Of course, I am a long time Quark user.

The bug 0000168 doesn't ask for this. It asks for a one-click selection and placement of the cursor. Is this feasible? At what cost in terms of usability? Please see below for how ID works.

The bug 0001114 ask for a "À la Quark" behaviour (my own report). Was closed as a duplicate but I still see this as a very important issue in usability.

The bug 0001293 I agree is a duplicate of 0001114.

Anyway, I think we need this fixed.

The way ID works is clumsy in my view. The text tool allows this one-click selection in any text frame without the need to select it. You basically enter the text mode directly. BUT you have to go to the tool palette and select the Select tool to be able to edit the text frame (resize). Now, this is too many round trips to the tool palette, imo, and doesn't solve the too many mouse clicks issue at all.
(0011401)
packetbell   
2006-05-21 20:22   
(Last edited: 2006-05-21 21:15)
Frame Properties
----------------
Basically, XYZ, Shape and Line are all frame properties. Line and shape can be combined in one new tab [Frame properties], where color is an attribute, just like it is in the text tab. The 'Distance of Text' functionality in 'Shape' should go to the Text tab.


XYZ
---
From the XYZ tab, I'd move the flip contents function from XYZ to within the Text and Image tabs, because they deal directly with the frame contents. The Rotation function could be enhanced by Inkscape-style rotation handles that appear after clicking a frame twice.


Colors
------
There's no need for a Colors tab. Instead, new colors should be defined from the main menu [Extras -> Manage Colors] or from a 'Manage Colors' button on the 'Pick a Color...' palette. In the tabs that remain, colors can be applied as an attribute through a drop-down menu, organized as follows:

1. None
2. Colors used in document
3. Pick a Color...
4. ------ [Divider] ------
5. Defined colors


Image
-----
This tab could do with some extra functionality: flip, rotate, distance from frame, color balance, brightness/contrast, hue/saturation, apply Gimp filter ;)


Tabs
----
By eliminating the color tab, and consolidating Line + Shape, only 4 tabs are left. More space can be saved by using icons instead of tab names, and using horizontal tabs instead of vertical tabs:

XYZ | Frame | Text | Image


Shortcuts
---------
Single click: select frame
Double click: select frame contents (and give focus to Text or Image tab in Properties)
Click twice: rotate handles appear

(0011405)
packetbell   
2006-05-21 21:11   
(Last edited: 2006-05-21 21:15)
Hmmm. The minimalist in me wants to eliminate the Text and Image tabs, leaving only 3 tabs:

XYZ | Frame | Contents

If a text frame has focus, 'Contents' will display all the options currently available in the 'Text' tab. If an image frame has focus, 'Contents' will display all the options currently available in the 'Image' tab.

Single click: select frame, focus 'XYZ' tab
Double click: select frame contents, focus 'Contents' tab
Ctrl+click: select frame, focus 'Frame' tab

(0011406)
christoph_s   
2006-05-21 21:20   
Ermm, this is a dispute about nothing. The properties palette is being completely reworked anyway, as far as I understood. So let's wait until the first draft is out. From what i have read from tsoots on the issue, many points discussed here will become meaningless.
(0024212)
louisdesjardins   
2010-06-25 02:01   
Raising this. It’s a good discussion about real life issues.

The way it worked and still works is not efficient and the solutions that are proposed here stand pretty well.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9099 [Scribus] Usability minor have not tried 2010-05-11 21:20 2019-11-07 17:32
Reporter: alexandre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: A better Path tool
Description: There are lots and lots of things that are wrong with the Path/Bezier Curve tool.

I always used to say something in the lines of "Just copy Inkscape's tool" before, which is never welcome for one reason or another :) So instead here is a brief proposal. Feel free to ask me for a full spec.

Let's start with definition of issues.

Problems with drawing a new path.

1. The only ways to finish drawing a path are Escape and right-click. The usual way is actually to double-click.

2. It's impossible to close a path when drawing it, unless, of course, I have to buy the user guide to find out some obscure way to do it. In both Inkscape in GIMP all I have to do is to target the pointer to the starting node and double-click (with GIMP — click with a modifier). The only way to accomplish the task is to select two end nodes and click a button in the palette.

Problems with editing an existing path.

1. The whole idea of editing nodes and their control points separately is absolutely horrible. I rarely manage not to swear every time I deal with this.

2. Adding and removing nodes via switching to specific modes is absolutely counter-productive and a waste of time (yes, AI does it too, and no -- this is not welcome). Double-click anywhere on path line to add a new node, select and press Del for removing -- that's the ticket.

3. Separate/symmetric shifting of CPs should not be done with specific modes as well. This is what we have modifiers for. Check Inkscape.

4. Mirroring paths is not required in this palette at all. This should be in Object menu, because this is an essential function for all types of objects currently available for them from XYZ tab of PP solely.

5. Same for shearing -- this is an essential function for other types of objects, at least shapes.

6. Rotation and scaling -- the very same thing again.

7. "Activate Contour Line Editing Mode" -- what is it? In seven or eight years that I've been using Scribus I could never figure out what on Earth it does. As far as I can see it does nothing.

8. Confirmation of editing a path, just like restoring position of a node or its CPs is nonsense. This is what properly implemented undo/redo system is for.

So, let's see what could be done about this:

1. All the generic shape deformations (scaling, shearing, rotations) can be moved elsewhere (menu, PP or both) to be available for all shape/image objects.

2. Nodes and CPs can be always editable without switching to the "Move Control Points" that currently enables editing of both.

3. Adding nodes would work by double-clickin anywhere on path line.

4. Removing nodes would work by selecting nodes and pressing Del.

5. Ways of moving CPs can switched with Ctrl/Alt/Shift/whatever modifiers, status bar would give a hint on that.

That gives us a very compact palette that contains:

1. Two buttons to break/join a path
2. Two spinboxes for X and Y values of a selected node

Additionally there could be buttons to change types of nodes (cusp, smooth etc.) which Scribus doesn't quite provide yet despite of providing means to draw different types of nodes.

Such a small palette could definitely be implemented as on-canvas widget like text tool options in GIMP 2.7 (origin/master).
Tags: text to path
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0023900)
alexandre   
2010-05-11 21:24   
Or, and the third thing in the reworked pallette, of course, would be absolute coords switcher.
(0023903)
cbradney   
2010-05-11 22:00   
Please provide programmers or patches for these requests.. we have no spare resources.
(0023909)
ale   
2010-05-12 14:09   
should scribus become a vector drawing app or should it interface in the best way with exising drawing apps?

personally, i have no problem with scribus being less "user friendly" than inkscape as long as i can do the work in inkscape and import without hassles into scribus.
(0023912)
alexandre   
2010-05-12 17:07   
OMG. I'm not talking about Scribus becoming a vector editing app. I'm talking about very basic drawing tasks. Seriously, the existing tool is plain PITA and has not been touched in years.

I'm amazed to see "we have no spare resources" tagline when things like DRW/CGM importers, meshes and symbols are being added. "We are not interested" -- that I can understand, because FOSS is a lot about personal interest. At least it would be honest.
(0023915)
cbradney   
2010-05-12 17:52   
Alexandre.. Franz has time for his interest projects outside of his work. Jean and I have about 1-2h per day each.. that is it.
(0023918)
alexandre   
2010-05-12 20:20   
@cbradney: Yep, point taken.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3513 [Scribus] User Interface feature N/A 2006-03-27 10:03 2019-11-07 17:31
Reporter: mhanski Platform:  
Assigned To: Tsoots OS:  
Priority: normal OS Version:  
Status: assigned Product Version: 1.3.3cvs  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.5.4  
Patch: No
Summary: Toolbar: rearrange icons, allow two column view (mockups included)
Description: -- Toolbar icons need to be rearranged to reflect the logical real world workflow.

-- Allow optional switching to two-column-view


Ideas from 0007465
 - something like OpenOffice
 - some default setting (for beginners)
 - user can create toolbars and each item and order is optional
 - in toolbar creating there must be all items not only basic like now (1.3.5)
 - if the item has a few levels (shape,...) add a possibility add each level (for example only Default Shapes)
Tags: indigodock
Steps To Reproduce:
Additional Information: This is a part of a longer report I've received per mail from a Polish DTP professional (a pl.comp.dtp reader).
Attached Files: scribus133cvs_main_toolbar-rearranged.png (9,717 bytes) 2006-03-27 10:03
https://bugs.scribus.net/file_download.php?file_id=1834&type=bug
scribus133cvs_main_toolbar-rearranged_2-cols.png (8,709 bytes) 2006-03-27 10:04
https://bugs.scribus.net/file_download.php?file_id=1835&type=bug
Notes
(0035326)
Kunda   
2015-06-05 20:19   
+1 on this. Adding to Future Releases.
(0035335)
ale   
2015-06-06 08:18   
(Last edited: 2015-06-06 08:18)
interesting (or even necessary!) for small screens (netbooks...)

... but are there people stille using scribus on such small screens?

if the there are too many buttons in the main toolbar and it does not fit in a normal small monitor, imo we should rather reduce the number of buttons in there...

also,i don't really see an interest to have the toolbar floating around...
just dock it to the left side of the scribus window and you'll have a layout that best uses the available space.

on the other side, what could be interesting, is to bind the tab key to hiding all scribus palettes and toolbars (as gimp does!)...

p.s.: i might change my mind, the day i can dock and "tab" palettes to the left and right side as i can do in gimp...

(0035336)
Kunda   
2015-06-06 12:30   
ale, thanks for your feedback. Besides the points your brought up the deeper issue here (for me) is freedom and personalization. The user should have the flexibilty to set up their UI as much as possible. For example, a left handed user or some one with certain disability issue, I'm sure they set up their workflows differently then the norm based on their preferences. Most likely they have customized their workstation to deal with their issues, lets let them be able to do so in the software as well. Yes they can keybind, but that's not the point because they wouldn't need many of the toolbars if that was the case. Let people be able to tinker and customize, they will appreciate these little details and feel more connected to application.

I like the other ideas you present and if they are not feature requested yet, I encourage you to report them.
(0038536)
Kunda   
2016-02-02 19:01   
Merged and closed 0007465
(0038540)
Kunda   
2016-02-02 19:15   
This may get addressed in indigoDock (https://github.com/nitramr/indigoDock)
(0047019)
ale   
2019-11-07 17:31   
imo, it would be better to remove some of the icons and leave it as a one column vertical toolbar...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9096 [Scribus] Usability feature always 2010-05-11 20:08 2019-11-07 17:30
Reporter: alexandre Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Tool options on canvas
Description: The way tools options are available now is somewhat counter-productive. If you look e.g. at GIMP 2.7 from master branch in Git you'll see that the new Text tool has a compact on-canvas transparent palette that allows changing typeface, font size and setting kerning, tracking and baseline shift. After having used it a lot I can say that while it does need work, it's much better that doing the same from a sidebar palette, because focus of your attention stays in one place.

Now, many things can't possibly fit canvas, but there are things that would definitely benefit from similar approach. I'm specifically referring to the Path Tool's palette and the new Mesh Tool options palette.

As for the Path tool, I'd rather see a combination of Inkscape's path tool and on-canvas palette. I'll file a separate report on that.
Tags: indigodock
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0023899)
plinnell   
2010-05-11 21:20   
screenie of gimp please :)
(0023901)
alexandre   
2010-05-11 21:56   
http://prokoudine.info/files/gimp-text-tool-on-canvas.jpg

Please note that one of GIMP's GSoC projects this year is implementing a whole infrastructure for drawing tools options on canvas.

http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/gimp/t127230759130

As a matter of fact, GIMP 2.7 (Git again) already draws dialogs of all color tools on canvas in fullscreen mode.
(0023902)
cbradney   
2010-05-11 21:59   
Please provide programmers or patches for these requests.. we have no spare resources.
(0023907)
ale   
2010-05-12 08:48   
i guess a first step will be to provide use cases and mockups on how to implement this in scribus.

imo, showing how gimp manages text is not that useful, since in scribus you want much more control on your text: that toolbar would be much bigger and hence probably useless!
(i don't think users will be interested in having just italics and bold in there... we should have ctrl+shift+b and ctrl+shift+i for it... if we ever find a way to reliably detect or define italics and bolds... but i disgress.)

i would like to see how gimp can integrate "adjust color curves" in that framework in order to be able to judge if it may be useful for scribus...

putting the controls on top of the frame won't be very useful for most people, either: in scribus text frames tend to be much longer and you will probably prefer to go to the PP than to scroll up just to be able to see the toolbar.


still, the concept is imho interesting and should be related to the work pierre did for the modularization of the PP.
what i personally would welcome is a personalized and content specific toolbar which would show up at the cursor place on a key press (i'd love to use the tab key for it...). but this is just a dream!
(0023914)
alexandre   
2010-05-12 17:30   
"imo, showing how gimp manages text is not that useful"

Absolutely. It's just an example of existing solution. What would be the point of referring to something that doesn't exist yet? :)

"i would like to see how gimp can integrate "adjust color curves" in that framework in order to be able to judge if it may be useful for scribus..."

1. Build Git
2. Start GIMP, open some image
3. F11 for fullscreen mode
4. Fire up curves dialog

It's crude, but it works. I'd be interested to see effects from the effects stack in Scribus working on canvas instead of the tiny preview area (that was also color UNmanaged last time I tried).

"what i personally would welcome is a personalized and content specific toolbar which would show up at the cursor place"

That's very much in the lines of the proposal :)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8624 [Scribus] Properties Palette minor N/A 2009-12-10 02:11 2019-11-07 17:17
Reporter: simanek Platform:  
Assigned To: jghali OS:  
Priority: normal OS Version:  
Status: assigned Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.5.4  
Patch: No
Summary: [OBSOLETE] Properties Palette/All Palette Window/Panel Management Improvement (mockup incl.)
Description: I realize that this is subjective, but I am speaking from my experience as a professional graphic designer that has worked on magazines, newspapers, catalogs and other smaller layout projects for over 10 years using Freehand, Illustrator, QuarkXpress, Pagemaker, InDesign, Photoshop, GIMP, Inkscape and Scribus (I use the open source apps on my freelance projects). The 'accordian' interface of the current Properties Palette is very inefficient and frustrating to use. All of the sub-palettes included are palettes that I like to view simultaneously as I address various aspects of my layout elements. It would be nice to have the option to separate all of the palettes that make up the current Properties palette into separate windows/panels. The Gimp, as much as (what I can only guess are amateur) users like to complain about its interface, has a much more customizable (and I think pro-user focused) approach to palettes: separate windows/panels or combine two or more into one window with tabbed selection. I think the 'accordian' interface is unusual and, though clever, awkward and inefficient. Every time I want to adjust something I have to scan the accordian stack (unless the one I need happens to be open) and carefully move my mouse to click on the right palette title, even when I only want view a certain property. This isn't that difficult, but the accordian interface is particularly bad because each palette's title can potentially be in two different places depending on which palette is initially 'open' (above or below the active panel). A much better solution would be to have a static stack of buttons representing each palette, displaying the active palette to the side of the button stack. In this way a user could develop muscle memory to match the consistent location of each palette's activation button. A row of tabs across the top of the active palette panel would be a variation of that scheme. Please consider these suggestions or at least execute a serious review of how palettes are managed in Scribus. The properties palette is a dark spot on an otherwise very promising, stable and professional quality application.
Tags: indigodock, palette
Steps To Reproduce:
Additional Information:
Attached Files: scribus-newtext_20091512.png (428,317 bytes) 2009-12-16 05:08
https://bugs.scribus.net/file_download.php?file_id=4503&type=bug
scribus-newlayers_20091512.png (418,542 bytes) 2009-12-16 05:08
https://bugs.scribus.net/file_download.php?file_id=4504&type=bug
Scribus_Palettes_Text.png (26,263 bytes) 2010-01-05 06:35
https://bugs.scribus.net/file_download.php?file_id=4522&type=bug
Properties.ui (111,595 bytes) 2010-04-26 20:57
https://bugs.scribus.net/file_download.php?file_id=4728&type=bug
XYZ-Tab.png (55,050 bytes) 2016-01-19 16:41
https://bugs.scribus.net/file_download.php?file_id=8076&type=bug
Shape-Tab.png (58,860 bytes) 2016-01-19 16:41
https://bugs.scribus.net/file_download.php?file_id=8077&type=bug
Line-Tab.png (60,459 bytes) 2016-01-19 16:41
https://bugs.scribus.net/file_download.php?file_id=8078&type=bug
Text-Tab.png (69,748 bytes) 2016-01-19 16:41
https://bugs.scribus.net/file_download.php?file_id=8079&type=bug
Image-Tab.png (45,266 bytes) 2016-01-19 16:41
https://bugs.scribus.net/file_download.php?file_id=8080&type=bug
Notes
(0022933)
t8xt   
2009-12-10 06:38   
What if pallets can dock into tabs underneath the toolbar buttons and expand when you click them?
(0022935)
simanek   
2009-12-10 13:28   
I think another user posted a request to mimic one of the late versions of InDesign (was that you?). That's a fine suggestion as well. We're still using InDesign CS at work, but I think the new interface is similar to what Inkscape has for collapsible palettes, though I think their 'collapsed' tabs would be better to set text horizontal as InDesign appears to do. But Inkscape also allows you to set the palettes as separate sub-windows as well. But I hesitate to make the mimicry of an existing commercial application the basis of my request. That's a great way to start a flame war. I simply want to convince the Scribus team that however the palettes are to be displayed, the current properties palette is not a good option. It looks like an interface very well suited to whoever designed it, but not well suited to a large population of professional graphic designers and typesetters. Not that Adobe, Aldus, Macromedia, Quark, Gimp or Inkscape have always been right, but I find it difficult to understand why an application interface (especially a relatively new one) would break with interface schemes that appear to have served users very well for twenty years or more. [Note:'palette' and 'pallet' are two different things, though they do have something in common. I am quite sure that 'palette' is correct in this case since layout/graphic design is an art and related to painting.]
(0022936)
cbradney   
2009-12-10 19:40   
Hi

I realise you have put a lot of effort into writing this bug up, however I am going to close it. We realise that the PP could be better, but it is not in our schedule to rebuild it yet. This is a duplicate bug of a number of others and unless we se some really convincing design we are not going to change just for the sake of changing. We plan to have a tear-off and dockable system, as much as this would be possible.

I will leave this open in case you have another comments but will have to close it in a day or so.

Craig
(0022937)
t8xt   
2009-12-10 21:36   
(Last edited: 2009-12-10 21:41)
Would it be possible to make the text on the buttons Shape, Group, Text, Image, Line, etc a different color or bold so they stand out a bit more from the other buttons? And have the diagonal double arrows appear on the mouse pointer to let users now they can re-size the pallet box on Windows when they hold the mouse pointer over the edge of the pallet box? I though this was a bug until I accidentally click and dragged on the edge of the pallet and caused it to resize.

(0022942)
cbradney   
2009-12-11 17:16   
The resize thing is an issue on Windows.. it appears on Linux and OSX. Seems to be a Qt issue.
(0022964)
ale   
2009-12-15 18:58   
craig, i thought that there was a solution which was better than the current one and easy to implement...

* using tabs instead of the accordion (there is a patch from pierre implementing this)
* using icons instead of text for the tabs labels (there are drafts for it somewhere)
* using only one content aware tab for the content properties (instead having group, text, and image: only one of which can be active at one time).

can we vote if this is a convincing enough design?

(it's certainly nothing revolutionary, not a brilliant solution... but imho simnple enough to be implemented)
(0022966)
simanek   
2009-12-16 03:59   
Would the tabs, with the icons replacing the text, still have a title that would show on :hover? Or maybe, similar to Gimp, show text next to the icon on the active tab? Otherwise, the features that you described sound like a good enough improvement for now.
(0022967)
t8xt   
2009-12-16 05:06   
(Last edited: 2009-12-16 05:15)
Hello,

Here's a couple of screen shots attached to this post of the properties panel. I made this in Gimp and QT Designer so nothing is exact. The button to the left of the properties panel will collapse or expand it, the panels are tear off removable. In theroy the pallet panels can be docked to either right or left sides, the tool bar on the left can be moved to its default place on the top, I'm not sure about having the left and right docking do you think it would become to cramped? Screens are getting wider these days and probably soon more designers will have them so having panels docked on the left and right may not be an issue so much in the future. The properties panel still has its accordion feature but now the contents in each section has a scroll bar so the contents of the smaller sub panel have been placed into one big panel. The most commonly used features of each panels are located at the top, please see the Typography panel. There is now the ability to style the text in the Typography panel and save this new style by clicking the +plus button next to the style drop down selectors. Let me know any thoughts about these changes.

Thanks
Warren

P.S. Maybe double clicking a section like for example Frame Spacing inside of a panel will collapse it, double click again to expand it or right clicking inside a panel and selecting Expand All would work to cut down on the scrolling in the panels.

(0023034)
simanek   
2010-01-05 06:35   
I guess I'll look into the nuts and bolts of marking up palette presentation in KDE. That might take some time to learn though. Meanwhile, I have attached a mockup (Scribus_Palettes_Text.png) of a more condensed arrangement of most of the text properties. Another aspect of Scribus's palette problem is the amount of empty chrome that makes these palettes much larger than they need to be. Hopefully this isn't an inherent characteristic of KDE's window layout capabilities. Whatever it is, my attached rendition is at least twice as efficient as the existing layout for text properties. I have also created a few new icons in the same style as the existing text icons to eliminate the need of text descriptions.
(0023832)
Mike   
2010-04-26 20:57   
I was playing with Qt Designer and create new layout of Properties Window. I didn't want to create new bug, so I wrote that here. I know that this won't be implement but I upload that because it (possibly) contains some ideas for developers.
(0023833)
cbradney   
2010-04-26 21:18   
Mike, things can be implemented.. assuming, with things like the PP, that it is seen as a decent step forward.... we just don't have the coding time to do this major work right now, so if others like yourself can present something, then we would encourage it!
(0023836)
Mike   
2010-04-26 22:09   
Ok, understand. If you need resolve some specific UI problem, you could write to me. I create some testing layouts (but direct implementation into code is too difficult for me).
(0024403)
mdcurtis   
2010-07-29 01:50   
As a new Scribus user, on a laptop with a 13" widescreen (ie, about 700px height), I also find the current properties interface somewhat limiting (I know this is not a professional DTP environment...). So I would like add a vote to this ticket. Also, I have a fair amount of experience with Qt (and may even have some time), so if the development team is interested, I could help contribute to a new interface.
(0024406)
ale   
2010-07-29 08:46   
hi mdcurtis, can you please mail me at ale.comp_06@xox.ch? you're help may be very welcome...
(0024407)
ale   
2010-07-29 08:49   
mike: you, too?
(0024408)
Mike   
2010-07-29 16:11   
me too :-)

I am quite busy right now but I try to contribute to this subject
(0038284)
Kunda   
2016-01-19 16:42   
Uploaded screenshots of proposed mockups for convenience
(Thanks to Mike for providing .ui file)
(0038285)
Kunda   
2016-01-19 16:42   
See https://github.com/nitramr/indigoDock
(0047018)
ale   
2019-11-07 17:17   
i think that we can close this ticket as it is superseded by the indigo ui project.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
10553 [Scribus] User Interface feature always 2012-01-29 22:30 2019-11-07 15:08
Reporter: charlieb000 Platform: 32bit PC  
Assigned To: OS: XP  
Priority: low OS Version: sp3  
Status: new Product Version: 1.4.0  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Ctrl/shift click/drag shortcut keys
Description: the existing function that does work is
Shift+click/boxselect for adding items to selection
please note that this is not configurable in the keys section

was wanting to add:
____+drag for copy. it does not have to be the same as the windows OS (ctrl), if you prefer it as shift, please have it configurable.
the three functions could be attributed to one key:



Tags: shortcuts
Steps To Reproduce: (whether for CTRL or SHIFT, configured in pref's)
ctrl+click : add item to selection
ctrl+drag, initial click outside the selection (box select): add items to selection
ctrl+drag, initial click inside the selection (or upon the lines of the objects in the selection): is copy.
Additional Information:
Attached Files:
Notes
(0027619)
charlieb000   
2012-01-30 01:00   
i have found the shortcut CTRL-D for duplicate but i beleive it is slower than the above, but at least its there.
(0027625)
cezaryece   
2012-01-30 11:34   
(Last edited: 2012-01-30 11:37)
For me copy after drag may be implemented as dragging with right mouse button or RMB click while normal dragging (than multiple copies will available while one drag).
Ctrl + drag should be used for constrain direction dragging.

Maybe we should implement some standard behaviors (Windows, Linux, Mac, Scribus deafult, User Set) for user`s choice?

(0027631)
ale   
2012-01-31 12:47   
or we could use the way inkscape is doing it?
(0047016)
ale   
2019-11-07 15:08   
currently, pressing ctrl-d while the selection is moving does create a duplicate at the original position.
we might simply change scribus to create the duplicate to the coordinates where the "mouse" is...


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15924 [Scribus] Canvas feature N/A 2019-11-07 14:51 2019-11-07 14:51
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: rotation tool: give a visual feedback when it detects that the mouse is on a node
Description: when the mouse is on a mode, the rotation tool automatically picks the opposite node as the basepoint.
that's amazing.

but
- that's hard to discover and
- it's hard to tell if you're close enough to the node

i suggest that:

- the rotation tool gives a visual feedback (highlighting the node below the mouse? the opposite one? changing the cursor?)
- use a " margin" that triggers the opposite behavior in both absolute (absolute minimum and maximum; and inside of that span, a percentage of the width / height)

has anybody suggestions for the exact UI?
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
There are no notes attached to this issue.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15923 [Scribus] PDF feature N/A 2019-11-07 13:19 2019-11-07 13:30
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: export selection to pdf
Description: - it should be possible to export the current selection (instead of a page) to pdf.
- the page size would be the size of the selection.
- bleeds and marks should be respected.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0047014)
ale   
2019-11-07 13:28   
(Last edited: 2019-11-07 13:30)
should scribus export he selected area or the selected items?

the easiest thing is probably to export the selected items in a single page document that has the size of the selected area



View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15919 [Scribus] Graphics / Image Frames minor always 2019-11-06 01:24 2019-11-06 23:26
Reporter: christoph_s Platform: x86-64  
Assigned To: OS: Linux  
Priority: normal OS Version: openSUSE Tumblew  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Undesired image border displayed with certain JPEG files
Description: In image frames sometimes a visible grey-ish image border can be seen both in the regular view, as well as the the document preview.
Tags:
Steps To Reproduce: 1) Create new doc.

2) Create a new image frame.

3) Insert the file https://de.wikipedia.org/wiki/Datei:Anas_strepera.jpg into the frame.

4) Enlarge the zoom factor.


--> There's a grey-ish border around the image, which isn't visible in any image editing programme or an image viewer.
Additional Information:
System Description
Attached Files: JPG_in_Scribus.jpg (25,527 bytes) 2019-11-06 07:39
https://bugs.scribus.net/file_download.php?file_id=10709&type=bug
JPG_in_GIMP.jpg (23,901 bytes) 2019-11-06 07:43
https://bugs.scribus.net/file_download.php?file_id=10711&type=bug
EyeofDuckinGimp.jpg (38,606 bytes) 2019-11-06 07:51
https://bugs.scribus.net/file_download.php?file_id=10712&type=bug
EyeofDuckinScribus.jpg (26,438 bytes) 2019-11-06 07:51
https://bugs.scribus.net/file_download.php?file_id=10713&type=bug
Notes
(0046983)
jghali   
2019-11-06 01:47   
Cannot reproduce this here.
(0046984)
PeterBenedek   
2019-11-06 07:39   
The scribus seems to apply antialiasing to the images.
Pixsels is visible in GIMP, but not visible in Scribus.

I think that is what is causing the phenomenon.
(0046985)
PeterBenedek   
2019-11-06 07:51   
Eye of Duck in GIMP and Scribus.
(0046996)
jghali   
2019-11-06 11:56   
It is not antialiasing which cause this as antialiasing is explicitly disabled in cairo when drawing images. It might be the downsampling Scribus performs when loading images for screen display.
(0047009)
christoph_s   
2019-11-06 23:26   
Whatever it is, it's very irritating if you have to judge the quality of a layout. ;)


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
3159 [Scribus] General feature always 2006-01-31 01:58 2019-11-06 23:23
Reporter: nemeth Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: acknowledged Product Version:  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Discretionary hyphenation support
Description: New version of the OpenOffice.org AltLinux Libhnj hyphenator supports discretionary hyphenation (alternations at hyphenation points). Discretionary hyphenation is crucial for Catalan, Dutch, Hungarian, German (old orthography) and Swedish typesetting.

Screenshot: http://www.openoffice.org/nonav/issues/showattachment.cgi/33622/discretionary_hyphenation.png

OOo issue with the new hyphenator and test data: http://lingucomponent.openoffice.org/issues/show_bug.cgi?id=44793
http://www.openoffice.org/issues/show_bug.cgi?id=58558

Code: http://www.openoffice.org/nonav/issues/showattachment.cgi/33618/altlinuxHyph2.tar.gz

Test data:
http://www.openoffice.org/nonav/issues/showattachment.cgi/33621/discretionary_hyphenation_test.tar.gz
Tags:
Steps To Reproduce:
Additional Information:
Attached Files: Error3159-nonstandard-hyphenation.png (19,881 bytes) 2010-06-27 21:22
https://bugs.scribus.net/file_download.php?file_id=4839&type=bug
Notes
(0008511)
nemeth   
2006-01-31 02:07   
There is a bad issue number in the description.
The right one: "http://www.openoffice.org/issues/show_bug.cgi?id=58558"

Code: http://www.openoffice.org/nonav/issues/showattachment.cgi/33618/altlinuxHyph2.tar.gz

Test data:
http://www.openoffice.org/nonav/issues/showattachment.cgi/33621/discretionary_hyphenation_test.tar.gz
(0008516)
plinnell   
2006-01-31 13:13   
Thanks very much for those links. We do plan to enhance text layout in the next couple of releases.
(0014896)
avox   
2007-01-20 02:14   
sorry, this wont make it into 1.3.4
(0024188)
nemeth   
2010-06-23 09:55   
Update: Hyphen (or libhyphen), the new version of this hyphenation library of OpenOffice.org is a shared library under the different Linux distributions: http://sourceforge.net/projects/hunspell/files/Hyphen/

The code and the extended English hyphenation patterns contain some crucial hyphenation fixes (OpenOffice.org didn't care about the hyphenmin values of the patterns, also apostrophe was a problem in hyphenation: http://www.openoffice.org/issues/show_bug.cgi?id=90028). Maybe this problem is related to Scribus, too.
(0024249)
bubu   
2010-06-27 21:25   
Remark: This is perhaps related to the updating libhyphen. Recently in issue 0009194 the Hungarian hyphenation patterns were updated. One of the new features of this updated huhyphn was the "double digraphs" (see the linked documentation by nemeth). For example, Hungarian word "asszonnyal" hyphanated: "asz- szony- nyal". But it does not work in Scribus (see the attached screenshot).
So, with this updated patterns the Hungarian hyphenation is better, but it could be better, if libhyphen also been updated.
(0024250)
cbradney   
2010-06-27 21:33   
That oo.org shows another ny in the text... ie asszony-nyal
(0024251)
bubu   
2010-06-27 22:13   
Yes, this is the right hyphenation: asszonnyal=asz|szony|nyal. Please read the mentioned documentation: http://sourceforge.net/projects/hunspell/files/Hyphen/documentation/tb87nemeth.pdf/download
(0029845)
bubu   
2013-02-16 09:36   
Hi avox, I think this bug should be assigned to jghali too. As I see, he is updated libhyphen to latest 2.8.6 in trunk and 14x. See Rev 18144 and 18145. This patch should be resolve this issue. I will test it in Scribus trunk, if appear in "PPA for Scribus friends".
(0038754)
Kunda   
2016-02-15 14:34   
bubu, what's the status on this ?
(0038788)
bubu   
2016-02-16 16:28   
Kunda, this is still open. I talked formerly with László Németh (@nemeth, lead developer of Hunspell). He told: this feature in not only a library update. There are new features in libhyphen, what Scribus devs need to implement for this discretionary hyphenation support.

László, if you read this, can you explain? Do you have documentation for Scribus devs?
(0038852)
Kunda   
2016-02-21 03:38   
nemeth, ping
(0042570)
bubu   
2016-11-29 13:38   
Reference: https://github.com/HOST-Oman/scribus/issues/145


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
12068 [Scribus] OS-MacOSX minor always 2014-02-16 16:58 2019-11-06 21:44
Reporter: JLuc Platform: OSX 10.x.x  
Assigned To: OS:  
Priority: normal OS Version:  
Status: confirmed Product Version: 1.5.0svn  
Product Build: Resolution: reopened  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: [Qt5 BUG] Open file dialog doesnt remember bookmarked folders
Description: "Open file" dialog (of all sorts) enables to bookmark folders (drag'n'drop them in the left column). That's very handy to get quick access to various work folders.
In 1.4.3, scribus remember these bookmarks across uses, days and weeks and months.

In 1.5, scribus DONT remember these bookmarks after closing the app, or doesnt reload them when launching scribus again.

[EDIT] fixed for linux, bug only exists now for Mac OS
Tags: Qt5.6, upstream
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0031320)
fschmid   
2014-02-16 22:44   
As this feature is a feature from QFileDialog from Qt itself, is's likely a Qt bug. Scribus in all versiona does nothing with Bookmarks here.
(0031325)
jghali   
2014-02-16 23:59   
Yeah it is a Qt bug in Qt 5.2.1 at least, do not remember about 5.2.0. Qt 5.1.1 works as expected on Windows.
(0031329)
FirasH   
2014-02-17 00:22   
On openSUSE 13.1 (Qt 5.2.1) the entries added in the left column are saved as expected.
(0031331)
JLuc   
2014-02-17 08:52   
(Last edited: 2014-02-17 12:19)
Issue is there in Ubuntu13.10 with both Qt5.2.0 and Qt5.2.1

AMOF there is no need to close Scribus for the FileDialog to forget the bookmarked folders : closing the dialog is enough.

OK I posted https://bugreports.qt-project.org/browse/QTBUG-36888

(0031342)
JLuc   
2014-02-18 22:04   
Qt has answered on Qt bugtracker's page.

Answer mentions :
- QFileDialog destructor saves the settings and in QFileDialogPrivate::init restores them.
> Could it be that one of these is not properly called ?

- KDE has their own dialogs, so the bug could be there (but that's probably irrelevant when running a Qt 5 application on KDE 4)
> Are you using KDE on your opensuse Firash ?

- Qt might have been built with #define QT_NO_SETTINGS
...
(0031343)
FirasH   
2014-02-18 22:37   
JLuc, I'm using KDE 4.11.5 and Scribus is compiled with QT 5.2.1.
(0031347)
JLuc   
2014-02-20 08:18   
Bug has been fixed in Qt and shall land in next version (5.3).
(0033024)
Kunda   
2014-07-26 13:15   
Reopening Qt bug and Scribus bug because bug still persists on OSX:
https://bugreports.qt-project.org/browse/QTBUG-36888?focusedCommentId=250445&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-250445
(0033025)
JLuc   
2014-07-26 13:39   
A patch (hack) is proposed in 0012534
(0033027)
jghali   
2014-07-26 13:46   
(Last edited: 2014-07-26 13:49)
Patch refused, breaks file dialogs on Windows and cause other issues on Ubuntu and OS X such as 0011996.

(0033029)
jghali   
2014-07-26 13:49   
Closing, this is not our issue. It has to be fixed by Qt.
(0033368)
Kunda   
2014-08-29 22:10   
reopening to track Qt's progress on this issue.
(0033369)
Kunda   
2014-08-29 22:11   
(Last edited: 2014-08-29 22:13)
UPDATE:
Just left another comment on the QT bugtracker and also sent a direct email to Shawn R. explaining this is still an issue on MAC OSX 10.8.5

Link: https://bugreports.qt-project.org/browse/QTBUG-36888?focusedCommentId=254280&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-254280

(0033431)
Kunda   
2014-09-01 12:05   
UPDATE 2:
Response from Qt dev Shawn R. with a patch!

Explanation: https://bugreports.qt-project.org/browse/QTBUG-36888?focusedCommentId=254334&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-254334

Patch: https://codereview.qt-project.org/#/c/93620/
(0033435)
jghali   
2014-09-01 16:47   
(Last edited: 2014-09-01 16:47)
No need to change subject, the patch does not apply directly to scribus code.

(0033454)
Kunda   
2014-09-02 12:10   
Right, sorry. That was me getting excited. I'm still figuring out how to test this without it being so time consuming
(0033705)
Kunda   
2014-09-15 20:50   
Qt5 Patch that made it in to Qt5.4 Alpha does not work as tested by chhitz. Letting Qt dev Shawn know.
(0034397)
Kunda   
2015-01-29 23:28   
This issue is now only related to the OSX platform. Even though it's really a Qt issue, keeping it open to monitor the situation.
(0034962)
Kunda   
2015-04-21 20:22   
News: Shawn R posted a fix and closed the bug it will be implemented in Qt5.5 beta! I haven't verified that it fixes our bug. Will make notation once Qt5.5 Beta is released
(0035858)
Kunda   
2015-07-22 15:16   
Still persists in Qt5.5 on OSX 10.10.3 r20256
(0036578)
Kunda   
2015-10-09 14:42   
Waiting for Qt5.5.1 to test
(0036757)
Kunda   
2015-10-21 01:36   
Persists in Qt5.5.1
Letting Qt dev know.
(0038786)
Kunda   
2016-02-16 14:40   
Craig, from Shawn R (Qt dev)
Tried qtbase/tests/manual/dialogs on 5.6 branch on OS X 10.11. Unhecked the checkbox "Use native dialog" and dragged a new folder to the sidebar. It's still there the next time I open the file dialog and the next time I run it. The settings are saved to ~/Library/Preferences/com.qtproject.plist, which is a binary file but I can open it with xcode, and I see the shortcut I added in the list under FileDialog.shortcuts.

link: https://bugreports.qt.io/browse/QTBUG-36888?focusedCommentId=306021&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-306021
(0038787)
jghali   
2016-02-16 15:33   
Kunda, as mentionned by Franz in the first note of this issue, bookmarks is a feature from QFileDialog, so we do not manage those at all. Those bookmarks are entirely managed by Qt.
(0038790)
Kunda   
2016-02-16 17:52   
jghali, understood. according to Shawn R. (0012068:0038786) it's fixed in Qt5.6 on OSX. I haven't tested it on 5.6 yet
(0039245)
Kunda   
2016-03-18 21:39   
Ugh, still persists in Qt5.6 on OSX 10.10.5 1.5.2svn r21089
(0039249)
Kunda   
2016-03-18 22:00   
Ok, further digging:
Per the Qt Dev:
 The settings are saved to ~/Library/Preferences/com.qtproject.plist, which is a binary file but I can open it with xcode, and I see the shortcut I added in the list under FileDialog.shortcuts.

So here i what I did:
1) Opened a the Open File Dialog
2) Dragged a new folder in to the Shortcuts area
3) Go to Finder and QuickLook at ~/Library/Preferences/com.qtproject.plist FileDialog.shortcuts
4) I can see the new folder appended to FileDialog.shortcuts
5) Reopen Open File dialog
Result:
I don't see the shortcut in the dialog

Perhaps if I restart Scribus ?
6) Restart Scribus
7) I still see ~/Library/Preferences/com.qtproject.plist that the shortcut is still in the .plist
8) Open the Open File dialog
Result: I don't see the shortcut in the GUI

9) Look at the ~/Library/Preferences/com.qtproject.plist again
Result: I don't see the entry in the FileDialog.shortcuts anymore

Very confused
(0040186)
Kunda   
2016-04-14 20:22   
Utnik, I'm wanting to get this feature fixed on OSX. would u mind doing some testing on 10.11 for this? Thx in advance
(0040199)
utnik   
2016-04-15 16:02   
i don’t have scribus 1.5.2. so i tested with 1.5.1 on macOS 10.11.4:
scribus seems to open the open file and save file dialog without connection to ‚~/Library/Preferences/com.qtproject.plist‘, but it overwrites this .plist with the standard entries (‚desktop’ and ‚volumes‘) when i close either the dialog or the program.
(0046999)
JLuc   
2019-11-06 17:25   
(Last edited: 2019-11-06 17:26)
It's Ok with Ubuntu and Scribus 1.5.5.
Is this still an issue on Mac with new Qt and Scribus versions ?

(0047001)
utnik   
2019-11-06 19:14   
just tested with scribus 1.5.5 and 1.5.6-r23195 on macOS 10.14.6.
scribus still 'forgets' the shortcuts (replaces them with 'volumes' and 'desktop').


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15912 [Scribus] OS-MacOSX tweak always 2019-11-04 17:44 2019-11-06 17:59
Reporter: jhmtv Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: Scribus doesn't open on double click of an data file
Description: If I double click a sla-file. Scribus starts, but it doesn't open
the file. Instead it opens the "new" dialog. If I disable these
dialog in the settings. It start, but the file isn't opened.

If scribus is started and the sla-file is double clicked, it opens
normally.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0046956)
PeterBenedek   
2019-11-04 17:51   
Tested in Linux Mint 19.x

I can't reproduce this. Any sla file is opened.
Please upload a sample file. Thanks.
(0046959)
ale   
2019-11-04 18:26   
this seems to be macos catalina specific.

inkscape (and gimp) seem to have similar issues:
https://gitlab.com/inkscape/inkscape/issues/459
(0046964)
jhmtv   
2019-11-05 07:24   
In my case it is MacOS Mojave.

It is not working i.E. in r22872, r23195, but it is working with 1.5.4.svn r22472
(0047000)
jhmtv   
2019-11-06 17:59   
I've made some more test. It happens for all users. So it is not dependent to any switches, configuration files or sthg. like that.

Due to the fact that r22472 is working it seems not to be an OS issue. Sthg. is changed.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
15906 [Scribus] General feature N/A 2019-11-04 08:43 2019-11-06 15:07
Reporter: ale Platform:  
Assigned To: OS:  
Priority: normal OS Version:  
Status: new Product Version: 1.5.6.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch: No
Summary: flipping an item should be an action not a property
Description: currently, an item has property "flipped".

this has the consequence that a rotated item will be rotated around the rotated axis, which is not what most people will want.

the item should flip around the item's real vertical or horizontal axis.

doing to this unusual behavior i don't think that many people will have rotated flipped items, but, indeed, changing this behavior will break documents where people might have flipped rotated items.

if you (plural) agree that the current behavior is not really useful, the simplest solution to avoid dangerous breakages, would be

- disable now the flipping buttons for rotated items (deprecating the feature) except for allowing the flipping to be turned off.
- add a warning in the preflight verifier that warns about he deprecation, if flipped rotated items are found.
- if people complain we will know that the feature as it is now is not that useless.
- otherwise, after a few stable dot releases, implement the new behavior in the new stable or in the development branch. (some sort of flip_content will have to be kept... since the content has now to be shown flipped)
- people who need the feature for legacy documents can always use the latest stable release that supports the property.
Tags:
Steps To Reproduce:
Additional Information:
Attached Files:
Notes
(0046953)
utnik   
2019-11-04 11:27   
the current state is a bit more complex!
if you select multiple items, they'll flip around global (horizontal/vertical) axes. even if you just duplicate a rotated item and flip them both…
(0046954)
ale   
2019-11-04 13:56   
oh! utnik you're catching bigger and bigger fishes! : - )

so, the correct behavior is already implemented but is only applied to groups and multiple selections.

i wonder if we can try to estimate how many people use the "wrong" behavior and if we come to the conclusion that probably nobody does fix what i now consider a bug despite the risk that there are documents in the wild with rotated flipped items.

personally, i would tend to accept the risk but i would understand the change to be made by first deprecating the flipping for rotated items.


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
8725 [Scribus] Story Editor / Text Frames minor always 2010-01-18 11:58 2019-11-06 15:02
Reporter: christoph_s Platform: x86  
Assigned To: OS: Linux  
Priority: normal OS Version: OpenSUSE 10.3  
Status: confirmed Product Version: 1.5.2.svn  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version: 1.6 milestone  
Patch: No
Summary: Font settings for text frames in the Document Setup are ignored
Description: Change the default font settings in the Document Setup and create new text frame --> The font is still the same as in the Prefs.
Tags:
Steps To Reproduce: I thinks this is how you recreate it:
1) open SLA
2) File > Doc Setup > Item Tools > Text > Text > Font
3) Change font to any other font and change size of the font
4) Press OK
5) open text box and add text
Result: Default font hasn't changed.
Additional Information:
Attached Files:
Notes
(0023098)
jghali   
2010-01-18 14:10   
(Last edited: 2010-09-29 06:48)
Since 1.3.4+, frames do not have their own default font anymore. Default font is determined by default styles. The default font setting is just used to initialize default styles on document creation. Have to decide what we do with those.

(0024356)
ale   
2010-07-18 07:08   
one way to do it, is to just empty the "tool > text" tab in the document settings and put there a select box for the style to be used as default.
(0024823)
jon.grossart   
2010-11-08 17:04   
(Last edited: 2016-03-15 12:39)
This sounds similar (or at least related) to the bug 0009373 that I reported.

(0040173)
Kunda   
2016-04-14 14:50   
This looks like a similiar issue to 0009742 which was just fixed by Franz


View Issue Details
ID: Category: Severity: Reproducibility: Date Submitted: Last Update:
9048 [Scribus] General feature always 2010-04-23 08:53 2019-11-05 14:09
Reporter: aliB Platform: Dell Inspiron 9400  
Assigned To: OS: Linux  
Priority: normal OS Version: OpenSuSE 11.2  
Status: new Product Version: 1.3.6  
Product Build: Resolution: open  
Projection: none      
ETA: none Fixed in Version:  
    Target Version:  
Patch:
Summary: Better control for the origin and basepoint of all frames
Description: 1) The origin settings in the property pallet should be rearranged and enhanced as shown in the screenshot.

2) In addition there should be also an option to specify the basepoint (zero point) of the page and if the zero point is the page itself or the page border.
Especially with the last setting it would be easier to work with documents with a left and a right side which have different inner and outer border sizes.

ATM, if a left page changes to a right page (because I inserted or removed an additional page) all frames have to be rearranged.

3) Behavior improvements
Pressing an arrow button with the left mouse button should change the current frame position.
Pressing an arrow button with the right mouse button should keep the current position and update x, y, and z values
Tags:
Steps To Reproduce:
Additional Information:
System Description KDE 4.3
Graphicdriver nvidia
Attached Files: basepoint_property.png (75,815 bytes) 2010-04-23 08:53
https://bugs.scribus.net/file_download.php?file_id=4718&type=bug
basepoint_Xara.png (236 bytes) 2010-04-23 23:02