empty document > file size?

[thomaso]

EDIT: the answer to the file size question is based in my Affinity app colour preferences, respectively the current CMYK profile setting when creating a document. Then profiles get embedded to be prepared for any later switch in colour handling (e.g. the UI colour model / space selection) or conversion with the goal of keeping the document independent from its creating computer.
==========

I experience a minimum document file size of 1.8 MB even for an empty 1-page document. There are no objects and no Assets are included.

– Any hints what causes this size?
– Could one re-save this in V1 + upload if it results in a smaller size, please?

empty but 1.8 MB.afpub

[v_kyr]

Empty A4 APub v1 file = 9 KB ...

• empty_a4.afpub

[thomaso]

Yes, I am aware of that. I can re-save small documents from the forum without increasing their file sizes. But I can't create a document below 1.8 MB. – Could you Save-As my .afpub in V1 + upload it, please?

[R C-R]

11 minutes ago, thomaso said:

Could you Save-As my .afpub in V1 + upload it, please?

I did not upload it but weirdly I got a second 1.8MB sized APUb V1 document. However, when I create a new empty V1 doc & save it I get only about a 10KB (on disk) file.

So my guess is there is something that has corrupted your file that causes it to include some useless data....

[v_kyr]

1 hour ago, thomaso said:

Could you Save-As my .afpub in V1 + upload it, please?

That would have the same odd size then, so what should an upload yield to here? - Instead you maybe should check/compare/diff via some HeX editor why your empty doc occupies ~ nearly 1MB more in content size. Or let someone from Serif check instead where the discrepancy comes from.

[thomaso]

49 minutes ago, R C-R said:

So my guess is there is something that has corrupted your file that causes it to include some useless data....

Thank you both for checking. So I would appreciate if a Serif moderator could detect what is causing the size that makes my APub create empty documents of 1.8 MB.

It appears especially weird because also an .afdesign created in AD has the same 1.8 MB – whereas an empty .aphoto has 0.48 MB only, while all three documents have same setup: Din A5, sRGB.

empty artboard file size.afdesign

empty canvas sRGB.afphoto

[v_kyr]

The turquoise part doesn't exist in my empty APub v1 A4 file and I can tell so far that it has nothing todo with embedded thumb pngs, as both files have just 1 plain white one of ~ 2 KB.

[thomaso]

Thanks, @v_kyr, unfortunately I am unable to interpret hex code. I mainly notice the different length between your 9 kB and my 1.8 MB .afpub, and have no idea what parts are expected to be identically in this two empty .afpubs (with not identical page size and margins).

[v_kyr]

10 hours ago, thomaso said:

unfortunately I am unable to interpret hex code

Well as the file formats are proprietary and undocumented there isn't much you can interpret here, without having further file format structure insights.

10 hours ago, thomaso said:

I mainly notice the different length between your 9 kB and my 1.8 MB .afpub, and have no idea what parts are expected to be identically in this two empty .afpubs (with not identical page size and margins).

At least the file start signature (BOM = 00 FF 4B 41 0B) tells us that it's an Affinity file and at the file end the embedded thumb image PNG signature (BOM = 89 50 4e 47 0d 0a 1a 0a) is known to us. - The concrete meaning of the other encoded offset sections isn't really known here to us, but it's viewable in a HeX diff comparision that there is a bunch of much more contents in your specific empty file as usually.

As I'm sure the Affinity team has some tools to read out a file's sections & contents, they may can tell you what sort of overhead data is additionally incorporated into your empty files here.

[thomaso]

18 minutes ago, v_kyr said:

PNG signature (BOM = 89 50 4e 47 0d 0a 1a 0a) is known to us.

Thanks for the link, I wasn't aware that certain contents has a general, non-proprietary HEX entry.

This, and the fact that I noticed ~ 1-2 years ago varying file sizes depending on the used document colour profile*, made me search now for "icc" in the hex/ascii of two .afpubs: While my 1.8 MB file contains "icc" twice your 9 kB file does not contain it.

*I had experienced that my .afpubs became larger when set to CMYK even with no pixel content but vector only. Then I noticed that also my RGB documents are larger than those from the forum and also that I get smaller file sizes when using "Generic RGB profile.icc" instead of "sRGB" … which meanwhile does not work any more but now creates the same 1.8 MB file size as an empty sRGB afpub. In a test done right now it gets even more odd:

RGB: sRGB –> 1.8 MB
RGB: Generic RGB profile.icc –> 1.8 MB

CMYK: Generic CMYK profile.icc –> 50 kB
CMYK: PSO coated.icc –> 1.8 MB

So, it appears quite likely caused by the used document colour space, respectively the profile that seems to write data into the empty document, triggered by whatever and getting worse over time.

empty Generic CMYK profile 50kB.afpub

empty CMYK PSOcoated profile 1.8 MB.afpub

[walt.farrell]

On the other hand, here is the info for my "empty" .afpub files (1 page, not facing, no master) in RGB (sRGB profile) and CMYK (SWOP V2 profile):

Both only 10KB.

empty-cmyk-swop.afpubempty-rgb-srgb.afpub

[v_kyr]

51 minutes ago, thomaso said:

This, and the fact that I noticed ~ 1-2 years ago varying file sizes depending on the used document colour profile*, made me search now for "icc" in the hex/ascii of two .afpubs: While my 1.8 MB file contains "icc" twice your 9 kB file does not contain it.

*I had experienced that my .afpubs became larger when set to CMYK even with no pixel content but vector only. ...

Hmm strange, what are the ICC profile file sizes themself on your system? - I can see here under my MacOS ...

Provided by MacOS

Generic RGB Profile.icc       2008 bytes
Generic CMYK Profile.icc  55300 bytes
sRGB Profile.icc                    3144 bytes
...

Provided by Affinity

CoatedFOGRA27.icc   557120 bytes
CoatedFOGRA39.icc  654352 bytes
...
USWebCoatedSWOP.icc 557168 bytes

 

[thomaso]

4 hours ago, v_kyr said:

Hmm strange, what are the ICC profile file sizes themself on your system?

I doubt the additional data is an ICC profile because the 1.8 MB don't fit to the size of the used profiles, e.g. PSOcoated_v3: 2.2 MB | sRGB: 3 kB.
Though I used to have ISOcoated_v2 with 1.8 MB years ago as app colour preference I don't see any reason why a profile should get saved with an .afpub / afdesign especially on my computer and only if the document gets created here. It seems my APub + AD run an extra task when creating a document that does not happen on another computer and also not in my APh.

- -

EDIT: I still have APub Beta 1.10.5 installed. With this a new created sRGB .afpub has 48 kB on disk. Hm?

I just renamed …
… the folder "~/Library/Application Support/Affinity Publisher"
… the file "~/Library/Preferences/com.seriflabs.affinitypublisher.plist"
of the retail version 1.10.5.
This caused APub to create a new preference folder + the .plist file (oddly with maintaining my custom panel setup on app launch) – but the issue of 1.8 MB for a new sRGB .afpub did not change.

Edited April 28, 2023 by thomaso

[v_kyr]

42 minutes ago, thomaso said:

I doubt the additional data is an ICC profile because the 1.8 MB don't fit to the size of the used profiles, e.g. PSOcoated_v3: 2.2 MB | sRGB: 3 kB.
Though I used to have ISOcoated_v2 with 1.8 MB years ago as app colour preference I don't see any reason why a profile should get saved with an .afpub / afdesign especially on my computer and only if the document gets created here. It seems my APub + AD run an extra task when creating a document that does not happen on another computer and also not in my APh.

AFAI recall the Aff file formats have certain zlib compressed sections, thus it's hard to tell if in your case ...

Quote

... my 1.8 MB file contains "icc" twice your 9 kB file does not contain it ...

... these maybe could then be twice embedded icc files here, or just some profile def references (...but that's just guessing here). - And as I already said, someone from the Affinity service/dev team might can better analyze your v1 empty file contents structure here and thus tell you what always happens here then. You maybe should mark/tag someone from them here so they may do recognize this thread.

[R C-R]

@thomaso, since I cannot duplicate this weird size issue in V1 or V2 of any Affinity app (& I do not think anybody else has been able to either?), this suggests there is something particular to your system that is the cause.

So maybe try an app reset (with the appropriate backups available if that does not help), or create new user account & seeing if the problem persists may help figure out what is going on?

[walt.farrell]

38 minutes ago, v_kyr said:

You maybe should mark/tag someone from them here so they may do recognize this thread.

It is considered impolite (and disruptive) to tag a Serif staff member who is not already participating in a thread, and Serif discourages doing that.

E.g., 

 

 

[v_kyr]

12 minutes ago, walt.farrell said:

It is considered impolite (and disruptive) to tag a Serif staff member who is not already participating in a thread, and Serif discourages doing that.

Which is deeply hidden in some unsusual place user thread, instead of being named (written down) in the forum guidelines or at least some forum FAQ! - However, then he can instead try to send an email to the Affinity user/help support, or file in some bug report about that theme/topic.

[walt.farrell]

1 minute ago, v_kyr said:

However, then he can instead try to send an email to the Affinity user/help support, or file in some bug report about that theme/topic.

Or simply wait until the Serif staff get to this topic. 

[v_kyr]

1 minute ago, walt.farrell said:

Or simply wait until the Serif staff get to this topic. 

That's probably the way it will go and let's hope for him that he  ... hasn't to wait for Godot. 😉

[thomaso]

@v_kyr, I did not expect an answer or solution from you in particular but rather respond my info to your hints for those who may need / interpret them accordingly. And, in my experience the lack is not in moderator reply delays but rather in Serif knowledge about odd issues like this. Means, I am confident a moderator will react here "in time" if there exists a known useful hint.

I doubt tagging a moderator or an email or bug report about a V1 issue will trigger more interest, in particular since the V1 bug forum became a less visible sub-forum of V2 bugs + further development of V1 was quit respectively limited to future issues with operating systems.

So, as long the causing culprit for this issue appears unknown to me the thread appears useful in this forum for either ideas of other users or as a hint for similar experiences, regardless of the app version.

[v_kyr]

26 minutes ago, thomaso said:

... So, as long the causing culprit for this issue appears unknown to me the thread appears useful in this forum for either ideas of other users or as a hint for similar experiences, regardless of the app version.

It's always useful to know the reason why something doesn't behave as expected, how to possibly prevent it and of course in case of a bug, if that has been fixed in the meantime for v2 apps or not.

[thomaso]

19 hours ago, thomaso said:

I just renamed …
… the folder "~/Library/Application Support/Affinity Publisher"
… the file "~/Library/Preferences/com.seriflabs.affinitypublisher.plist"
of the retail version 1.10.5.
This caused APub to create a new preference folder + the .plist file (oddly with maintaining my custom panel setup on app launch) – but the issue of 1.8 MB for a new sRGB .afpub did not change.

I wonder why renaming the folder "~/Library/Application Support/Affinity Publisher" only (not the .plist) creates a new folder (~200 kB) with obviously far less custom content BUT maintains to open APub still with my custom panel setting, while EDIT: assets + colour palettes + the Toolbar appear reset. And, again unexpected, these are maintained after opening + closing + opening APub, as if Apub would still read the contents of the renamed folder / or would store related info somewhere else. Does the .plist file cause APub to use content of the renamed folder?

While renaming the file "~/Library/Preferences/com.seriflabs.affinitypublisher.plist" also did not change my issue / the custom UI settings / contents when opening APub BUT then re-renaming the initial file (=back to the previous state) caused kind of a reset in the UI and my custom contents when APub got opened. Then a new empty test document gets created with 12 kB (9,699 byte).

So I got back by replacing both (folder and .plist) from a backup. Now I renamed the folder only (got it newly created as expected but with my unchanged UI), created the empty test document, saved (1.8 MB), closed document + app … and found in the autosave folder a 4 kB file (126 byte) and in the temp folder an 1.8 MB file. If I move both to the desktop, rename .autosave to .afpub, open this from the desktop, I get my test document open without any complaint AND again a temp file of 1.8 MB. –> This appears to mean the unwanted data were not in the .afpub (= the moved & renamed 126 byte .autosave) but gets created and placed as temp file by any of my custom settings when opening this document.

Maybe someone can get info from the attached zip: The .autosave (126 byte), the temp (1.8 MB) and the renamed autosave (.afpub, 126 byte) which opens the empty document even if the temp folder is empty.  test empty 1.8 MB afpub.zip

18 hours ago, R C-R said:

So maybe try an app reset

Yes, this indeed appears to solve the issue of the empty 1.8 MB file size. But I want to avoid the need to setup + reinstall / recreate the former UI + contents. Thus I currently still prefer and hope to detect the related custom preference respectively its culprit / causing file.

Edited April 29, 2023 by thomaso
When renaiming this library pref folder after 2 app relaunches the Panel settup is maintained but assets, palettes and Toolbar get reset.

[thomaso]

I found one/the culprit: Depending on the app colour preference for CMYK documents an empty RGB document seems to get this CMYK profile kind of embedded – kind of, because the profile file size is a bit larger than the the resulting .afpub (compare profile sizes shown above). After closing APub the autosave folder appears empty but a temp file is left, while this doesn't have the same size than the last saved document.

The APub library pref folder shows only 1 pref file as modified by the changed profile preference: The "~/Library/Application Support/Affinity Publisher/preferences.dat", which could mean (but doesn't have to?) the colour prefs are stored in this file. But because the issue occurs without closing APub (and thus without updating this pref file on disk) either another file is involved or it is an issue "by design" caused by the app and its Save procedure. – I can't see any use or need for this, especially as long no CMYK content was used in the .afpub. Accordingly this behaviour appears to be a bug to me.

Now I am curious if one can reproduce this behaviour? (in V1 or V2)
–> Recipe: with any CMYK profile preference create a new RGB document, e.g. from the "print" presets (RGB). -> Save & close. -> Choose another CMYK profile pref, create a new RGB document again, save & close, etc. …

[R C-R]

1 hour ago, thomaso said:

Now I am curious if one can reproduce this behaviour? (in V1 or V2)

As I have mentioned, I cannot. 

[thomaso]

2 minutes ago, R C-R said:

As I have mentioned, I cannot. 

Meanwhile the question is not simply whether you get an ~1.8 MB file but rather whether the file size of a newly created, empty RGB .afpub gets saved with a different file size if you choose a different CMYK profile in the app preference before creating the new document.