URGENT - how do I open a document made with 1.8 in 1.7.3

[Alex_M]

I've got an urgent job to deliver and after updating Affinity Photo to 1.8 and working with it for a while I noticed a few serious bugs that makes it impossible to continue using this version normally - masks not resizing when resizing documents, teleporting cursor when adjusting brush size etc. Now I found out I can't even downgrade to 1.7.3 because it can't read documents made with 1.8! Any help is GREATLY appreciated.

[Fritz_H]

Since Updates from 1.7 to 1.8 are free Serif expects the user to install the Update - I guess.

kind regards
Fritz
 

Update: found out that I misunderstood the posting of Alex_M; sorry.

[walt.farrell]

You could try the 1.8.1 beta of Photo if you're on Windows. Perhaps some of your issues are fixed.

If you're on Mac, try the 1.8.2 beta.

The official release of the retail updates for all three stores should be available soon.

[Pšenda]

1 hour ago, Alex_M said:

Now I found out I can't even downgrade to 1.7.3 because it can't read documents made with 1.8

Try export and import (for example pdf). Or try new beta with fixes. 

[Alex_M]

Thanks a lot for the suggestions, I'll try them out!

[R C-R]

5 hours ago, walt.farrell said:

If you're on Mac, try the 1.8.2 beta.

As of a few hours ago, the Mac 1.8.2 retail version should be available, either from the Affinity Store if bought there or (often with a lot of coaxing to get it to appear) from the Mac App Store if bought there.

[firstdefence]

3 hours ago, R C-R said:

from the Mac App Store if bought there.

It’s definitely on the Mac App Store

[R C-R]

31 minutes ago, firstdefence said:

It’s definitely on the Mac App Store

As I explained here, for me AP 1.8.2 did not initially appear there, thus my 'coaxing' remark.

[Fritz_H]

The whole issue is caused by Serif changing the Fileformat with every version.
It´s about time that Serif moves to a file-format which is backwards-compatible.

No discussions about that please: it IS possible.
Older Versions of the Software will simply drop/ignore features that are not available.
This will also end the mess with Beta-Version-Files that can not be opened with the release-Version of the Software.

Fritz

[Pšenda]

14 minutes ago, Fritz_H said:

This will also end the mess with Beta-Version-Files that can not be opened with the release-Version of the Software.

You have noticed that files stored in beta 1.8.1 can be opened in customer version 1.8.0.

Serif changes the file format only when absolutely necessary, which is certainly needed quite often due to the versatility of the format for three different applications. It certainly does not do this because it forces an upgrade, which has nothing at all thanks to free.

[R C-R]

37 minutes ago, Fritz_H said:

Older Versions of the Software will simply drop/ignore features that are not available.

That would mean dropping/ignoring not just any features but also any layers that require something supported only in a later version.

For what should be obvious reasons, most users would not find that acceptable.

[Alex_M]

The new 1.8.2 version of Photo seems fix the mask resize problem, but the mouse cursor still teleports when resizing the brush. ☹️ Looks like I'll be moving back to 1.7.3...

[walt.farrell]

26 minutes ago, Alex_M said:

The new 1.8.2 version of Photo seems fix the mask resize problem, but the mouse cursor still teleports when resizing the brush. ☹️ Looks like I'll be moving back to 1.7.3...

Gabe gave you a workaround for the teleporting in your other thread: just release the left-click first. Seems simpler than downgrading.

[Alex_M]

That's nice to know, but this means I have to always intentionally focus on my order of actions/clicks which I don't have the time and nerves to do. Everything was working beautifully up until version 1.8.

[Fritz_H]

5 hours ago, R C-R said:

That would mean dropping/ignoring not just any features but also any layers that require something supported only in a later version.

For what should be obvious reasons, most users would not find that acceptable.

If you have to chose: 
either rescue 80% (?) of your work (20% are lost because features are not available on older Version..)
or lose 100% because the file can not be opened at all..

what do you prefer?

kind regards
Fritz

[Pšenda]

56 minutes ago, Fritz_H said:

what do you prefer?

As I wrote a few posts above, if you need to transfer files from a later (backward incompatible) version to an older version, there is no problem to export the data (pdf, svg, eps, ...) and import it into the older version with about 100% success. I prefer this.

[R C-R]

1 hour ago, Fritz_H said:

If you have to chose: 
either rescue 80% (?) of your work (20% are lost because features are not available on older Version..)
or lose 100% because the file can not be opened at all..

How could they know in advance how to code the then current versions to ignore anything that relied on a feature in some future version without knowing how that future version would affect the native file format?

[Fritz_H]

58 minutes ago, Pšenda said:

As I wrote a few posts above, if you need to transfer files from a later (backward incompatible) version to an older version, there is no problem to export the data (pdf, svg, eps, ...) and import it into the older version with about 100% success. I prefer this.

lets say you have a Publisher-File from Version 5.1 (timetravel?  ;-) )
The File contains several Layers, FX, embedded images, typographic Design-Elements etc. - some are standard-Features that ARE supported in your Version 4.0 and some that are not.
Do you really want to start from Scratch with a File-Format that contains NO Affinity-related parameters at all?
Or are you happy about all those Elements that are available/rescued and do no have to be re-created again?

Fritz

[Fritz_H]

37 minutes ago, R C-R said:

How could they know in advance how to code the then current versions to ignore anything that relied on a feature in some future version without knowing how that future version would affect the native file format?

I am not a developer, but if they use a structure like XML they can develop the File-Parser to drop all key-Words + parameters it does not recognize.
Only constraint: you are not allowed to change the meaning or parameter-Range of existing keywords - you are only allowed to add new keywords in the new Fileformat.

some how like:

Publisher file 5.0
  Size 
      Paper:  A4
      HTML:  1024x 768
Colorspace
     fallback: SWOP
     preferred:  Hyperspeed-Full-Color-Fantasyland-Colorspace 2.0

If your Version does not know any Size called "HTML" it will drop this option.
If your Version does not support this fancy Colorspace, it will drop this and default to SWOP.

Of course, there will be a message to the user that some elements could not be properly imported.

If done properly, the Software could be so smart to keep the "unknown" keywords and parameters - just in case the file will be opened
by a newer Version of the Software later again.

This way you may lose e.g. the new shadow-effect since this one is not yet supported in your Version, but you can see and use major parts of the File.

Fritz

[Wosven]

The same as we do with ID or other type of files for different reasons. The important trick is to keep a visual (PDF or image, depending of the file) to check each the final result once open in an earlier version of an app.

And yes, that's better than loosing hours of work. It goes with the "save often, use backup, etc." litany. We're used to this, but it happens that I finish working on a file and realize that it's the 1st save I do! I learn a good lesson from this too: you do it faster—but not happier—the second time!

[R C-R]

18 minutes ago, Fritz_H said:

I am not a developer, but if they use a structure like XML they can develop the File-Parser to drop all key-Words + parameters it does not recognize.

You do not need to be a developer to open a native format file in a text editor to get some idea of what the structure of the native file format looks like. Do that & should be pretty obvious that it is not XML or very XML-like, nor does it use keywords as such.

Besides, the staff have told us that the file structure is proprietary, & that among other things that it is optimized for fast loads & saves, includes mipmaps, does not necessarily load the entire file into memory at any one time, is serialized, & so on.

So basically, not only would they have to make fundamental changes to the file format itself, they would also have to do the same for the application code that opens it.

[Fritz_H]

18 minutes ago, R C-R said:

So basically, not only would they have to make fundamental changes to the file format itself, they would also have to do the same for the application code that opens it.

Well, it was their decision to do it wrong - not mine.
Perhaps they will do it right with version 2.0

https://en.wikipedia.org/wiki/OpenDocument
" The Open Document Format for Office Applications (ODF)  (..) is a ZIP-compressed[6] XML-based file format for spreadsheets, charts, presentations and word processing documents. "

https://en.wikipedia.org/wiki/Office_Open_XML
" Office Open XML (also informally known as OOXML or Microsoft Open XML (MOX))[3] is a zipped, XML-based file format developed by Microsoft for representing spreadsheets, charts, presentations and word processing documents. "

see:  C:\Users\%username%\AppData\Roaming\Affinity\Photo\1.0\Settings:   all XML

putting some KB of structured Data into the Header of a file does not slow the opening-process down.

Fritz

[R C-R]

34 minutes ago, Fritz_H said:

Well, it was their decision to do it wrong - not mine.

Their decision was to create a proprietary file format that can support extremely high pan & zoom rates, unusually high memory efficiency, novel data serialization methods that allow piecemeal reading from & writing to native format files (which improves the performance of the history & snapshot features among others), & so on.

There is nothing wrong with that. The only thing they got very wrong recently was not catching quite a few serious bugs that appeared in the initial 1.8 retail versions. They are working to fix that as quickly as they can & have just now released 1.8.2 retail version updates that fix most of them.

[Fritz_H]

58 minutes ago, R C-R said:

Their decision was to create a proprietary file format that can .....

Whatever. For me a file-format is a format for data at rest, for data-storage - not data-manipulation.
the latter has to be done completely in RAM - that is what RAM is made for: fastest possible data-manipulation.

We will perhaps never agree on this, but for me a Software that changes its file-format at every minor Update* is not suitable for PRO-Users.

* https://en.wikipedia.org/wiki/Software_versioning

Fritz

[walt.farrell]

30 minutes ago, Fritz_H said:

a Software that changes its file-format at every minor Update*

Serif does not do that. Minor updates are things like 1.8.0, 1.8.1, 1.8.2.

1.8 compared to 1.7 is a major update, and major updates are where Serif has changed the file format as far as I know.