Recent posts

#31
Code / Re: Feature discussion: column...
Last post by utnik - September 28, 2024, 01:31:35 PM
i would still prefer the 'column span' as a part of the definition of the paragraph style.
welding may be a solution. but you need to import the 'overspanning' paragraph as a separate text...

utnik
#32
Code / Re: Feature discussion: column...
Last post by a.l.e - September 28, 2024, 11:35:12 AM
In my eyes, this is a very typical layout that is "hard" to achieve with the in-frame columns:

colums-layout.png

People who have only learned about columns inside of frames, will really struggle to achieve it.

With a better typographical grid and a powerful welding system (moving down the title's bottom border would move down the columns, the image and the legend...), in many (if not most) cases, it would be "easy" to put such a "structure" in the scrapbook, then pull it out from there when it's needed, and adapt it to the specific page.
It would be more complex to setup, (hopefully) just a bit harder to use, but way more flexible and fast for the cases that are just slightly different.
(and the beginners only need the typographical grid, not the welding!)

But can we really hope that Scribus will get there in a foreseeable future?

On the other side, it's clear that with the way Scribus currently works and for the layout Paul is supporting, having slightly better columns inside of the frame looks like the most straightforward solution.
#33
Code / Re: Feature discussion: column...
Last post by Nermander - September 28, 2024, 08:21:23 AM
Could'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).
#34
Code / Re: Feature discussion: job ja...
Last post by a.l.e - September 27, 2024, 10:44:33 AM
i 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...
#35
Code / Re: Feature discussion: job ja...
Last post by utnik - September 27, 2024, 10:21:02 AM
a 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
#36
Code / Re: Feature discussion: PDF ex...
Last post by a.l.e - September 27, 2024, 10:19:57 AM
I 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.
#37
Code / Re: Feature discussion: column...
Last post by a.l.e - September 27, 2024, 10:07:35 AM
personally, 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?
#38
Code / Re: Feature discussion: job ja...
Last post by a.l.e - September 27, 2024, 09:39:36 AM
isn'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?
#39
Code / Feature discussion: job jacket...
Last post by BN_Dev - September 23, 2024, 04:05:41 AM
Hi all,

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
#40
Code / Feature discussion: column flo...
Last post by BN_Dev - September 23, 2024, 03:41:20 AM
Hi all,

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