View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0017829 | Scribus | User Interface | public | 2026-06-03 06:20 | 2026-06-06 20:33 |
| Reporter | soerendanielkarch | Assigned To | nitramr | ||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 1.7.3 | ||||
| Target Version | 1.7 milestone | ||||
| Summary | 0017829: Creating a linked text frame starts offset from the mouse pointer / crosshair position | ||||
| Description | When 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 Reproduce | Create 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. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Patch | Yes | ||||
| related to | 0014046 | confirmed | The link textframe icon changes between it's starting position and when actually using it |
|
|
All items start off of the pointer/cursor cross. See I am pretty zoomed in to show this. |
|
|
I cannot replicate qirat's issue, but soerendanielkarch's one also happens for me. |
|
|
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. |
|
|
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:
|
|
|
0014046 This is probably the same fault. |
|
|
Yes, @nitramr. I commented earlier that the fractional scaling is causing the issue for me. Anyhting about 100%, and there is this issue. |
|
|
@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? |
|
|
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. |
|
|
@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) |
| 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 |