News:
Problems registering, no confirmation email - see http://wiki.scribus.net/canvas/Forums_Registration
Recent posts
#61
Code / Re: Feature discussion: column...
Last post by Nermander - September 28, 2024, 08:21:23 AMCould't the desired effect essentially be managed by linked frames?
Multi-column body text frame in the bottom, on top of this the heading frame spanning two columns.
Link the heading frame to the body text frame.
Now, the big issue of course is if the headings have such a variable size that the height of the heading frame would need to be dynamic. But maybe dynamic frame height could solve this (there are already scripts to adjust the frame height I think, but I am not sure how they would work with linked frames since I guess they depend on overflow).
Multi-column body text frame in the bottom, on top of this the heading frame spanning two columns.
Link the heading frame to the body text frame.
Now, the big issue of course is if the headings have such a variable size that the height of the heading frame would need to be dynamic. But maybe dynamic frame height could solve this (there are already scripts to adjust the frame height I think, but I am not sure how they would work with linked frames since I guess they depend on overflow).
#62
Code / Re: Feature discussion: job ja...
Last post by a.l.e - September 27, 2024, 10:44:33 AMi think that the tool for creating the config file can also run from outside of scribus...
then it can easily be done with qt and python...
then it can easily be done with qt and python...
#63
Code / Re: Feature discussion: job ja...
Last post by utnik - September 27, 2024, 10:21:02 AMa text file with the settings for different jobs and a script would be great. (maybe with a ui to write the settings to the text file and to grab the right set for the actual job – and without tkinter, as this would ban it from mac os...)
utnik
utnik
#64
Code / Re: Feature discussion: PDF ex...
Last post by a.l.e - September 27, 2024, 10:19:57 AMI like the idea of a directory with multiple files in it, each one being a definition of a profile.
My suggestion is that all options that are not defined in the profile, will get the default value.
My suggestion is that all options that are not defined in the profile, will get the default value.
#65
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?
#66
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?
#67
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
#68
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
#69
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
#70
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