A linked offset to a text object is malformed (lines leading to top-left corner of canvas)

[sandthorn]

Win32 Build Inkscape21502-0906061949.7z

I have a problem with radius to this font--Eucrosia News.

When I move a text object to some particular position, save, and then reopen file, the linked offset is rendered weirdly.

This might be caused by the font itself. I'm not sure the font is well implemented. Because when I change my text object using another font, the weirdness is just gone.

If I somehow unlink the offset to the text object (e.g. converting text object to path), the weirdness is gone too.

While weirdness occurs, if you try to move the text object, CPU is used up and the application process seems fail to response (keep you wait at some time).

Please investigate this.

Thank you,
Sandthorn

Attached ZIP contains
1. Test SVG file
2. Font files
3. Screen shot (2 upper examples are rendered weirdly, the lowest seems ok)

[jazzynico (jazzynico)]

Confirmed on Windows XP, Inkscape 21524, but not reproduced with 0.46.

Since it works with 0.46, I can't tell if it's due to the font or to the linked offset, but if you use a bigger font size (86 or more), the weirdness is removed. On the contrary, decreasing the font size adds some more nodes at the page's top left corner.
I've tried to reproduced with other fonts, without success.

[jazzynico (jazzynico)]

Steps to reproduce:

1. Type a text with the text tool (the "A" character), default font.
2. Resize the text so that it is about 500px tall (it seems that it's not reproducible with small sizes).
3. Apply a link offset.
4. Open the undo history.
5. Select the first entry of the undo history (unchanged), then the last one (Moving node handle).

After step 5, you should see a node position 0,0 attached to the offset path.
I've managed to reproduce it with the default Sans font on Ubuntu (DejaVu Sans), DejaVu Serif, Liberation Serif, Georgia, Droid Sans, but not with Arial.

[jazzynico (jazzynico)]

Reproduced again on Windows XP, revision 11649.

[insaner (insaner)]

a couple more diagnostics i just ran into:

-once you have the artifacts displaying (the long lines), if you export to pdf, the lines appear.

-with the artifacts present, go into the text, edit it (type a letter then backspace), and notice the lines go away.. even if you undo, the lines are gone. if you export to pdf the lines will not be present.

is anyone currently looking into this?

[Tobias Bieniek (tobias-bieniek)]

I can confirm this bug on Ubuntu 12.10 with Inkscape 0.48+devel r (Feb 14 2013)

I can also confirm the previous comment that changing the text and reverting it hides the bug. The bug is also relevant for the command line PNG conversion.

[insaner (insaner)]

one more interesting thing I just noticed as I ran into this bug again..

If you have the lines going up to the top left corner, double click there to begin editing the text as nodes. There is a node there at that top left corner which you can drag (to adjust the offset). Drag that node close to the text, and then undo. You will notice that the artifact is still there, and the moving of the node is not undone. ie, the node is in the position you dragged it to. Repeating this process by moving the node to a 3rd location, and undoing again, yields the same result: artifacts still present, and the node is in the same location you dragged it to this time.

Hope that helps narrowing down the cause of this.

[David Mathog (mathog)]

Please post an example that uses a common font and a description of how to trigger the bug in current versions of trunk. Thanks.

[insaner (insaner)]

hmm.. it seems I wasn't notified of your comment David Mathog, sorry about the delay in answering (I also didn't see it after checking here when I saw your comment in the other bug). In any case, this is the simplest use case where I can reproduce the bug:

1 - open a new document, and create a new text object with any text (I chose Luxi Serif as the font, since this is the default that appeared, and I assume it is standard with any linux distro) and increased the font to 48 pt
2 - go to Path > Linked Offset and create the offset.
3 - drag the offset node to make it fatter than the original text (select a different color so you can discern between the two)
4 - group the text object and its linked offset and watch the artifacts immediately appear
5 - modify the text and see the artifacts disappear.
6 - save the file and close.
7 - re-open the file. The artifacts are back.

I have included the file I created by following those instructions.

[ScislaC (scislac)]

This bug is easy to hit and a complete nightmare if you re-open a file that had a lot of different text objects with linked offsets.

[ScislaC (scislac)]

Bug it still present. To narrow it down, it appears to mostly happen on letters with holes where there is a cusp present in the hole. Unfortunately, this is not universal, it also varies by font.

Attached is a file which renders fine in Firefox, Chrome, and rsvg. Open it in Inkscape and a number of characters will show the issue in the offset. Fonts in the example are Arial & Times New Roman (to make it easy).

At first it appeared the place the artifacts stretched to was just the top-left of the document. If the document is resized and a transform is present on the layer, it will stretch to the "original top-left location", not the top-left of the resized document. To see this hide Layer 2, Unhide Layer 1, select all in Layer 1, and Group the objects, the artifacts will show up stretching to the original location.

[insaner (insaner)]

One more diagnostic:
-if the affected object is in a layer, and the layer is hidden and then made visible again (even via undoing), the artifacts disappear for that object (for that instance).

[Tavmjong Bah (tavmjong-free)]

Some documentation is at: http://livarot.sourceforge.net/

The offset path written into the SVG file is correct (when it is updated... it is not always updated when the original path is changed).

[Tavmjong Bah (tavmjong-free)]

I've checked into trunk a 'fix'. It changes a flag so that a slower, but more accurate offset routine is used. Let's see if this really fixes things and that offsetting isn't now too slow.

[su_v (suv-lp)]

On 2015-05-16 15:23 (+0200), Tavmjong Bah wrote:
> I've checked into trunk a 'fix'. It changes a flag so that a slower,
> but more accurate offset routine is used.

Related feature request:
* Bug #770461 “Better interfacing to use_slow_but_correct_offset_method”
  https://bugs.launchpad.net/inkscape/+bug/770461

[insaner (insaner)]

Well, I can't say that it feels slower yet, but it does in fact fix the artifacts for me, THANK YOU!

Should we change the status to "Fix committed"?
If we need to make both options available to the user, I can write up the code to have it as a preference in a menu (bug #770461), but honestly, what is the speed difference for the two? Is it really noticeable in some cases?

Also, does this fix bug #550789, too?

 ---
Fix checked in by tavmjong
revision 14156.

[su_v (suv-lp)]

On 2015-05-17 23:07 (+0200), insaner wrote:
> Also, does this fix bug #550789, too?

AFAICT no, it does not fix bug #550789 (still reproduces).

The "slower" method does seem to affect bug #167519 positively though:
* Bug #167519 (sf1489909) “Artifacts in large offsets”
  https://bugs.launchpad.net/inkscape/+bug/167519

[su_v (suv-lp)]

Follow-up report (regression):
* Bug #1507049 “Regression with linked / dynamic offsets (rev >= 14156)”
  https://bugs.launchpad.net/inkscape/+bug/1507049

[su_v (suv-lp)]

JFTR: r14156 has been reverted due to bug #1507049 (regression).

[Geoffrey Bennett (geoffrey.bennett)]

In case it helps, here is a minimal test case that demonstrates the issue reliably (for me, at least) using Inkscape 0.92.0 (on Fedora 25).

[Nathan Lee (nathan.lee)]

Closing as part of bug migration to Gitlab.

Issue can be tracked in https://gitlab.com/inkscape/inkscape/-/issues/1226

Did not copy over original test case because I'm unsure about font licensing and other test files adequately show the issue.

No new information, however if versioning info is kept in files, the old files are touched by 1.0 on open, so the artefacts don't appear. Doesn't help with plain-svgs