strokes can be incorrectly scaled when objects are copied and pasted

[slowkow]

 

Edited September 15, 2023 by slowkow
change title

[Dan C]

Hi Slowkow, 

Could you edit this post with the actual report alongside the files used to test so we can attempt to recreate your issue.

Lee

[slowkow]

Hi Lee_T,

 

Here you go:

 

 

Bug report

I noticed unexpected inconsistent behavior. Details below.

Before using Designer, I would have assumed that Procedure 1 (P1) would produce the same result as Procedure 2 (P2).

Confusingly, the behavior is different for PDF and SVG files:

• For PDF files, P1 is not equivalent to P2. P1 produces undesirable results, but P2 works as expected.
• For SVG files, P1 is equivalent to P2. Both P1 and P2 produce undesirable results.

 

Procedure 1 (PDF): ❌

Open the PDF in Designer. Copy all. Open a new document. Paste.

Problem: Lines are too thin.

 

Procedure 2 (PDF): ✅

Open a new document in Designer. Drag the PDF directly into the document. Double-click to edit the PDF. Copy all. Paste into the parent document.

Problem: None. Render looks good!

 

Procedure 1 (SVG): ❌

Open the SVG in Designer. Copy all. Open a new document. Paste.

Problem: Lines are too thick.

 

Procedure 2 (SVG): ❌

Open a new document in Designer. Drag the SVG into the document. Double-click to edit the SVG. Copy all. Paste into the parent document.

Problem: Lines are too thick. (Same problem as Procedure 1 (SVG).)

 

 

Here are the files:

example.pdfexample.svg

[slowkow]

In case you're wondering how I created the pdf and svg files, it was with R. This is the complete source code for creating the files:

library(ggplot2)
ggplot(mtcars) + aes(wt, mpg) + geom_point()
ggsave("example.svg")
ggsave("example.pdf")

 

If Affinity developers could fix these PDF and SVG issues, I would come back to Designer and see if it meets my needs for my work. If it does, I'd be encouraging all my colleagues to try it, because it's much cheaper and faster than the alternatives. You might see a lot of academics coming to Designer if you can satisfy their needs.

But until these issues are fixed, it is not possible for me to recommend using Designer for making figures for academic papers.

[v_kyr]

1 hour ago, slowkow said:

Here you go:

I can't reproduce that under ADe v1, as here both will be identical, as far as the same document sizes and zoom levels are used for both files (aka for the initial example PDF/SVG ones and the new created and with contents pasted over ones)!

Further your above screenshots aren't representive at all here, as your example and pasted over files comparisons always use different doc zoom levels!

---------

So here's my go with ADE v1 and with your above example files ...

1)   Example PDF        - 503 x 503 px - 72 DPI at 150% Zoom

      New Pasted  PDF - 503 x 503 px - 72 DPI at 150% Zoom

 

2)  Example SVG       - 504 x 504 px - 72 DPI at 139% Zoom

     New Pasted SVG - 504 x 504 px - 72 DPI at 139% Zoom

[slowkow]

Here's what's happening in the video below:

1. I drag a PDF onto the canvas, and it looks good ✅
2. I open the same PDF with Designer, then select-all and copy, then go back to the canvas and paste. It looks bad ❌

Do you see the problem now?

 

 

[v_kyr]

1 hour ago, slowkow said:

Do you see the problem now?

I see it, but did you saw that the docs then have different zoom levels in their docs here then, namely ...

• for the first dragged in --> 106,6 %
• and for the second via "File -> Open" one --> 187,3 %

... so if you adjust/setup the second opened one's zoom level afterwards also to just 106,6 %, or let's say instead both to 100 % zoom, you should see that their common doc contents is/has the same size! - The visual difference is here only due the different preview zoom levels for the opened/generated docs, which in turn doesn't mean that the drawings have different sizes, or that they will be saved differently sized here when saved!

So the only difference here is the initial zoom level they are shown up when opened via drag'n'drop versus opened via the file menu. - If you meant that preview problem (which doesn't compromize the real size of the drawings), then file in a bug report for the different on file load zoom handling here!

[slowkow]

@v_kyr Zoom level does not change the result.

 

[v_kyr]

7 hours ago, slowkow said:

@v_kyr Zoom level does not change the result.

I think I know now what you mean, namely the font/text size for parsed in graph based SVG files (?). - In former v1 apps that was never fixed and it seems that this old font size issue here (when parsing in generated SVG graphs based scale text data values)  hasn't been fixed so far in v2 apps too.

[lepr]

3 hours ago, v_kyr said:

I think I know now what you mean, namely the font/text size for parsed in graph based SVG files (?).

No, it's the years old mismanagement of stroke widths when objects are pasted into a document with different pixel density.

 

source 72 ppi.afdesign

destination 300 ppi.afdesign

 

Edited September 14, 2023 by lepr
forgot to include the documents

[Dan C]

Hi Slowkow,

as @v_kyr mentioned, this is due to a known issue with SVG scaling that we are still working on.

Lee

 

[slowkow]

@lepr

Thank you for adding your example! It seems that we are describing the same issue.

Is it true to say that Affinity Designer developers have already known about this issue for several years?
 

@Lee_T

Can we expect any updates on this issue in the next release of Affinity Designer? I am willing to help test a beta version if you would like another user to test new code.

I'll gladly come back to Designer in the future, after this issue has been addressed, and re-evaluate if it meets my needs. Thanks!

[Dan C]

We currently have an open beta program accessible here: https://affinity.serif.com/en-gb/affinity-beta-program/

Lee

[v_kyr]

4 minutes ago, slowkow said:

Is it true to say that Affinity Designer developers have already known about this issue for several years?

Just search after it ...

• svg scalling bug site:forum.affinity.serif.com

[lepr]

36 minutes ago, slowkow said:

Thank you for adding your example! It seems that we are describing the same issue.

You're welcome!

Note that Lee_T and v_kyr are talking about another problem, not the one demonstrated by our examples. I don't know why they are doing that.

This thread has now been tagged with AFD-5160, which is a different issue than the one you and I have demonstrated.

 

36 minutes ago, slowkow said:

Is it true to say that Affinity Designer developers have already known about this issue for several years?

Yes, and there are other ancient bugs which I've abandoned hope of being fixed.

 

[slowkow]

@lepr Thank you!

I agree that v_kyr and Lee_T are talking about something else.

 

@Lee_T 

I have reproduced this issue in the Beta version of Affinity Designer. I see exactly the same problem: the line thickness is changing unpredictably. (This is not related to zoom level as suggested by v_kyr.)

[v_kyr]

6 hours ago, slowkow said:

(This is not related to zoom level as suggested by v_kyr.)

I initially thought you meant why both (PDF & new pasted one) lines are shown up in your screenshots differently sized. Since as I showed & proved above with your attached files when zoom wise scaled up/down to the same value they (lines, points, scale) also look identical (at least for v1). - Further for me and my understanding, you didn't expressed that well what you overall meant and are after!

[lepr]

6 hours ago, v_kyr said:

Since as I showed & proved above with your attached files when zoom wise scaled up/down to the same value they (lines, points, scale) also look identical (at least for v1).

That's because you pasted into a destination with same PPI as the source. The effect of the stroke scaling bug becomes apparent when you paste into a document with a different PPI and a physical unit of measurement (in other words, not pixel as unit of measurement), as I showed. (1.x and 2.x are the same. This is an ancient permabug.)

object is not in a copied Group, object's stroke is 'Scale with object' enabled: object's stroke gets wrongly scaled by a factor of destinationPPI/sourcePPI when pasted

object is in a copied Group, object's stroke is 'Scale with object' disabled: object's stroke gets wrongly scaled by a factor of sourcePPI/destinationPPI when pasted

[lepr]

@slowkow

Please change the title of the thread, so people don't think the problem involves PDF or SVG files in particular.

Maybe something like "Buggy stroke widths when pasting objects into another document".

[v_kyr]

4 hours ago, lepr said:

That's because you pasted into a destination with same PPI as the source. The effect of the stroke scaling bug becomes apparent when you paste into a document with a different PPI and a physical unit of measurement (in other words, not pixel as unit of measurement), as I showed. (1.x and 2.x are the same. This is an ancient permabug.) ...

I tried to follow the OP's second posting with his P1/P2 samples and shown images there and as he always just wrote "...Open a new document. Paste" that's in my case an equivalent PPI setup new doc, but with a different zoom level. The OP missed in his above report to name and make clear that the whole is meant for different doc PPI contexts here, which is an essential information part to recreate that behavior.

That old unfixed bug (and some more SVG related ones) with different density resolution docs are still there as we already said and noted above. - Another probably unfixed one for SVG is, that text portions from imported parsed in SVG graph plots (Py matplotlib/plt etc.), often aren't handled correctly (size scale and position placement wise).

 

[lepr]

46 minutes ago, v_kyr said:

The OP missed in his above report to name and make clear that the whole is meant for different doc PPI contexts here, which is an essential information part to recreate that behavior.

Yes, I realise that and wasn't meaning to suggest you should have known that automatically.

[Dan C]

@slowkow What software are you using to generate your source files?

Lee

 

[lepr]

3 hours ago, Lee_T said:

@slowkow What software are you using to generate your source files?

@Lee_T: probably, I'm on your ignore list, but in case you can see this message, please realise that you seem to be still completely misunderstanding the reason this thread was started.

The current original title, "Buggy unexpected behavior with embedded PDFs and SVGs", and the content of the first post may be misleading you. The problem isn't particular to PDF or SVG files, and it has nothing to do with fonts.

I posted an example with screenshot and simple Affinity documents to clearly demonstrate the problem: strokes can be incorrectly scaled when objects copied from one Affinity document are pasted into another Affinity document which has a different pixel density.

Repeating a message I already posted in this thread:

Quote

The effect of the stroke scaling bug becomes apparent when you paste into a document with a different PPI and a physical unit of measurement (in other words, not pixel as unit of measurement), as I showed. (1.x and 2.x are the same. This is an ancient permabug.)

object is not in a copied Group, object's stroke is 'Scale with object' enabled: object's stroke gets wrongly scaled by a factor of destinationPPI/sourcePPI when pasted

object is in a copied Group, object's stroke is 'Scale with object' disabled: object's stroke gets wrongly scaled by a factor of sourcePPI/destinationPPI when pasted

 

Edited September 15, 2023 by lepr
thread title has been updated

[slowkow]

3 hours ago, Lee_T said:

@slowkow What software are you using to generate your source files?

I shared the complete R source code used to generate each file in my previous post above.

[lepr]

@slowkow: thanks for improving the title of this topic