Inkscape Background Image Issue

[mkdiet]

When the Inkscape file used in the lithography software is saved to the G drive, the background image does not load into the Inkscape file. The background image can be saved locally or on G drive with no issues.

All files are loading properly into the lithography software, the only issue is loading the background image into the Inkscape file; Inkscape shows "linked image not found"

Windows allows long paths to be used but that did not fix the issue.

The paths are not being cut in the lithography software when being read in. I can not find if that is true when the file is being sent to Inkscape

[Monkeymerlot]

OK please upload the file that is giving issues. We do not "send" a file to inkscape. The way it works (as of now) is that the software changes an image located at "C:\AFM\surfacepic.jpg", which is linked already in the inkscape file. In the future this will be slated to change but as of now it is using this legacy method, so I am not sure why it is giving issues unless something changed in the inkscape file.

[ciozi137]

@Monkeymerlot OK I see thanks for the explanation. That makes a lot of sense and helps to explain what we were observing with respect to the background image "changing" in the svg file.

However, we were able to reproduce the issue at the Cypher this afternoon. When we use the following paths from G:...:

and then click the "refresh" button we observe this:

It is possible that this issue could be related to the local version on Cypher not being synchronized to the remote repo. @mkdiet please delete the current local copy and clone the remote again, and store in C:\Documents or similar, not under OneDrive.

[Monkeymerlot]

I can take a look on the cypher and try getting to the bottom of this because this is weird. What location is the image linking to? Also I created another issue (#94) to update this at some point, probably once we understand what is going on with this issue.

[Monkeymerlot]

This is where it determines where to save the image. The VI is "Background.vi".

[Monkeymerlot]

I took a look on cypher and some bizarre behavior happened. So I saw that the location of the file in the broken document was "file:///AFM/surfacepic.jpg". I opened the test file and the location got corrected but was working: ".././../../../../../../AFM/surfacepic.jpg" (corrected from "../../../../../../AFM/surfacepic.jpg"), which makes sense because of the location of the repository.

But then trying to see the location of the inkscape file that was having issues, inkscape crashed. Reopening inkscape and opening the file it seems to be working now? I've even changed the file location in the lithography software and it updated fine. Im going to look and see if there was any issues with inkscape regarding file paths or images.

[Monkeymerlot]

@mkdiet @ciozi137 I think changing "file:///AFM/surfacepic.jpg" to "file:///C:/AFM/surfacepic.jpg" might fix this problem and at the very least it is worth checking out. Note that it needs to be forward slashes, not backwards slashes as all backwards slashes can apparently crash Inkscape. See https://gitlab.com/inkscape/inkscape/-/issues/2743

[Monkeymerlot]

We can also try updating to Inkscape 1.2 instead of Inkscape 1.1, which seems like it fixed this issue (if it is the same issue that we are having) https://gitlab.com/inkscape/extensions/-/merge_requests/461

[ciozi137]

@Monkeymerlot are you describing a path inside the svg file?

I think the more proper way to do this would be to reference something like file://%AppData%/AFM/surface.jpg

[Monkeymerlot]

@ciozi137 Yes, the issue doesn't seem to be with the lithography software but rather with how the path is linked the inkscape file itself. If you open the XML editor (ctrl + shift + X) and click on the image you will see a field called xlink:href. This is the location that the image linked in the svg file is located.

Using AppData can be tricky as a file on one computer cannot necessarily be opened on another computer easily, but I agree this is not the way to do this correctly, but I have been trying to maintain backwards compatibility with older Inkscape files for the time being while I was making changes to the lithography software itself. Take a look at issue #94 as I want to change how this is done totally in a future version of the lithography software and would like to hear what ideas you have regarding this.

[ciozi137]

Everyone take note: %AppData% = %USERPROFILE%\AppData\Roaming\ %LocalAppData% = %USERPROFILE%\AppData\Local\

In LabVIEW you can use this VI to get the application data directory;

https://www.ni.com/docs/en-US/bundle/labview/page/glang/get_system_directory.html

BUT it will return \local, not \roaming. These things need to be kept straight when you compatibility across different applications.

[ciozi137]

@Monkeymerlot regarding AppData on different computers, aren't these background images just local temporary images?

[Monkeymerlot]

@ciozi137 Yes, but how do we locate that in the file path in the inkscape file? Will it be able to resolve %AppData%? Will it automatically change it to "profilename\AppData\Roaming"? This can complicate things.

My thought was to change how we do this all together in the future: We copy the ibw file to a user specified location, and then generate a png, and finally create a new inkscape file with the image linked and embedded. All of these would be in the same directory, and the image filepath in the inkscape file would be relative. This would all be done automatically in the lithography software and we could ship this whole folder as a zipped folder.

[ciozi137]

@Monkeymerlot It is not clear to me what problem we are trying to solve. What I observed today is that the lithography program is being used to change a temporary background image "c:\image.jpg" that is statically linked inside the SVG file. That doesn't make sense to me.

I think the user should:

1. embed (or rather link) their image into the svg file and make their drawings
2. Tell the litho program which SVG file they would like to process (or GDSII file...)
3. The lithography program should extract the background image path and all of the shapes when it reads the svg file.

[Monkeymerlot]

@ciozi137 Sorry I'm having trouble explaining it because of all of the different files, "paths" and programs here. I can make a diagram if needed. So everytime the user changes the background image path in the lithography program, it reads in the data from the ibw file, and then saves a jpg file to C:/AFM/surfacepic.jpg. If we change to another ibw/background image file in the lithography program, it will change the image file located at C:/AFM/surfacepic.jpg.

When you put an image in the svg file, you have an option to embed or link the image. When you link the image in the svg file, it stores a file path to that image file. When you then open up the svg, it will look for that image file that is linked in the svg file at the path that is saved in the SVG file. We use c:/AFM/surfacepic.jpg for two reasons, the first is that it was legacy code and a procedure that was common in the lab and I did not want to have to deal with issues regarding images not being linked or files that were working yesterday breaking whenever the lithography program updated. The second reason we are still using this old legacy workflow is that by having that singular location for the background image that is linked in the svg and then changing/updating the physical image file when we update the background image path in the lithography software it will cause the background image in the svg file to automatically update as well, which is convenient.

The problem we are having right now, is that when we updated inkscape to v1.1 from a very old version that we were previously using (that had much more serious issues), Inkscape is having trouble resolving file:///AFM/surfacepic.jpg correctly (and only sometimes it seems, as when I first checked out the issue on the cypher it wasn't working, but then when I restarted Inkscape it was working as intended). My suggestion is to try changing the path in the inkscape file to file:///c:/AFM/surfacepic.jpg, which was a suggestion for a similar issue on the gitlab page for inkscape by one of the inkscape developers.

Regarding your suggested workflow, the AFM program will still need to generate an image file, as it is not possible to just input an ibw file into Inkscape. A possible work around would be specifying a location where we could find the background image file at and have the lithography program save it there instead. The last two steps are actually done already for svg files. The last one was added with the new parser in preparation for a possible change in workflow in the future, as this current workflow is something I have been wanting to change for a while.

[ciozi137]

@Monkeymerlot thanks for the explanation. @mkdiet And some other users should chime in about the workflow. I'm not a fan of linking a temporary image inside a svg - it makes it impossible to see how the pattern lines up with the image in the future

[Monkeymerlot]

I agree. To review old files, the current work around is to open up your SVG and then in the lithography program input your background image (ibw) and then everything should line up in the old SVG.

---

From: Patrick Irvin @.> Sent: Thursday, July 6, 2023 7:13:07 PM To: levylabpitt/AFM-Lithography @.> Cc: Albro, Joseph Aaron @.>; Mention @.> Subject: Re: [levylabpitt/AFM-Lithography] G Drive Inkscape Background Image Issue... (Issue #93)

@Monkeymerlothttps://github.com/Monkeymerlot thanks for the explanation. @mkdiethttps://github.com/mkdiet And some other users should chime in about the workflow. I'm not a fan of linking a temporary image inside a svg - it makes it impossible to see how the pattern lines up with the image in the future

— Reply to this email directly, view it on GitHubhttps://github.com/levylabpitt/AFM-Lithography/issues/93#issuecomment-1624419452, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AI6TZOBPIYEW6QS4EC2FQGDXO5BAHANCNFSM6AAAAAA2A3T7UU. You are receiving this because you were mentioned.Message ID: @.***>

[ciozi137]

While I think that there is a better way to handle IBW files and how to insert them into SVG files (Issue #94), I think to avoid feature creep for release 10.1 we should just fix the temporary path inside the SVG file. I did a quick test on my computer and confirmed that the following change inside the SVG file will work:

<g
     inkscape:label="Layer 1"
     inkscape:groupmode="layer"
     id="layer1">
    <image
       sodipodi:absref="C:\Users\ansom\AppData\Loca\AFM\surfacepic.jpg"
       xlink:href="../AppData/Local/AFM/surfacepic.jpg"

to:

<g
     inkscape:label="Layer 1"
     inkscape:groupmode="layer"
     id="layer1">
    <image
       sodipodi:absref="%LOCALAPPDATA%\AFM\surfacepic.jpg"
       xlink:href="../AppData/Local/AFM/surfacepic.jpg"

Note: I am using Inkscape v1.0.1. Let me upgrade to v1.2 and try again...

[ciozi137]

👍 👍 in Inkscape v1.2.2

[ciozi137]

[Monkeymerlot]

My VI analyzer will flip if there is wires with small bends but otherwise looks good! We should also make it clear that there is a change in the SVG files in Asana and provide a template file..

[ciozi137]

@Monkeymerlot I just pushed changes. I agree there should be an easy way to update the SVG files. Maybe "Update_SVG_surfacepic_path.vi"???

[Monkeymerlot]

Yeah I can piece together something that will do it properly reusing parsing tools that I already made. I have a meeting from 11:00 to 4:30 but can do it after that...

[Monkeymerlot]

Also did you change the background image in lithography and verify that it automatically updates in the inkscape file?

[Monkeymerlot]

Another thought: (sorry for spamming you guys) what if the parser automatically corrects this if it finds that it is in the old location? That way the users wont need to really worry about the changes...

[ciozi137]

@Monkeymerlot differences in background image in two svg files:

[ciozi137]

OK apparently I didn't properly test before. I changed the sodipodi:absref node, which is some weird optional field. Let me try again with xlink:href... https://github.com/levylabpitt/AFM-Lithography/issues/93#issuecomment-1625529337: Test: Not yet https://github.com/levylabpitt/AFM-Lithography/issues/93#issuecomment-1625532521: Correct old links: I like this idea, but it should only update surfacepic.jpg links, and not if the user chooses to embed or link a different file?

[Monkeymerlot]

@ciozi137 Yes I would check to see if any of the images linked in the file were surfacepic.jpg, and that they were located at the correct location. If they were not, then I would make the changes. sodi:podi is inkscape specific nodes I believe, but not straight XML/SVG.

[ciozi137]

Inside the SVG file: xlink:href="file:///%LocalAppData%/AFM/surfacepic.jpg" did not work xlink:href="../AppData/Local/AFM/surfacepic.jpg" did work

[Monkeymerlot]

Can you also post (generically) where the svg file is located?

[Monkeymerlot]

Also this might be helpful, in particular the iri descriptions: https://www.w3.org/TR/SVG11/struct.html#ImageElement

[ciozi137]

My svg file is on Desktop. The background image I'm trying is %localappdata%/afm/surface.jpg I see...perhaps ../ is relative to Desktop

[ciozi137]

I moved the SVG file to G:\.shortcut-targets-by-id\0B8-gGFa6hkR4XzJJMDlqZXVKRk0\ansom\temp\drawing.svg and Inkscape changes the image href to xlink:href="file:///C:/Users/ansom/AppData/Local/AFM/surfacepic.jpg"

[Monkeymerlot]

I pushed some changes to the parsing classes to the repository...

[ciozi137]

@Monkeymerlot what if we just store surfacepic.jpg beside the SVG file? For G:\.shortcut-targets-by-id\0B8-gGFa6hkR4XzJJMDlqZXVKRk0\ansom\temp\drawing.svg we then have xlink:href="./surfacepic.jpg" inside the file

[Monkeymerlot]

New Branch: svg-background

[Monkeymerlot]

@Monkeymerlot what if we just store surfacepic.jpg beside the SVG file? For G:\.shortcut-targets-by-id\0B8-gGFa6hkR4XzJJMDlqZXVKRk0\ansom\temp\drawing.svg we then have xlink:href="./surfacepic.jpg" inside the file

This is actually what I am going to implement. I will have the parser check that the surfacepic.jpg path is correct in the SVG file, and if not, correct it. I have to play around with the XML parsing utilities in LabVIEW as they are reference based so I might make a subclass to deal with handling the references and parsing utility to avoid cross coupling of the SVGImage class and the ParseSVG class.

To elaborate, I am parsing everything, then I have a check in the SVGImage class to make sure that the surfacepic.jpg is in the right location, then I use the ParseSVG class to find that particular node and change it. Before the SVGImage class was essentially a storage class without any serious methods other than a constructor/initialize method, so it was only created after the SVG was completely parsed.

[Monkeymerlot]

@ciozi137 Do we want to delete the temporary file that is stored next to the svg file once we either change the svg file path or close the program?

[ciozi137]

@Monkeymerlot good question. I actually think the background image should just match the svg file name

[Monkeymerlot]

@ciozi137 Also can you test the changes made on the svg-background branch? It should change the file if it detects the wrong path, and it also is saving surfacepic.jpg next to the svg image.

Regarding the background image filename we can easily change that in the future.

[ciozi137]

@Monkeymerlot this error:

[Monkeymerlot]

OK I am not sure what the issue was but I removed it from the library and then put it back in. Hopefully that fixes things. Let me know what happens.

[ciozi137]

@Monkeymerlot I made the following test and it looked ok to me:

I think the background image should have the name of the SVG. Any reason not to?

[Monkeymerlot]

@ciozi137 There is no reason that it shouldn't, I just wanted to make sure that it was working correctly first with the existing images. I will add a legacy check and still look for "surfacepic.jpg", but also look for the name of the svg with the jpg extension

[Monkeymerlot]

@ciozi137 Try it now and see if it is what you were thinking...

[ciozi137]

@Monkeymerlot how about drawingname.svg_surfacepic.jpg or drawingname_surfacepic.jpg

[Monkeymerlot]

I'm going to straight out veto (do I even get a veto?) the first one but the second one is fine. Let me know what you decide (ie drawingname_background or drawingname_surfacepic etc) and I can implement it.

[ciozi137]

Lol i agree that the second is better. Let's keep the name_surfacepic to keep a little consistency with the old name

[Monkeymerlot]

OK the latest commit should have this issue completely fixed. (fingers crossed). Let me know what your tests show.

[ciozi137]

@Monkeymerlot thanks! @mkdiet will test on the Cypher