Footnote number style in note body

[crdasneves]

Hi guys,

Any local formatting or character style applied to the first word (or letter or space) in the note body text is also applied to the footnote number, even if it already has a character style. It's the same with endnotes and sidenotes (Windows 10, v. 2.0.3).

Could you please try to replicate that?

Best,
Cleber

 

[MikeTO]

Hi, I'm unable to duplicate this problem. Could you share the test document that shows this problem?

Here's a document that shows it working fine for these three styles.

note style.afpub

[Old Bruce]

I think the problem is caused by your use of [No Style] for the Note Body Style.

[crdasneves]

2 hours ago, MikeTO said:

Hi, I'm unable to duplicate this problem. Could you share the test document that shows this problem?

Here's a document that shows it working fine for these three styles.

note style.afpub

 

Thank you, but I guess I didn't explain it well. In your note 2, for example, please try to apply italic to the word "Strong" and see if "2" remains the same, just bold, or it turns italic and bold. In other words: the number heirs the character style from the first word (or letter, or space) of the text.

Here's what I get:

[crdasneves]

2 hours ago, Old Bruce said:

I think the problem is caused by your use of [No Style] for the Note Body Style.

 

Actually I've notice this in a text with styled footnote text, so I think it doesn't matter. Here's the test file from my firt post, now with a paragraph style.

footnote_number_style.afpub

[Old Bruce]

If what you are after is unique first word formatting then you'll need to use the Custom to set that note's Numbering back to a new Plain Character Style which is just [No Change] for everything. I am not sure if this is what you want. I made a Group Style called Footnote numbers for Character styles.

footnote_number_style by Bruce.afpub

[MikeTO]

Bruce is right and his workaround is the best approach.

But you've discovered a bug or at least a design flaw, it definitely should not work this way. Other apps don't do this so it's going to be a problem with imported footnotes from MS Word and eventually IDML.

This is similar to formatting bulleted or numbered paragraphs. You should be able to make the first character red or bold without changing the colour of the bullet or number. It's a common bug in word processors and page layout apps and even Microsoft has had issues with this, but the the standard is that the bullet and number must not be impacted by character attributes applied to the first character. I hope that Serif will see this thread and investigate the issue.

But for now please try Bruce's workaround. It wouldn't hurt anything if the bug is later fixed.

Cheers

[PixelEngineer]

 

 

EDIT: Here is a result after importing from MS Word with no modifications. 
This is the actual representation of importing into Affinity Publisher with no edit. Please disregard the earlier posted quote of my previous upload.  I was still able to adjust first words character style without affecting the number importing from MS Word.

[walt.farrell]

17 minutes ago, MikeTO said:

This is similar to formatting bulleted or numbered paragraphs. You should be able to make the first character red or bold without changing the colour of the bullet or number. It's a common bug in word processors and page layout apps and even Microsoft has had issues with this, but the the standard is that the bullet and number must not be impacted by character attributes applied to the first character. I hope that Serif will see this thread and investigate the issue.

As you say, that's how Bullets and Numbering works in Affinity, and it's the same approach used in the Footnote numbering, I think. You must specifically assign a Character Text Style to the Bullet/Number for lists, and to the Footnote Number, if you want it to be different from the Character formatting applied to the first character of the following text.

It would be complicated to change that in Affinity now. They would need to recognize files created the old way, and leave them working that way, while changing how it works for new files. And then users would have to deal with both in their work, which would be confusing.

[crdasneves]

20 minutes ago, Old Bruce said:

If what you are after is unique first word formatting then you'll need to use the Custom to set that note's Numbering back to a new Plain Character Style which is just [No Change] for everything. I am not sure if this is what you want. I made a Group Style called Footnote numbers for Character styles.

footnote_number_style by Bruce.afpub

Thank you, Bruce, I'll try it.

9 minutes ago, PixelEngineer said:

 

Here is result importing from MS Word where it is working for me.
 

You may also want to try something like this:
If you are creating these footnotes within Affinity Publisher. Place the cursor between the superscript and the word Strong  and go to the Notes panel and in the "In note body" > "Number style" select the desired character style you want to apply to that superscript.

Using this method will ensure that your link functionality is still intact.

 

I've found this issue importing a MS Word file; in one footnote the first word had a character style and the number got it.

9 minutes ago, MikeTO said:

Bruce is right and his workaround is the best approach.

But you've discovered a bug or at least a design flaw, it definitely should not work this way. Other apps don't do this so it's going to be a problem with imported footnotes from MS Word and eventually IDML.

This is similar to formatting bulleted or numbered paragraphs. You should be able to make the first character red or bold without changing the colour of the bullet or number. It's a common bug in word processors and page layout apps and even Microsoft has had issues with this, but the the standard is that the bullet and number must not be impacted by character attributes applied to the first character. I hope that Serif will see this thread and investigate the issue.

But for now please try Bruce's workaround. It wouldn't hurt anything if the bug is later fixed.

Cheers

Yes, it shouldn't be like this. In the file I mentioned, I solved it by cleaning up the first word style, inserting a zero-width space before it and then reapplying the style to the word.

Thank you all guys!