Mantis Issue Tracker for Scribus - Issues

0017914: UI: Style Manager styles' sorting is inconsistent

Mon, 10 Aug 2026 20:56:12 +0000

When working with the Style Manager, a predictable sorting helps navigating the styles. The more complex the project is, the more important it gets. However, currently styles' sorting seems to work in an inconsistent, 'hard to grasp' way.

I'm sharing my experience with style sorting in Style Manager below.

**Observed rational behaviours:**
- The ordering of `` and `` tags in the `.sla` file doesn't seem to impact styles' ordering.
- The following rules seem to impact styles' ordering to some degree:
- Alphabetical ordering works in most cases.
- Uppercase characters come before lowercase characters.
- Numbers come before letters in most cases.

**Observed inconsistent behaviours:**
- The 'A, B, C, D' characters are sorted after all other letters. Alphabetical ordering works fro the remainder of the letters. For example, _H1_ comes before _Body_, whereas _Example_ comes before _H1_ (as expected).
- Numbers come before letters, but only if they aren't the starting characters of style names. For example, _Fs-4_ comes before _1-Fs-4_, but _F1s-4_ comes before _Fs-4_.

See the attached short screen capture for reference.

As demoed, it's difficult to manage styles with such an unpredictable sorting. Resolving this would make style management a lot cleaner and easier. Thank you for looking into this!

0013314: "Default" styles should stay on top of the list regardless of alphabetical sorting

Mon, 10 Aug 2026 20:56:01 +0000

"Default" styles should stay on top of the list regardless of alphabetical sorting.

0017897: Keep/improve the Auto Hanging Indent checkbox option

Mon, 10 Aug 2026 11:41:11 +0000

This is the something discussed in 0017243 and Fahad suggested it needs its own bug report.

I think I need to explain a little more (which I avoided in the report as it was not related to that):
- the option is there, a checkbox named "Auto Indent" in the Lists & Drop Caps tab
- when checked it creates a perfect hanging indent for numbered and bulleted lists
- it is real helpful when the list entries are paragraphs or multiple sentences
- when it is removed (as I have, Fahad's patch applied), it makes a bit more work to achieve the same
-- you have to go in para style or PP and it becomes a trial and error method for values which align best (see screenshot).
-- but the checkbox "Auto Indent" makes it very simple (and result is perfect, as far as I saw)
- it just needs a rename "Auto Hanging Indent" to me more acurate description
- not much else is needed imo, works fine already

0017636: Drag-selected and copied content from multiple pages is dictated by a wrongly highlighted page

Mon, 10 Aug 2026 11:36:58 +0000

So, when zooming out, drag-selecting and copying content from multiple pages, the page that is highlighted/selected during this dictates how the content would be pasted, even if the page has no content on it to be selected int he first place. It is like the page itself is copied during this as if it was content.

Please follow the steps below and you will find that pasting this content acts weird.

0017920: [PATCH] Line Style Edior widget UI polish update

Mon, 10 Aug 2026 07:49:30 +0000

Some more UI polish as an improvement on 0017910

0017919: [PATCH] 5_Notes: Add per-notes-style separator rule/line, with editor UI (+additional UI polish)

Mon, 10 Aug 2026 05:29:36 +0000

- New opt-in per-style property set: Draw Separator Rule, Length (% of frame text width), Thickness, Colour, Indent, Gap Below (space to first line of note text). Persisted in `.sla`.
- Rendered via `PageItem_NoteFrame::DrawObj_Item()` override. When Auto Height is on, `PageItem_NoteFrame::layout()` temporarily inflates the top text-distance margin by thickness+gap so note text sits below the rule instead of under it; original margin is restored after layout.
- New "Separator Rule" group added to the Notes Style Editor (Tools → Manage Notes Styles) exposing the above fields.
- Additional UI polish for the Notes Style Editor dialog beyond the above (group reorg, label placement, sizing/alignment consistency) — not functional, cosmetic only.

## Files touched
`notesstyles.h/.cpp`, `pageitem_noteframe.h/.cpp`, `scribusdoc.cpp`, `scribus171format.cpp`, `scribus171format_save.cpp`, `ui/notesstyleseditor.h/.cpp/.ui`

## Compatibility
Old files load with rule enabled by default. Older Scribus versions ignore new attributes on open. No scripting API changes.

0017909: No Line Styles in Style Manager

Sun, 09 Aug 2026 15:44:07 +0000

It has been like this for me for a long time. I never had any usecase defining Line Style in Style Manager so it did not bother me that much. However it is something to be reported.

For Line Styles there:
-- no drop-down arrow
-- no default entry

Screenshot attached.

0017918: [PATCH] 4_Notes style conflict warning names the wrong range and lacks any highlighting

Sun, 09 Aug 2026 13:58:14 +0000

The duplicate-numbering-settings warning in ScribusDoc::validateNSet() hardcodes "document" as the range regardless of which range (Document/Story) actually caused the conflict, and gives no visual distinction between style names and fixed text. Fixed by using the actual range value and bolding the style names/range in the (already rich-text) message. Text-only change; independent of the other Notes Styles Editor patches.

0017917: [PATCH] 3_Notes Styles Editor: add ability to rename an existing notes style

Sun, 09 Aug 2026 13:45:44 +0000

[Patch 3 of 3]

AI found this and suggested it must be 3rd in the sequence.

The style name field was previously editable only while creating a new notes style, with no way to rename an existing one. Adds a dedicated Rename button that unlocks the field for the currently selected style; also fixes validateNSet() being called without the style's pre-rename name, which caused a false "provide same numbering style as set X" rejection on every rename attempt (the validation was comparing the style's already-updated new name against its own not-yet-renamed entry in the document's list). Requires patch B (uses the Add/Cancel button infrastructure it introduces).

0017916: [PATCH] 2_Notes Styles Editor: UI redesign — layout, sizing, icons, mnemonics

Sun, 09 Aug 2026 13:42:38 +0000

[Patch 2 of 3]

AI was big help here. Suggested it must be 2nd in the sequence.

General visual and usability overhaul of the Notes Styles Editor dialog. Splits the former dual-purpose Apply/OK buttons (which relabelled themselves depending on mode) into dedicated Add Style/Cancel/Save Changes/Delete buttons; reorganises field alignment, spacing, and group layout (Numbering, Marks & Styles, Frame Behaviour); adds icons (including colour-coded confirm/cancel icons) and tooltips throughout; adds Alt-key mnemonics; reduces overall dialog width. No functional/logic changes to how notes styles are read, saved, or validated — cosmetic and layout only.

0017915: [PATCH] 1_Notes Styles Editor: default notes style incorrectly identified by name, not identity

Sun, 09 Aug 2026 04:34:07 +0000

[Patch 1 of 3]
It is something AI detected while I was working on the UI actually, and suggested patches to be applied in right sequence. I hope it is right.

NotesStylesEditor decides whether the current notes style is "the default" by comparing its name against tr("default"). The actual default style is seeded with the literal name "Default" and is never translated, so the comparison never matches in any locale — the Delete button's protection against removing the default style, and the name-lock logic, were silently ineffective. Fixed by identifying the default style the same way ScribusDoc::deleteNotesStyle() already does internally: by list position (m_docNotesStylesList.at(0)), not by name string. No user-visible behavior change beyond the button now being correctly greyed out for the true default style. Also removes a small piece of dead code in updateNSList() where the buggy check was immediately overwritten by a duplicate unconditional line.

0017913: Crash when adding Index Mark in empty text frame

Sat, 08 Aug 2026 14:01:26 +0000

Pretty much what the title says. BT attached.

0017502: Losing text (and style) on import.

Sat, 08 Aug 2026 12:18:15 +0000

Scribus is not importing all text from .odt file. It loses:
1. Chapter titles,
2. Page breaks between chapters,
3. Style (set in .odt and imported along with the file) of text also.

The issue is there in 1.7.0 and, as ale confirmed in the matrix chat, in 1.6 too.

0017867: [Feature Request] Script-specific font preferences to prevent missing glyphs in mixed-script text

Sat, 08 Aug 2026 11:57:08 +0000

Add an option to assign default fonts for specific scripts (e.g., Latin, Devanagari, CJK) individually.

When pasting mixed-script text, the app should automatically render each character using the user-defined font for that script. This will help to display complex characters correctly (especially for mixed-script text) and eliminates "missing glyph" boxes without requiring manual font changes.

0017906: Resetting Table Style does not reset Character/Paragraph Style

Fri, 07 Aug 2026 20:36:52 +0000

I don't know what category is befitting this one (change if needed).

The .sla is attached. Please take a look.

The setup:
- I pasted a table form LO (which now pastes directly, thanks to @MrB for 0017893)
- the table has Gurmukhi in col 2

The issue:
- even when I modify the Default Para- and Char Style to use Gurmukhi font,
-- set appropriate cell and para style in the Table Style
-- the text in col 2 keeps showing missing glyphs for Gurmukhi
- I tried modifying the Default and creating new, both don't work
- Pressing the Reset button in the TPP (when table is selected) does nothing
-- shouldn't it set things (para- and char style) back to how they are defined in the Table Style?

Manual works:
- after all the above, enter the col 2
- select the text, and in PP select "Default Char Style" instead of "[Default...]"
-- this brings back Gurmukhi text showing properly.

0011871: Using bullets in Paragraph Styles cause crash by pressing Ctrl+Z in determined condition

Fri, 07 Aug 2026 05:00:41 +0000

Adding a Paragraph in the end of a Text field which is using a Paragrah Style with bullets and then deleting it, cause crash by pressing Ctrl+Z

0017912: Crash when undoing deleting text-frames with Marks

Fri, 07 Aug 2026 04:45:10 +0000

CRASH
- only when both text frames are selected with mouse drag
- press Delete button, Ctrl+Z

NO CRASH
- delete one-by-one, press Delete button, Ctrl+Z
- shift-select one-by-one, press Delete button, Ctrl+Z

0017911: The 2 defaults — Default & [Default] — ideas and solution(s)

Fri, 07 Aug 2026 01:14:25 +0000

I recently had an issue 0017873 that triggered this discussion in the comments. It was not relevant there so here it is.

Here is what I think and understand as of now.

**"Default..." Only:**

A better way (and cleaner too) would be that everything has the "Default..." style by default (until changed). This, as @ale stated earlier in 0017873, would make things simpler for the devs. As a user I think this will be simple and easy for the user as well.

Why keep 2 defaults which is more complex (than 1 default) in terms of code and hard for users to wrap their minds around (unless explained by a dev)?

**The Issue with "Default..." Only:**

As far as I understand, keeping only the "Default..." would make working with mix-script text a nightmare.

Currently, I can have a Gurmukhi word in an all-English paragraph. I have to manually give it a character style though that is specifically created for Gurmukhi text. But things work. The whole paragraph keeps following the Paragraph Style defined for Latin script using a Latin font. This, as far as I understand, is the magic of "[Default...]".

Now, pressing the reset button on the Paragraph Style will turn the Gurmukhi text into 'missing-glyphs' boxes. This I think is what "Default..." does to the text because a style (character or paragraph) cannot be defined for scripts at the same time.

-------

A feature I requested at 0017867 might help somehow (if everything is to have "Default..." by default, and no "[Default...]")

-------

Please share your thoughts and ideas.

0017859: Simplify the Style manager

Thu, 06 Aug 2026 12:06:28 +0000

The Style manager should always be expanded.

From a "technical" perspective, the code can also be simplified and avoid using the labels in the styles tree to pick the right type of action.

0017907: The bleed area still shows in Preview mode in Master Page editing mode

Thu, 06 Aug 2026 00:49:00 +0000

Related to issue 0017901, which is sucessfully fixed, the bleed area is not hidden in preview.

It does not show while previewing in normal mode.

0017910: [PATCH] Line Style widget UI polished

Thu, 06 Aug 2026 00:36:48 +0000

As I mentioned in 0017909, I never saw this widget before. When I finally did today, I took some liberty to polish the UI a bit.

Here is the patch, with screenshots showing before and after the changes.

0017869: Previous paragraph style should be retained on backspace

Wed, 05 Aug 2026 19:51:53 +0000

While pressing backspace, the para that is becoming a part of the previous para should assume the para style of the previous para, and not vice versa.

See the attached clip.
PARA2 should assume the para style of PARA1, and not the other way around.

Attaching a .sla file for your convenience.

0011974: Removing a paragraph via backspace in the SE switches a previously "styled" paragraph to "No Style"

Wed, 05 Aug 2026 19:49:59 +0000

Open any advanced SLA or imported file with applied paragraph styles. Select a text frame and delete the last paragraph via backspace --> Once the previous paragraph has been reached it changes to "No Style".

0000185: Allow frames on master pages to have content when applied to normal pages.

Wed, 05 Aug 2026 09:11:05 +0000

Need to find a way to allow creation of unchangeable text and picture frames on master pages that can have their content edited when applied to normal pages.

0017835: Table Style editor UI suggestions (minor)

Wed, 05 Aug 2026 08:59:59 +0000

1. Should it be "Custom"--a better description (instead of "Other...")?
2. And, should "Custom" be at the bottom (after 100%)
3. Also, should "Use Parent Value" be the first option?
4. Should the section be called "Colour" (instead of "Colours")?