Jump to content

Recommended Posts

There are many threads regarding relative paths for linked images and wanted "pack & go" functionality. I read it over and over and I start to think that these solutions are partly really complicated for a thing that already has a easy solution if you look at other software.

I reseaeched how customer photo book creation software like the one of CEWE, Rossmann and Pixum does it.

They all have a "inages"/"ressources"/"assets" folder right beside the document file.

This folder is managed by the application: If you drag an images from anywhere into your document (application window) the file is copied into that folder. If you delete the image from the document the file gets deleted to. If you change the file in the folder ot gets updated in the document like Publisher does this automaticly with linked ressources (if the option is acticated).

It's really simple and works basicly the same way the APUBs "internal filesystem" works.

This could be a third mode alongside with "embedded" and "linked".

So there would be no need to do a regular "pack & go" to "clean" your image directory from unused files. Publisher should automatic delete them in this mode.

Of course if you delete a used file it should show up with a broken image indicator in the document. But using this mode you know what you do.

Again, every major photo book creator works this way and I believe this would solve all the problems people asking for relative paths and pack&go have.

Also in my workflow it's cumbersome to copy my selected images first to another place. I browse my photo collection looking for fitting photos as I build up a new page and drag them in, look how they fit into what I want to show and maybe I remove it again and use another. Having them to copy to an image folder first is a bit annoying.


Windows 10 Pro x64 (1903). Intel Core i7-9700K @ 3.60GHz, 32 GB memory, NVidia RTX 2080
Affinity Photo 1.7.2.471, Affinity Designer 1.7.2.471, Affinity Publisher 1.7.2.471

Share this post


Link to post
Share on other sites

That's an interesting idea but not usable in all situations.

For example we use different resources and some are on servers and should stay this way, since they can be modified by coworkers (like ads or logos/commons files) between the time we begin a document and the moment we create a PDF for print.

 

Exporting a document with each fonts and resources used, and a PDF for print is the usual way to create archives (at first it was used for sending documents -- not PDFs  --to printers) we'll be able to open in few years without missing elements. We can do this too when needing to send a document to someone else.

Since this is a way to collects linked elements in a "links" folder, fonts in a "fonts" folder, etc., with plugins/scripts those app's fonctions can be used to store documents and elements in a more complex way to store/archive/use in a database for larger companies.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.