Callum

I believe this is the same as the bug Walt has referenced I'll update the report count.

If you don't have Publisher
Highlight the text and export to svg using Selection Only
The svg will show this:
<text x="-4.904px" y="62.941px" style="font-family:'Bauhaus93', 'Bauhaus 93', fantasy;font-size:92.139px;">what font?</text>

Hi Marce.isasmendi,
Welcome to the forums
If you could provide the info Ken has requested I should be able to look into this further with you.
Thanks
C

What font is that?
How was the É (Eacute) entered?
Is it a single character? (U+00C9)
Or was it entered as an E and a separate acute?
Some keyboard layouts enter separate characters.
Some fonts create the composite characters using different components.
And that may be confusing the PDF library (and/or APub).
Can you paste the text here?
Then we can see what characters are there.
Or can you attach that page of the APub doc?
 

Most likely you have Align to Baseline Grid turned on for all the Paragraph Styles. Turn it off for the "Navigation" heading Paragraph Style.
I use Exact leading for all my Paragraph Styles and do not use the Baseline grid. You may want to use the Baseline grid for the Paragraph Style which is used for the bulk/body/normal/whatever-it-is-called of the text. This will assist in lining up the text at the bottom of pages which is something a great many people worry about. An inordinate amount of worry in my opinion.

Draw your shape and make it much shorter than it would be, use the Knife tool to then "draw" the break. Use the Move tool to drag one end away a bit.
For more control over the shape of the break you could use the Pen tool to draw a line and then select the Pen's line and the object you are wanting to break and use Geometry > Divide.

Here's why it's happening:
You have a document that starts out as 62 mm wide, and 300 DPI.

62 mm is 2.4409448818897637795275590551181 inches, and at 300 DPI that is 732.28346456692913385826771653543 pixels.

Or, another way of looking at it: The conversion factor between DPI and DPmm is 0.03937007874015748031496062992126, so 300 DPI is 11.811023622047244094488188976378 pixels per mm, and again, 62 mm gives 732.28346456692913385826771653543 pixels.
  Of course, you can't have .28... pixels in a physical object, so the object must end up 733 pixels to hold all the data. At that point, 733/11.811023622047244094488188976378 gives you 62.060666666666666666666666666666 mm, and rounding up gives you 62.1 mm. I can't tell you the best way of handling it, though. Sorry.

Something seems to have happened behind the scenes. My account became locked since creating it. I can only surmise I've locked it by too many "failed" login attempts with my correct credentials or something funny happened between starting it as a trial account and moving it to a paid one. I was prompted in my current session to perform a password reset to resolve the lock.

Resetting the account meant changing the password and....now I'm able to register. Huzzah

A more useful response in the original 401 unauthorized message returned to the client would have been helpful if it was to do with an account lock out, and nor does it explain why I couldn't enrol with the original credentials which were part of my account when I started the trial...but never mind. It's not worth sacrificing a goat over to find out.

Thanks nameless IT Admin gods.

Hi bbrother,
This is something we're aware of and is logged with development to be fixed.

Regarding Hangman's video - the only reason the length affects the Stroke Width is that Hangman has 'Scale with object' enabled in the stroke panel, so when the object is resized, the stroke is scaled relative to that to try to ensure the scale of that stroke is maintained with the resized object.

I believe the above issue is covered by the bug report hangman has mentioned this should be fixed in a future update.

Hi @Nephilim983,
This issue sounds very similar to AF-1761 where grouped objects use the Base box rather than the Regular bounds, though this is logged in reference to lines rather than shapes or curves...

Welcome to the Serif Affinity forums.
You would see that if your colleague saved the file using 2.4 and you only have 2.3, or in any other case where they have 2.x and you have 2.y, where x > y.

I've never used Affinity on the second monitor but I did have to reconfigure their priority recently. And you're right; that was exactly the thing. Monitor 2 was not switched on. Thank you for that so simple insight.
... Ken 

The issue exists on iPad as well but I can fix the problem by changing the node alignment setting as shown. The one shape that doesn’t show the issue does not have the internal sharp point of inflection.

It can also be fixed by reducing the number of close together unnecessary nodes at that internal point of inflection. 


RPReplay_Final1709333722.mp4 RPReplay_Final1709334231.mp4

Affinity Publisher relies on Hunspell for spelling and hyphenation of languages that it doesn’t support directly. I don’t think there’s a Hunspell word-splitting dictionary for the Korean language.

Thanks Anto,

I'll get this bumped - its not a new issue, but occurs when both are floating in the same area - the Tools Panel should really have 'Keep on Top' enabled but it doesn't, so when focus changes to the document window it appears on top.
 

Hi @felo and welcome to the forums,
Is the document that has been provided to you an RGB or CMYK document and is the document you're then working on RGB or CMYK? For colour consistency between the two, you would need to ensure that both documents use the same colour space and the same colour profile...

Using the Layers Panel, drag the image layer onto the name of the text/vector layer to clip the image to the text/vector.
I would recommend watching some of the tutorial videos to get more information about using the applications: https://affinity.serif.com/en-gb/learn/

This is currently by design
Thanks
C

I will log an improvement for this however if I'm being honest I feel as though this behaviour is unlikely to change as its consistent with the behaviour of locking objects throughout the app. Its also very difficult to accidentally delete a guide due to you needing to be within the guide manager.

I will log an improvement for this however if I'm being honest I feel as though this behaviour is unlikely to change as its consistent with the behaviour of locking objects throughout the app. Its also very difficult to accidentally delete a guide due to you needing to be within the guide manager.

Hi, this has been reported before but it's been determined that it's a bug in macOS and not Affinity. If it's the same issue, logging into macOS with a different account will work but not with your normal account, so it's some sort of caching issue. You have to clear your settings and restart macOS to resolve it. More information is available in this thread. Good luck!
 

And how did you get to this page? – I see stuff like '#comment' etc. only if I use the share button or the search option or a link from another post or a notification email.
If you delete the yellow marked part in your link then it works:

It will sometimes be the latest if one doesn't use the share button.

Anto please read what I am saying carefully. You created the original thread but the link you are posting isn't to the thread its to a specific reply to that thread which is now hidden. You can see this is true because the URL ends in #comment-1176229 try posting the link again without this #comment-1176229 at the end and see what happens.