View Issue Details

IDProjectCategoryView StatusLast Update
0015539Scribus-public2019-01-21 16:11
Reporterale Assigned To 
Status newResolutionreopened 
Product Version1.5.5.svn 
Summary0015539: the preflight verifier should set the pdf version in the pdf dialog
Descriptionwhen 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.
TagsNo tags attached.


duplicate of 0014436 new improve the link between the pdf version choice and the preflight verifier 



2019-01-16 16:32

administrator   ~0045799

Duplicate of 0014436... reported by yourself ;)


2019-01-16 17:38

manager   ~0045802

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?


2019-01-18 08:40

manager   ~0045811

no reply, reopened.


2019-01-18 09:17

manager   ~0045815

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.


2019-01-18 15:09

administrator   ~0045819

>> no, it's not a duplicate of the other ticket.

It definitely is.


2019-01-18 15:52

manager   ~0045820

no way it is

and i've written both.


2019-01-18 16:02

manager   ~0045821

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.


2019-01-18 18:55

administrator   ~0045822

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


2019-01-21 16:11

manager   ~0045837

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

Issue History

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