View Issue Details

IDProjectCategoryView StatusLast Update
0017829ScribusUser Interfacepublic2026-06-06 20:33
Reportersoerendanielkarch Assigned Tonitramr  
PriorityhighSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version1.7.3 
Target Version1.7 milestone 
Summary0017829: Creating a linked text frame starts offset from the mouse pointer / crosshair position
DescriptionWhen creating a new linked text frame directly from an overflowing text frame, the new frame does not start exactly at the mouse pointer / crosshair position.

The issue occurs when I click the overflow/link marker at the bottom right of an existing text frame and then draw a new text frame. The frame preview and/or the resulting new linked frame appears shifted by several pixels, for example slightly to the left and below the actual cursor/crosshair position.

This makes precise layout work difficult, because the new linked frame cannot be drawn accurately at the intended position. I then have to manually correct the frame position afterwards, or create the text frames first and link them later. Both workarounds interrupt the normal workflow.
Steps To ReproduceCreate a new document.
Create a text frame and fill it with enough text so that the text overflows.
Click the overflow/link marker at the bottom right of the text frame, or activate the text frame linking workflow.
Move the mouse/crosshair to an exact position, for example a guide intersection, page margin, or grid point.
Click and drag to create a new linked text frame.
Now the pointer jumps—or rather, the new frame does not start at the intended position, but is offset to the left, somewhere below it.
Compare the intended starting position of the drag operation with the actual position of the new text frame.
TagsNo tags attached.
Attached Files
PatchYes

Relationships

related to 0014046 confirmed The link textframe icon changes between it's starting position and when actually using it 

Activities

qirat

2026-06-04 14:53

reporter   ~0053760

All items start off of the pointer/cursor cross. See I am pretty zoomed in to show this.

ale

2026-06-04 16:10

manager   ~0053762

I cannot replicate qirat's issue, but soerendanielkarch's one also happens for me.

qirat

2026-06-05 01:38

reporter   ~0053764

I found it. For me its the display scaling. At 100%, there is no issue. But anything above 100, there is this issue. But as it is super tiny at 100%, I am forced to use bigger.

nitramr

2026-06-05 18:29

developer   ~0053768

I fixed the offset issue with the text-linking cursor. The offset was likely a leftover from the old icon set.

I was also unable to reproduce the issue reported by qirat.
@qirat, do you have fractional scaling enabled for your screen in the display settings? There might be an issue regarding the cursor position on the screen.
cursorfix_2026-06-05_01.diff (487 bytes)   
diff --git a/scribus/canvasmode.cpp b/scribus/canvasmode.cpp
index f34cb36d8..aaf1ca2e7 100644
--- a/scribus/canvasmode.cpp
+++ b/scribus/canvasmode.cpp
@@ -648,7 +648,7 @@ QCursor CanvasMode::modeCursor()
 			cursor = im.loadCursor("cursor-color-picker", 0, 31);
 			break;
 		case modeLinkFrames:
-			cursor = im.loadCursor("cursor-link-text-frame", 0, 31);
+			cursor = im.loadCursor("cursor-link-text-frame");
 			break;
 		case modeMeasurementTool:
 		case modeEditGradientVectors:

PeterBenedek

2026-06-06 08:24

developer   ~0053773

0014046
This is probably the same fault.

qirat

2026-06-06 10:04

reporter   ~0053774

Yes, @nitramr. I commented earlier that the fractional scaling is causing the issue for me. Anyhting about 100%, and there is this issue.

nitramr

2026-06-06 20:04

developer   ~0053781

@qirat okay, I misunderstood you there. I thought you were referring to the zoom level.

I switched the fractional scaling on my monitor to various factors but didn't experience any offset with the selection box.
Tested on Ubuntu (GNOME desktop). Which desktop environment are you using?

soerendanielkarch

2026-06-06 20:09

reporter   ~0053782

Thank you for the `.diff`.

I should mention that I am only an end user, not a developer. I use Scribus for layout work, but I do not know how to apply patches or compile Scribus myself.

What should I do with this file? Is there a way for a normal user to test it, or do I need to wait until the fix is included in an official macOS/Linux build?

I would be happy to test a ready-made build, but I cannot build Scribus from source myself.

ale

2026-06-06 20:33

manager   ~0053783

@soerendanielkarch don't worry about the diff!

If it's indeed the solution to the problem you reported, the change will be integrated into Scribus and you will get the improvement the next time a new version (or snapshot) of Scribus gets released!

(If you're brave enough, you can also get the "nightly" build that the community is providing on Gitlab: but also for that, you'll need to first wait for the patch being accepted by the team and added to the SVN / Git code)

Issue History

Date Modified Username Field Change
2026-06-03 06:20 soerendanielkarch New Issue
2026-06-03 06:20 soerendanielkarch File Added: Bildschirmfoto 2026-06-03 um 08.20.14.png
2026-06-04 14:53 qirat Note Added: 0053760
2026-06-04 14:53 qirat File Added: items_start_off_of_pointer_cursor_cross.mp4
2026-06-04 16:10 ale Note Added: 0053762
2026-06-05 01:38 qirat Note Added: 0053764
2026-06-05 18:29 nitramr Note Added: 0053768
2026-06-05 18:29 nitramr File Added: cursorfix_2026-06-05_01.diff
2026-06-05 18:30 nitramr Assigned To => nitramr
2026-06-05 18:30 nitramr Status new => assigned
2026-06-05 18:30 nitramr Target Version => 1.7 milestone
2026-06-05 18:30 nitramr Patch No => Yes
2026-06-06 08:20 PeterBenedek Relationship added related to 0014046
2026-06-06 08:24 PeterBenedek Note Added: 0053773
2026-06-06 10:04 qirat Note Added: 0053774
2026-06-06 20:04 nitramr Note Added: 0053781
2026-06-06 20:09 soerendanielkarch Note Added: 0053782
2026-06-06 20:33 ale Note Added: 0053783