View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015539 | Scribus | - | public | 2019-01-16 16:20 | 2019-01-21 16:11 |
| Reporter | ale | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | new | Resolution | reopened | ||
| Product Version | 1.5.5.svn | ||||
| Summary | 0015539: the preflight verifier should set the pdf version in the pdf dialog | ||||
| Description | when the user chooses a version in the preflight verifier, that version should also be selected in the pdf dialog. in the other direction, the last pdf version used for the document should be selected the next time the preflight verifier is shown. | ||||
| Tags | No tags attached. | ||||
| Patch | No | ||||
| duplicate of | 0014436 | new | improve the link between the pdf version choice and the preflight verifier |
|
|
Duplicate of 0014436... reported by yourself ;) |
|
|
no, it's not a duplicate of the other ticket. this has a much smaller impact and: - it might be easy to implement. - is more of a bug fix than a feature request. i still believe that the link between the preflight verifier and the pdf version needs to be further improved, to be really useful for most beginners (and 0014436 has a few ideas on how to improve it). but, at least, if one has picked a version in the preflight verifier, she should get the same version in the pdf dialog. that's a different dimension of the prohblem. can i please reopen this? and maybe work on it? |
|
|
no reply, reopened. |
|
|
i'd like to change the code and remove the setting for the last pdf version used in the preflight verifier and use the same setting for both the preflight verifier and the pdf export dialog. this would mean that when you launch the preflight verifier as a standalone tool (no idea if anybody really does it) and you select "postscript", the selection will not be retained for the next launch. (the same happens for the EPS export) The proposed change will: - give almost the same experience as today when exporting to EPS (except that you will have to select PostScript again, if you do multiple EPS exports in a row). - make it impossible to pick PostScript as your default for verification (i really don't think that such a user exists). - give a better experience to the vast majority (or totality) of the users for the PDF workflow. - simplify and slightly shrink the code while providing a better experience most of the time. at the time Scribus was started, PostScript workflows were a thing... today I think that it has become a very marginal use case. a use case that, in most (or all) cases can be better covered with other software than Scribus. |
|
|
>> no, it's not a duplicate of the other ticket. It definitely is. |
|
|
no way it is and i've written both. |
|
|
more seriously, jean, please consider expressing your opinion about the change, what parts should / could be implemented, instead of putting so much weight on the detail if it's a duplicate of or a child of. this ticket has been written with the purpose of being a child of the other bug. its purpose is much smaller, even if comprised in the other one. that's a child. not a duplicate. this ticket proposes a change that is minimally invasive and just synchronizes two values / merges them. the other ticket (while starting with the same purpose) aims at getting the people to better understand what the purpose of the preflight verifier is, by forcing the user to make a conscious choice. (people have the sad tendency to click away dialogs) it's sad to see patches and ideas rotten in this bug tracker, because the team does not give an opinion if they wish a change or not (and accept the changes that have been proposed / give a feedback on what has to be modified to be accepted). if you don't like the proposal (or see issues), then just refuse it (or comment on it). it's more honest than just closing it as a duplicate. |
|
|
>> the preflight verifier should set the pdf version in the pdf dialog In fact I disagree with that statement itself. I'm ok if the preflight verifier takes the PDF version information from the PDF dialog options, not the reverse. |
|
|
that's more useful! in my experience, the preflight verifier is normally shown before the pdf export dialog. i'm interested in knowing what would be the use case for not setting the pdf version after the one picked by the user in the verifier. of course, there might be users who start the preflight verifier in other contexts (standalone, eps export), but i really wonder if anybody is really doing that. and if the the number of users doing that will be lower and lower in the future. of course, the preflight verifier could know in which context it is being called and set the version according to it (every option for standalone, no option (ps) for the eps export, list of pdf version (and storing the version in the file) for the pdf export). but is it really useful to add even more complexity to the scribus code? i've seen that you are started writing some code and i wonder in which direction you will be going... |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2019-01-16 16:20 | ale | New Issue | |
| 2019-01-16 16:32 | jghali | Assigned To | => jghali |
| 2019-01-16 16:32 | jghali | Status | new => resolved |
| 2019-01-16 16:32 | jghali | Resolution | open => duplicate |
| 2019-01-16 16:32 | jghali | Note Added: 0045799 | |
| 2019-01-16 16:32 | jghali | Relationship added | duplicate of 0014436 |
| 2019-01-16 16:33 | jghali | Status | resolved => closed |
| 2019-01-16 17:38 | ale | Note Added: 0045802 | |
| 2019-01-18 08:40 | ale | Assigned To | jghali => |
| 2019-01-18 08:40 | ale | Status | closed => feedback |
| 2019-01-18 08:40 | ale | Resolution | duplicate => reopened |
| 2019-01-18 08:40 | ale | Note Added: 0045811 | |
| 2019-01-18 08:40 | ale | Status | feedback => new |
| 2019-01-18 08:41 | ale | Relationship deleted | 0014436 |
| 2019-01-18 08:41 | ale | Relationship added | child of 0014436 |
| 2019-01-18 09:17 | ale | Note Added: 0045815 | |
| 2019-01-18 15:09 | jghali | Assigned To | => jghali |
| 2019-01-18 15:09 | jghali | Status | new => resolved |
| 2019-01-18 15:09 | jghali | Resolution | reopened => duplicate |
| 2019-01-18 15:09 | jghali | Note Added: 0045819 | |
| 2019-01-18 15:09 | jghali | Relationship replaced | duplicate of 0014436 |
| 2019-01-18 15:10 | jghali | Status | resolved => closed |
| 2019-01-18 15:52 | ale | Assigned To | jghali => |
| 2019-01-18 15:52 | ale | Status | closed => new |
| 2019-01-18 15:52 | ale | Resolution | duplicate => reopened |
| 2019-01-18 15:52 | ale | Note Added: 0045820 | |
| 2019-01-18 16:02 | ale | Note Added: 0045821 | |
| 2019-01-18 18:55 | jghali | Note Added: 0045822 | |
| 2019-01-21 16:11 | ale | Note Added: 0045837 |
