News:
Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration
Recent posts
#31
Code / Re: Feature discussion: column...
Last post by a.l.e - September 27, 2024, 10:07:35 AMpersonally, i fear that people will start doing the full layout inside of text frames:
if somebody is coming from the word processors world, this is probably the most logical way to do it.
and then they start being frustrated, because it gets harder and harder when they start adding images and legends for them.
and then the culprit is scribus and its developers.
(we have already seen such complaints many time in the past, even with the current very basic columns for frames)
on the other side, i understand why, for power users it can be a game changer in specific cases!
the big question is: how to extend this feature so that it will "only" be used in the cases where it's really useful?
if somebody is coming from the word processors world, this is probably the most logical way to do it.
and then they start being frustrated, because it gets harder and harder when they start adding images and legends for them.
and then the culprit is scribus and its developers.
(we have already seen such complaints many time in the past, even with the current very basic columns for frames)
on the other side, i understand why, for power users it can be a game changer in specific cases!
the big question is: how to extend this feature so that it will "only" be used in the cases where it's really useful?
#32
Code / Re: Feature discussion: job ja...
Last post by a.l.e - September 27, 2024, 09:39:36 AMisn't this something that should be done through scripting?
personally, i would prefer if scribus would not have this type of features.
looks like a monster that is very hard to be done in the right way: both from the UI and the code side (lot of flexibility, all features must be possible).
what i would like is:
a python script that can do this.
i would say that at first there should be a python script with little to no UI, that make sure that the rules can be done with the scripter API.
at first the rules would be hard coded in the script.
in a second step, they might be moved in external text files that are read by the script.
then, if there is a need for it, we could have a separated script (or a script using the former one) that has an UI and can be used by people who don't know python.
what do you think about this?
personally, i would prefer if scribus would not have this type of features.
looks like a monster that is very hard to be done in the right way: both from the UI and the code side (lot of flexibility, all features must be possible).
what i would like is:
a python script that can do this.
i would say that at first there should be a python script with little to no UI, that make sure that the rules can be done with the scripter API.
at first the rules would be hard coded in the script.
in a second step, they might be moved in external text files that are read by the script.
then, if there is a need for it, we could have a separated script (or a script using the former one) that has an UI and can be used by people who don't know python.
what do you think about this?
#33
Code / Feature discussion: job jacket...
Last post by BN_Dev - September 23, 2024, 04:05:41 AMHi all,
An essential feature we need is something analogous to Job Jacket Rules in QuarkXPress. See QuarkXPress 2023 User Guide: Working with Rules and Rule Sets.
Job Jackets are a terrible stupid name, but essentially they're a way of sharing common resources between multiple files related to the same project (resources can be your corporate color scheme/paragraph styles/etc.) But one of the resource types that allow you to share are preflight rules that are run on certain hooks (usually before exporting a PDF but can be set to run on open/save/demand etc).
Although Scribus has PDF verification for various standards, the job jacket rules allow you to specify various user tests that are applied to the document to enforce not just technical PDF compliance but layout policy compliance. If the tests fail you can mark them as warnings that tell the user, or errors that abort the export.
Rules can be specified to match against anything; or just certain types of boxes (frames); or just text content; etc.
Here are some of the real-world use case rules we have setup that are run before exports:
We are aware there are some built-in checks for things like overflow etc., but the feature request was for the checks to be user editable and a wider range of them so they better allow us to reach the same level of policy compliance that we can with QuarkXPress.
As you can probably guess, with a newsprint publication put together at speed by a team of people this can be invaluable to making sure nothing silly happens. Job jacket rules have been a life-vest multiple times and would mean it becomes somewhat dangerous to move a production workflow away from a program that was trying to help you not make mistakes.
However it does seem that implementing this sort of functionality should be quite easy by traversing the outline tree and seeing if any relevant tests match the properties of each item.
Many thanks,
Paul
Quote from: BN_Dev on September 23, 2024, 02:07:24 AM^^ With regards to this post ^^
An essential feature we need is something analogous to Job Jacket Rules in QuarkXPress. See QuarkXPress 2023 User Guide: Working with Rules and Rule Sets.
Job Jackets are a terrible stupid name, but essentially they're a way of sharing common resources between multiple files related to the same project (resources can be your corporate color scheme/paragraph styles/etc.) But one of the resource types that allow you to share are preflight rules that are run on certain hooks (usually before exporting a PDF but can be set to run on open/save/demand etc).
Although Scribus has PDF verification for various standards, the job jacket rules allow you to specify various user tests that are applied to the document to enforce not just technical PDF compliance but layout policy compliance. If the tests fail you can mark them as warnings that tell the user, or errors that abort the export.
Rules can be specified to match against anything; or just certain types of boxes (frames); or just text content; etc.
Here are some of the real-world use case rules we have setup that are run before exports:
- STOP: Image color space is RGB (should be converted to CMYK and our print profile)
- STOP: Colors are specified as RGB (they are out of gamut)
- STOP: Fonts have been substituted (will cause broken ugly output)
- STOP: Text box has overflown (story is cut off)
- WARN: Something is left on the pasteboard (might have forgotten to put it in the layout)
- WARN: Something is rotated between 0°-15° CW/CCW (usually an accident rather than a deliberate rotation over 15°)
- WARN: Dark text on a dark background/light text on a light background (hard to read)
We are aware there are some built-in checks for things like overflow etc., but the feature request was for the checks to be user editable and a wider range of them so they better allow us to reach the same level of policy compliance that we can with QuarkXPress.
As you can probably guess, with a newsprint publication put together at speed by a team of people this can be invaluable to making sure nothing silly happens. Job jacket rules have been a life-vest multiple times and would mean it becomes somewhat dangerous to move a production workflow away from a program that was trying to help you not make mistakes.
However it does seem that implementing this sort of functionality should be quite easy by traversing the outline tree and seeing if any relevant tests match the properties of each item.
Many thanks,
Paul
#34
Code / Feature discussion: column flo...
Last post by BN_Dev - September 23, 2024, 03:41:20 AMHi all,
An essential feature we need is something analogous to column flow in QuarkXPress. See QuarkXPress 2024 User Guide: Controlling column flow.
This has already been discussed a little on the Mantis issue tracker by somebody else wanting this feature; see 0016049: Span Columns for selected text.
I won't rehash everything already said there as it's probably best to read that for the details. But the essential real-world use case is for a newsprint production being able to flow even just the first paragraph over multiple columns would save a huge amount of time when laying out stories with the headline (and maybe the subheading) being in the first (plus maybe second) paragraph.
The time saved would be measured in hours per day and would drastically simplify updating layouts when you only have to move a single text frame per story and don't have to deal with grouping/linking/welding/moving/etc. multiple text frames.
Although the column flow could support all sorts of weird and whimsical combinations, 99% of the use case for most people seems to be just for headlines on the first paragraph and this would be the only thing needed to make the Scribus workflow as efficient as the QuarkXPress workflow when doing the layout.
Many thanks,
Paul
Quote from: BN_Dev on September 23, 2024, 02:07:24 AM^^ With regards to this post ^^
An essential feature we need is something analogous to column flow in QuarkXPress. See QuarkXPress 2024 User Guide: Controlling column flow.
This has already been discussed a little on the Mantis issue tracker by somebody else wanting this feature; see 0016049: Span Columns for selected text.
I won't rehash everything already said there as it's probably best to read that for the details. But the essential real-world use case is for a newsprint production being able to flow even just the first paragraph over multiple columns would save a huge amount of time when laying out stories with the headline (and maybe the subheading) being in the first (plus maybe second) paragraph.
The time saved would be measured in hours per day and would drastically simplify updating layouts when you only have to move a single text frame per story and don't have to deal with grouping/linking/welding/moving/etc. multiple text frames.
Although the column flow could support all sorts of weird and whimsical combinations, 99% of the use case for most people seems to be just for headlines on the first paragraph and this would be the only thing needed to make the Scribus workflow as efficient as the QuarkXPress workflow when doing the layout.
Many thanks,
Paul
#35
Code / Feature discussion: PDF export...
Last post by BN_Dev - September 23, 2024, 03:29:29 AMHi all,
An essential feature we need is something analogous to PDF output styles in QuarkXPress. See QuarkXPress 2023 User Guide: Default PDF Output Style.
Essentially in Scribus the File->Export->Save as PDF screen has hundreds of options. That is great, but it is also a double-edge sword. Our real-world use case requires us to generate quite different PDFs of the same document for different things, with often very different settings that it's easy to make a mistake with.
In QuarkXPress you can capture all the input control values as an "output profile" and it appears in a drop-down. Choosing the profile on the PDF export screen allows you to immediately set hundreds of controls and options to exactly what is needed, without missing anything or making mistakes.
For example, our RIP PDF's have to be 300dpi, single PDF per page, without any compression, all composite, without annotations, flattened transparency etc. etc. But the PDFs we make for the digital version are a single file, at 72dpi, with all the annotations enabled, and embedded thumbnails etc. etc. We have profiles for advertisers proofs; internal copy proofs; and more. Automatically setting hundreds of options enables the workflow very efficiently.
We considered a few ways that this could be achieved by saving the PDF output profiles:
After considering all these things, I think the last option would be best because it also allows Scribus to ship with some sensible defaults to get new users started. If there is a print-ready profile, a screen-only profile, an Amazon Kindle profile, etc. this would let users get started easily on one of the most complex aspects of publishing.
Professional users could remove or replace these with what their organization's particular RIP or other processes requires.
We envisioned at the top of the PDF export window would be a drop-down to choose a profile, and then the user could tweak the settings (if required) before the actual export. We also considered that it could be possible for a feature in the profile data to allow an attribute to mark certain presets to be disabled so they cannot be changed by the user; so if giving a profile to an employee they could not accidentally change essential values before exporting that would cause problems further down the production line.
Many thanks,
Paul
Quote from: BN_Dev on September 23, 2024, 02:07:24 AM^^ With regards to this post ^^
An essential feature we need is something analogous to PDF output styles in QuarkXPress. See QuarkXPress 2023 User Guide: Default PDF Output Style.
Essentially in Scribus the File->Export->Save as PDF screen has hundreds of options. That is great, but it is also a double-edge sword. Our real-world use case requires us to generate quite different PDFs of the same document for different things, with often very different settings that it's easy to make a mistake with.
In QuarkXPress you can capture all the input control values as an "output profile" and it appears in a drop-down. Choosing the profile on the PDF export screen allows you to immediately set hundreds of controls and options to exactly what is needed, without missing anything or making mistakes.
For example, our RIP PDF's have to be 300dpi, single PDF per page, without any compression, all composite, without annotations, flattened transparency etc. etc. But the PDFs we make for the digital version are a single file, at 72dpi, with all the annotations enabled, and embedded thumbnails etc. etc. We have profiles for advertisers proofs; internal copy proofs; and more. Automatically setting hundreds of options enables the workflow very efficiently.
We considered a few ways that this could be achieved by saving the PDF output profiles:
- Using an external script to set them; but requires installing and going to 2 places rather than just the PDF output screen
- Embedding them in the .sla file; super portable but bloats the files and hard to update centrally
- Saved in the program configuration; would require lots of exacting setup on each new installation and then further updates
- In a custom folder that can be set in the program config the same as a font path and profile path; much easier to update on a central file share
After considering all these things, I think the last option would be best because it also allows Scribus to ship with some sensible defaults to get new users started. If there is a print-ready profile, a screen-only profile, an Amazon Kindle profile, etc. this would let users get started easily on one of the most complex aspects of publishing.
Professional users could remove or replace these with what their organization's particular RIP or other processes requires.
We envisioned at the top of the PDF export window would be a drop-down to choose a profile, and then the user could tweak the settings (if required) before the actual export. We also considered that it could be possible for a feature in the profile data to allow an attribute to mark certain presets to be disabled so they cannot be changed by the user; so if giving a profile to an employee they could not accidentally change essential values before exporting that would cause problems further down the production line.
Many thanks,
Paul
#36
Code / Feature discussion: content va...
Last post by BN_Dev - September 23, 2024, 03:03:26 AMHi all,
An essential feature we need is something analogous to Content Variables in QuarkXPress. See QuarkXPress 2024 User Guide: Content Variables.
I am aware that the Marks feature exists and is experimental. It is very promising and we are excited that it could offer better functionality than Content Variables. We have been playing with this feature and found a few bugs (which I have started reporting via Mantis; see 0017269: Ascent not computed with variable text).
We would like to contribute work in this area for the following goals:
Referencing the post at the top, whilst we recognize that a lot of this is possible by directly manipulating the XML file with external tools and with the use of plugins (I have seen an example of a mail-merge type system that does this), having something built-in that's analogous to Content Variables makes time-saving smarter layout features available to everyone without having rely on anything external and is document-portable.
A few example of our actual use case in a newsprint production include:
Many thanks,
Paul
Quote from: BN_Dev on September 23, 2024, 02:07:24 AM^^ With regards to this post ^^
An essential feature we need is something analogous to Content Variables in QuarkXPress. See QuarkXPress 2024 User Guide: Content Variables.
I am aware that the Marks feature exists and is experimental. It is very promising and we are excited that it could offer better functionality than Content Variables. We have been playing with this feature and found a few bugs (which I have started reporting via Mantis; see 0017269: Ascent not computed with variable text).
We would like to contribute work in this area for the following goals:
- To ensure that variable text is treated identically to text entered in to a text frame and has all the correct formatting and behavior of non-variable text
- A view toggle option to highlight Mark objects with a different background color
- To support a type of dynamic variable text whose contents can be updated based on a template or light code solution, such as:
- Set by the contents of an external file path
- Set by a simple Excel-like macro; =DATE('MMM YYYY')
- Access properties of the document or program, such as last save datetime/current file path/etc.
- Extracting "running headers" or other conditional input from the page/section/document, such as current chapter or section name
- An idea to set the content as the output of a Python script that is automatically invoked when fields are updated
- To allow certain variable text Marks to reference others and be embedded/nested
- With an updated UI editor to allow easy access to choosing functionality for the content the user desires
- A new Mark type to allow dynamic picture frame URI
- Using a Mark text to allow dynamic generation/updating of a barcode based on it
- Relevant/associated API interfaces for Scripts to also access/modify these things in a document
Referencing the post at the top, whilst we recognize that a lot of this is possible by directly manipulating the XML file with external tools and with the use of plugins (I have seen an example of a mail-merge type system that does this), having something built-in that's analogous to Content Variables makes time-saving smarter layout features available to everyone without having rely on anything external and is document-portable.
A few example of our actual use case in a newsprint production include:
- Having the issue date as a content variable in the master template that is updated once but referenced in the headers and masthead so no issue ever has the previous incorrect date
- Generating the EAN 13+2 sales barcode for each edition+issue (ISSN+week number)
- Running header for current section name (also potential to use for ToC index)
Many thanks,
Paul
#37
Code / Re: Best forum
Last post by BN_Dev - September 23, 2024, 02:07:24 AMThanks @all, it's been nice to start getting involved and the community is very friendly. I used to use svn before git; I was worried I forgot everything but it all came back to me quickly and I'm happy to use it until/if the project officially switches. I found the process to start submitting patches was easy, plus KDevelop has made it super fast to jump straight in although I mostly live in the terminal.
I finally have a list but it took a small while longer than I thought to collate feedback related to my post above:
I'm going to start typing them out now and I'll put an index post after this one with links directly to them. Our ultimate hope is to switch from QuarkXPress to Scribus for an existing production workflow without any downtime. In order for us to do this we have classified features as essential/desired/future. For essential features we intend to be present and actively work on these and contribute to them in a way that supports our goals whilst also being useful for other users and improving the software overall. If we can meet all our essential needs we will certainly switch to Scribus.
Functionality considered desired are things we can work towards without time constraints and it doesn't matter if they aren't all possible as any pain points are likely to be less than what we currently have with QXP. Functionality considered future is long-term roadmap stuff and we will be happy to continue to commit resources to ensuring Scribus stays on-par with QXP/ID and their offerings.
Our hope is that by working with an open-source project to recreate the features we need in production we can offer a migration path for other publications off proprietary layout software too. As a background project we have also considered documenting how we intend to achieve the QXP>Scribus migration plus the actual migration itself (if it becomes possible) to offer a blueprint for others.
At the very core of a lot of consideration for Scribus is the open XML file format; which is far more accessible than Quark's .QXP format. Some of the features we need could be implemented with external tooling to modify tags if all else fails; but we feel this is too hacky and we would rather have actual native UI support that all users can benefit from on all platforms without external tooling.
Many thanks,
Paul
I finally have a list but it took a small while longer than I thought to collate feedback related to my post above:
Quote from: BN_Dev on September 08, 2024, 07:28:12 AMOver the course of the next week I'll open separate threads for each feature to keep the discussion focused to that particular feature.
I'm going to start typing them out now and I'll put an index post after this one with links directly to them. Our ultimate hope is to switch from QuarkXPress to Scribus for an existing production workflow without any downtime. In order for us to do this we have classified features as essential/desired/future. For essential features we intend to be present and actively work on these and contribute to them in a way that supports our goals whilst also being useful for other users and improving the software overall. If we can meet all our essential needs we will certainly switch to Scribus.
Functionality considered desired are things we can work towards without time constraints and it doesn't matter if they aren't all possible as any pain points are likely to be less than what we currently have with QXP. Functionality considered future is long-term roadmap stuff and we will be happy to continue to commit resources to ensuring Scribus stays on-par with QXP/ID and their offerings.
Our hope is that by working with an open-source project to recreate the features we need in production we can offer a migration path for other publications off proprietary layout software too. As a background project we have also considered documenting how we intend to achieve the QXP>Scribus migration plus the actual migration itself (if it becomes possible) to offer a blueprint for others.
At the very core of a lot of consideration for Scribus is the open XML file format; which is far more accessible than Quark's .QXP format. Some of the features we need could be implemented with external tooling to modify tags if all else fails; but we feel this is too hacky and we would rather have actual native UI support that all users can benefit from on all platforms without external tooling.
Many thanks,
Paul
#38
Layout Issues / Re: Table of contents changes ...
Last post by utnik - September 21, 2024, 11:55:09 PMhi flaxx
it should be the level of the frames. (it's the order in which you've created the frames in the first place. but you may change it in 'preferences' → 'x,y,z' → 'level'...)
utnik
Quote from: Flaxx on September 21, 2024, 09:56:11 PM...it often happens that the top-down order of those articles appears random...
...What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
it should be the level of the frames. (it's the order in which you've created the frames in the first place. but you may change it in 'preferences' → 'x,y,z' → 'level'...)
utnik
#39
Layout Issues / Table of contents changes the ...
Last post by Flaxx - September 21, 2024, 09:56:11 PMHi, probably I'm wrong here, but my question might have to do with layout as well - somehow. 
If not, please move it to the right place.
First: Scribus 1.6.2 is installed on Windows 11 Pro, as well on Linux Mint 22 Cinnamon (dual boot), and portable on USB.
I'm quite comfortable with the usual way how to create tables of contents. I'm doing the layout of a club-internal monthly newspaper (usually 20 to 28 pages), where one chapter allows member groups announcing their meetings and the planned topics on a couple of pages. As these are mostly short paragraphs it usually happens, that more than one (up to four) are published on a single page - all in the same way. The order likely changes from month to month.
The leftmost frame, with the title of each group, is usually marked by unchanged attributes as the one appearing in the TOC. The right one has the content.
After generating the TOC it often happens that the top-down order of those articles appears random. This means, that the third article on a page might stands on top, followed by the second one, and so far.
As I didn't find a way to force the correct sequence, I always have to change the order manually.
My question: What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
If not, please move it to the right place.
First: Scribus 1.6.2 is installed on Windows 11 Pro, as well on Linux Mint 22 Cinnamon (dual boot), and portable on USB.
I'm quite comfortable with the usual way how to create tables of contents. I'm doing the layout of a club-internal monthly newspaper (usually 20 to 28 pages), where one chapter allows member groups announcing their meetings and the planned topics on a couple of pages. As these are mostly short paragraphs it usually happens, that more than one (up to four) are published on a single page - all in the same way. The order likely changes from month to month.
The leftmost frame, with the title of each group, is usually marked by unchanged attributes as the one appearing in the TOC. The right one has the content.
After generating the TOC it often happens that the top-down order of those articles appears random. This means, that the third article on a page might stands on top, followed by the second one, and so far.
As I didn't find a way to force the correct sequence, I always have to change the order manually.
My question: What is the parameter, that Scribus is looking for? It doesn't seems to be the internal frame number nor an alphabetical order.
#40
PDF Generation / Re: [SOLVED] Incorrectly Scale...
Last post by AdmFubar - September 20, 2024, 10:59:28 PMThe best I could do is using PDF/X-4 for the exported PDF. but this still has a small off white border around the shadow when imported into scribus on linux.