Some "Edit Text Style" settings will not save

[garrettm30]

When trying to edit a paragraph style from the "Edit Text Style" dialog, I have noticed these problems with saving certain values:

• Typography script: changing from from [No change] to Auto will not save
• Typography language: changing from [No change] to Auto will not save
• Font Traits: changing from Regular (or anything else it seems) to [No change] will not save
• Baseline: trying to set "Auto" is not possible, even before saving the edits to the text style

On that last point, I also notice that "auto" is not an option when in Character Studio. Is "auto" in practice any different than setting 0?

Edited August 5, 2019 by garrettm30
Added the Front Traits problem to the list

[thomaso]

What different behavior do you expect between [No change] and [Auto], unless you haven't changed a default language setting somewhere else?

In my opinion the [No change] setting = [Auto] as long it is not overwritten by another choice at any place.

So my default languages in Character Panel are all set to [Auto] and therefore will be used with [No change] – the spelling language excepted, which does not have [Auto] but [None] only, which does not make much sense. In my experience both the Typography Script / Typography Language are connected to the Spelling language and become automatically used accordingly without the need to set them.

On 8/5/2019 at 8:31 PM, garrettm30 said:

• Baseline: trying to set "Auto" is not possible, even before saving the edits to the text style

On that last point, I also notice that "auto" is not an option when in Character Studio. Is "auto" in practice any different than setting 0?

Yes. Actually there is no [Auto] for this baseline setting, because it used for baseline correction at specific spots (of a single word for instance, if you have assigned a different font for instance). So not changing this baseline setting means using no correction but the default instead – quite auto.
I assume the list in the text style options window is one and the same for various pull-down menus there – regardless whether each of the entries is necessary or redundant.

 

[garrettm30]

3 hours ago, thomaso said:

What different behavior do you expect between [No change] and [Auto], unless you haven't changed a default language setting somewhere else?

In my opinion the [No change] setting = [Auto] as long it is not overwritten by another choice at any place.

But they are unique settings with differences, and if they are both presented as options, then the dialog should be able to save the user's choice. If a user sets an option that is not grayed out and then saves, he naturally assumes a bug if his choice was not retained. If that is intended behavior, then it should be rethinked, such as removing the superfluous setting (which may be the case for baseline auto)

To illustrate the difference between the two Auto and [No change] for the typography options, let's say you select some text with Typography language set to "Latin."

• If you apply a style whose Typography language setting is [No change], then the text will still have "Latin" set (or else, it will be set according to a parent style settings)
• If you apply a style whose Typography language setting is Auto, then the Typography language setting for that text will be changed from "Latin" to Auto.

They are distinct settings for a reason.

[thomaso]

7 minutes ago, garrettm30 said:

If a user sets an option that is not grayed out and then saves, he naturally assumes a bug if his choice was not retained.

In general I agree – but here I can't because I still have the impression that [No change] means an automatic setting, too. It possibly results in the same as [Auto], unless [Auto] was changed somewhere else. So the UI refusing to keep [Auto] but jumping back to [No change] may be confusing but would not do any harm or result in errors in the text. In that case it would be a cosmetic issue rather than a bug with bad consequences to the data you create.

10 minutes ago, garrettm30 said:

If you apply a style whose Typography language setting is Auto, then the Typography language setting for that text will be changed from "Latin" to Auto.

... and will remain Latin, because you had set Latin as Language before. So it's automatically set to Latin – which does not result in a change towards [No change].

Can you describe what you expect to see in your text frame when switching and saved successfully from [No change] to [Auto] in the character text style window which you assign to a text which you have set to "Latin" in Character Panel? – Whereas I do assume an example would need to use a language which has its own fonts, as Greek and Cyrillic for instance, to illustrate the full use of all the 3 types of language settings.

[garrettm30]

13 minutes ago, thomaso said:

and will remain Latin,

This is where you have misunderstood. The Character Studio will no longer show Typography language of the selection to be set to "Latin," but rather to "Auto," which is of course a distinct setting.

When I set a style to have "Auto" as its Typography language, I have made a conscious decision to explicitly clear out any other setting or mix of settings for Typography language that the selected text may have had. Often it could be text pasted from another program, and it may have its own settings (which, by the way, is what led me to discover this bug). When I apply a style, I want to clear out all local overrides unless I have specifically chosen otherwise, and if I leave a setting at [No change], then I will have style overrides for that attribute left in my text.

[garrettm30]

33 minutes ago, thomaso said:

Whereas I do assume an example would need to use a language which has its own fonts, as Greek and Cyrillic for instance, to illustrate the full use of all the 3 types of language settings.

It may be helpful to understand that languages with other scripts do not necessarily need separate fonts. It only depends on the support of the font. For example, I do not need to change the font in this post to be able to type this passage from the Greek New Testament: Οὕτως γὰρ ἠγάπησεν ὁ θεὸς τὸν κόσμον, ὥστε τὸν υἱον τὸν μονογενῆ ἔδωκεν.

Or I could even try this Hebrew from the Hebrew Old Testament:

אשׁרי האישׁ אשׁר לא הלך בעצת רשׁעים

Both of those scripts display fine on my system with the default font (which is Roboto).

(By the way, my specific work involves publishing Christian religious material in French. I do occasionally need to print the odd Greek or Hebrew text).

[thomaso]

7 hours ago, garrettm30 said:

Often it could be text pasted from another program, and it may have its own settings (which, by the way, is what led me to discover this bug)

Can you paste here or in an .afpub an example?

7 hours ago, garrettm30 said:

It may be helpful to understand that languages with other scripts do not necessarily need separate fonts.

You even don't necessarily need to assign a language in AfPub if the font supports various languages, possibly ordered its glyphs according to the Unicode table
https://unicode-table.com/fr/

In this sample all text is formatted in one identical style;
note the language settings, which seem to support neither Greek nor Hebrew:

7 hours ago, garrettm30 said:

Both of those scripts display fine on my system with the default font (which is Roboto). 

... and they also show fine in my and your browser, even though the font 'Roboto' isn't used to display, and neither you nor me has switched a browser language to Greek and Hebrew.
Possibly the operating system is involved, too, in correct font display – regardless of the application.

So I ask you again to show visually what kind of bug you suspect or have discovered with the [No change] versus [Auto] setting not being saved in your style. The easiest would probably be an .afpub.

[garrettm30]

2 hours ago, thomaso said:

So I ask you again to show visually what kind of bug you suspect

Tomaso, you seem to be a very helpful fellow, as I have observed how you have often been helpful around the forum. I do believe you are an asset to this community. I’m sorry to say that this interchange is starting to seem like another bug I reported recently, and I shall reply the same way: This is a bug report intended for Serif's benefit. I have provided the details to Serif as clearly as I think I can. It is up to Serif to decide whether what I have pointed out is in fact an unintended  bug, whether there is a UX improvement that could be made or some clarification that could be provided, or whether they just wish to dismiss or ignore it. If they need more information, I am confident they will let me know, I and I will do my best to provide it.

But if I have to go through several rounds of defending a bug report with fellow forum members who are not connected with Serif, then I feel I will just get discouraged with the process and give it up completely. 

[Patrick Connor]

Sorry.

Thank you for reporting a problem using 1.7.x . It appears that a member of the Affinity QA team didn't get round to fully investigating this specific report posted in the bugs forums. We are very sorry for this oversight. Yours is one of a number of reports that I am posting this apology to, using an automated script.

Now we have released 1.8.3 on all platforms containing many hundreds of bug fixes, and we hope your problem has already been fully addressed. If you still have this problem in the 1.8.3 release build, then the QA team would really appreciate you reporting again it in the relevant Bugs forum.

• Report a Bug in Affinity Designer
• Report a Bug in Affinity Photo
• Report a Bug in Affinity Publisher

Each of those links above contains instructions how best to report a bug to us. If that is what you already did in this thread just copy paste your original report into a new thread. We appreciate all the information that you have including sample files and screen shots to help us replicate your problem.

This thread has now been locked as the QA team are not following the threads to which this automatic reply is made, which is why we would appreciate a new bug report if you are still have this problem in the current 1.8.3 release build.