Recent posts

#21
User Interface / Re: Indigo UI: Text Properties
Last post by tim_occ - September 28, 2024, 11:11:07 PM
@BN_Dev the color list need some more improvements yes.

In the last weeks I redesigned the whole text properties panel (+ style manager for paragraph and character styles).

Below you can find a 1:1 comparison from Scribus 1.6.2 and the new concept.

I merged "first line offset" and "optical margins" into "columns and distance" section. Language field has been moved to hyphenation section, because hyphenation requires a language dictionary to work.

Have in mind that it is still a work in progress.
There is no patch file yet, because it needs still some more code optimizations and refinements.
You can check the latest status here: https://codeberg.org/Scribus/scribus


I'm happy about feedback.
#22
Code / Re: Feature discussion: column...
Last post by BN_Dev - September 28, 2024, 08:56:12 PM
Regarding potential solutions and discussions on this; please also consider the primary motivation for this feature being added in QXP/ID is to increase speed of layout. Pasting a story in to a text frame and applying the headline style to the first paragraph is 90% of the job done for a newspaper layout...
Press t (for text tool), 1 drag (create text frame), press Ctrl+V (paste), 1 click (in first para), 1 click (on style pallet). 3 keys and 3 mouse clicks  8)
How many interactions are required to achieve the same with multiple frames, creating welds, groups, etc. etc.
#23
Code / Re: Feature discussion: column...
Last post by a.l.e - September 28, 2024, 08:18:17 PM
ps.: no, in my example above there is only one text flowing through all the frames (title + columns; of course not the image legend)

pps.: if the column / frame break would work correctly, it would even be more comfortable to jump to the first column after the title.

ppps.: as i wrote, i don't think that the current implementation of welding cannot move and resize all the relevant frames at once, when resizing the title part... and it can for sure not do it in a reliable and comfortable way.
#24
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
#25
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.
#26
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).
#27
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...
#28
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
#29
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.
#30
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?