Affinity Publisher Customer Beta - 1.10.1.1135

[AdamW]

Status: Beta
Purpose: Fixes
Requirements: Purchased Affinity Publisher
Windows Store: Not Submitted
Download: Download
Auto-update: Not Available

---

We are pleased to announce that Affinity Publisher Customer Beta 1.10.1.1135 is now available as a download from the link above.

If this is your first time using a customer beta of an Affinity app, it’s worth noting that the beta will install as a separate app - alongside your store version. They will not interfere with each other at all and you can continue to use the store version for critical work without worry.

This beta is an incremental update to the 1.10.0 version recently released to all customers. We recommend that you use this beta in preference to the release version if you are affected by any of the issues listed below.

---

• Fixed instance where a document could get into a state where it could not be saved
• Invalid URL hyperlinks prevent PDF export
• Fixed crash on launch when a sync'd asset references an unavailable font

Affinity Publisher for Windows 1.10.0 Release Notes

---

To be notified about all future Windows beta updates, please follow this notification thread 

To be notified when this Publisher update comes out of beta and is fully released to all Publisher customers, please follow this thread

[Petar Petrenko]

Why 1.10 beta when we got 1.10 retail ones?

[walt.farrell]

32 minutes ago, Petar Petrenko said:

Why 1.10 beta when we got 1.10 retail ones?

It's a beta of 1.10.1, Petar. The retail is 1.10.0.

[walt.farrell]

2 hours ago, AdamW said:

Fixed crash on launch when a sync'd asset references an unavailable font

What is a "sync'd asset"?

[Patrick Connor]

1 minute ago, walt.farrell said:

What is a "sync'd asset"?

one you download via My Account (in this case the very old iOS 11 UI Kit)

[narrationsd]

@AdamWVery happy to have this, as all your work; often compliment it on DPReview.

Yet you are repeating a pattern here that isn't so healthy, no?

• you release, we are happy
• immediately, you push a Beta...with very important fixes (cf. breaking projects so they don't open; also, crash on your downloaded assets)

This has happened each time recently, and I can't think it makes non-beta users happy, if they even know of it.

Or get bitten by the important issues..

I fully appreciate about release cycles, and how things turn up anyway, but since you come back each time so rapidly, it seems clear you know about the problems when you release, and just don't re-initiate the testing to assure no retreats, for an actually sound release.

Thoughts from rather dev-experienced here; hope they get suitable wakeups with your crew....

Best,
Clive

[Tegwyn]

@narrationsdBased on watching some of the threads about the can't-save bug, I don't think they knew about it when they released. They probably just scrambled to examine the reported files and crash logs and fix it, as I would expect for a bug that affects saving.

[AdamW]

@narrationsd Thanks, the beta is to address issues that have been highlighted by our support since the release. Once we have confidence these have been resolved we will issue a retail update.

[JRC58]

I appreciate your efforts for maintaining the apps updated. However, the problem several of us reported about the use of the "." of the numerical pad as a decimal comma (in spanish and other languages) still continues without correction. In the past, I think version 1.9 or 1.8, if I typed the "." of the numerical pad in the transform menu (for example for changing the width of a rectangle) it was interpreted as a comma and aplied the change accordingly. For example, 12.9mm was interpreted as 12 mm and 9 tenths. However, none of the betas (neither the 1.10) after this versions recognize the "." of the numerical pad as a comma, so 12.9mm is interpreted as 129mm. This force us to use the "," of the main keyboard to write decimals, which is quite annoying and much less productive. I pointed out this issue several times but it seems that nobody at Affinity seems to have paid attention to my problem. The Affinity team should also take care of the spanish (and other languages) users, not only english users.

Thanks

javier 

[MadeGlobal]

NOT FIXED for opening my 1.9 afpub file. Still crashes in the same way.

[Patrick Connor]

6 hours ago, MadeGlobal said:

NOT FIXED for opening my 1.9 afpub file. Still crashes in the same way.

Sorry, not yet. This quick beta was built specifically to address the three items specifically listed and no other issues yet. That does not mean that your problem will not be investigated or fixed before 1.10.1 is formally released, this is just the first patch for a few issues currently affecting many people.

[lacerto]

(...)

[Alfred]

4 minutes ago, Lagarto said:

(not compliant to RFC 3986)

A grammatical nitpick here: it should say “not compliant with” or “not conforming to”. I wonder where the quoted wording comes from.

[lacerto]

(...)

[salgood]

Thanks the beta seems to do the job so far!

[Sam Neil]

On 8/13/2021 at 10:21 AM, Lagarto said:

Nothing at all seems to have been fixed -- I wonder if even correct build got packaged in... Or do I need to reset something?

PDF_create_action(p_0x000001F009A81D30, "URI", "url={mailto: Jdoe@acme.com}")
[Last exception 2863 in PDF_create_action]["URL 'mailto: Jdoe@acme.com' is invalid (not compliant to RFC 3986)"]

PDF_create_action(p_0x000001F867273660, "URI", "url={mailto:Jdoe@acme.com?subject=Test message åäö}")
[Last exception 2863 in PDF_create_action]["URL 'mailto:Jdoe@acme.com?subject=Test message åäö' is invalid (not compliant to RFC 3986)"]

This is exactly same behavior as in the current release:

1) The error halts PDF creation. It should never do that, but continue creation after possibly having notified user about incorrect mailto addresses having been found. It could notify this also in Preflight.

2) The code does not itself try to compose a valid address from the user-given plain text parts, but just adds mailto:, and stops there. It should be capable of removing any preceding or tralilng spaces from the address part, and be able to percent-encode spaces and non-ASCII characters in parameter and data parts. Many apps create mailto links without percent encoding and this should be passed through in context of PDF creation. Most mail clients (e.g. Outlook and macOS Mail) can process unencoded parameter data at least in subject parameter without any problems. If you at some point process mailto links of opened PDFs or IDML files, you probably find that most of these links will come with unencoded subject data. 

3) The app should not leave URI creation to the user but ideally have Email field that only accepts address part (no ? and & allowed and spaces removed), and then provides the parameter field (InDesign has a field called "Subject", but it can probably handle other headers, as well). The point is: if the user is not supposed to type in "mailto:", they should not be be supposed to type in stuff like ?subject=My%20subject&body=My%20body%20text either. 
 

 

[lacerto]

(...)