Jump to content
You must now use your email address to sign in [click for more info] ×

Pinned objects, columns & Text Wrap bugs


loukash

Recommended Posts

  1. It is impossible to apply Text Wrap on inline pinned objects. While that may be "by design", it leads to unexpected results if the object spans over multiple columns.
    In any case it is confusing that Text Wrap panel appears as "applicable" to an object even though it cannot affect it at all:
    pinned_inline_text_wrap.png.9a4437acd8c5970e83ded3f6065a0b26.png

     
  2. If an inline pinned object is at the beginning of a line and wider than the column, it results in this ugly text mash:
    pinned_inline_with_text.png.4f072b5920df2a48159abee87090b54d.png

     
  3. Floating pinned object with Text Wrap behaves even more erratically as it floats where the line would be if Text Wrap were not active:pinned_floating_text_wrap.png.44916aaef52eb7ad33d395cf4c33c2c6.png

     
  4. Editing Text Wrap values of a floating object doesn't refresh the layout until another value has been – at least temporarily – edited elsewhere:
    pinned_floating_text_wrap_edited.png.c8368d65884dd4f15daa61ddf8beb0cf.png

There may be more…

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

  • 2 weeks later...
  • Staff

Hi @loukash

Sorry for the delayed reply. 

On 2/5/2021 at 6:58 PM, loukash said:

It is impossible to apply Text Wrap on inline pinned objects. While that may be "by design", it leads to unexpected results if the object spans over multiple columns.
In any case it is confusing that Text Wrap panel appears as "applicable" to an object even though it cannot affect it at all:
pinned_inline_text_wrap.png.9a4437acd8c5970e83ded3f6065a0b26.png

Issue logged. 

On 2/5/2021 at 6:58 PM, loukash said:

If an inline pinned object is at the beginning of a line and wider than the column, it results in this ugly text mash:
pinned_inline_with_text.png.4f072b5920df2a48159abee87090b54d.png

I can't seem to replicate this here. Have you got a sample doc? 

On 2/5/2021 at 6:58 PM, loukash said:

Floating pinned object with Text Wrap behaves even more erratically as it floats where the line would be if Text Wrap were not active:pinned_floating_text_wrap.png.44916aaef52eb7ad33d395cf4c33c2c6.png

Not really sure what you mean by this. 

 

On 2/5/2021 at 6:58 PM, loukash said:

Editing Text Wrap values of a floating object doesn't refresh the layout until another value has been – at least temporarily – edited elsewhere:
pinned_floating_text_wrap_edited.png.c8368d65884dd4f15daa61ddf8beb0cf.png

Issue already been fixed in the latest beta. 

Link to comment
Share on other sites

42 minutes ago, Gabe said:

I can't seem to replicate this here. Have you got a sample doc?

42 minutes ago, Gabe said:

Not really sure what you mean by this. 

I'll set up a few examples and post back.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

  • 2 weeks later...
On 2/5/2021 at 7:58 PM, loukash said:

If an inline pinned object is at the beginning of a line and wider than the column, it results in this ugly text mash:

On 2/18/2021 at 4:32 PM, Gabe said:

I can't seem to replicate this here. Have you got a sample doc?

video:

 
On 2/5/2021 at 7:58 PM, loukash said:

Floating pinned object with Text Wrap behaves even more erratically as it floats where the line would be if Text Wrap were not active:

On 2/18/2021 at 4:32 PM, Gabe said:

Not really sure what you mean by this. 

video:

 ^ 1st part is behavior without text wrap.
With text wrap, the anchor/pin itself is being knocked out by the wrap.

 

Expected behavior would be like in InDesign, where the actual paragraph with the anchor/pin is being ignored by text wrap:
id_pinned_object_float_wrap.png.b646458ecddb6960287d1b2a864eea52.png

 

 

On 2/5/2021 at 7:58 PM, loukash said:

Editing Text Wrap values of a floating object doesn't refresh the layout until another value has been – at least temporarily – edited elsewhere

 
On 2/18/2021 at 4:32 PM, Gabe said:

Issue already been fixed in the latest beta. 

Can confirm in v1.9.1, thanks.

Edited by loukash
compacted *.mov to to *.mp4

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

On 3/3/2021 at 11:24 AM, Gabe said:

Still nothing on your mashed letters at the end of that frame. Again, no file attached so can't really tell. My guess is that you have some conflicting text styles.

Alright, I found it: "Use auto-hypenation" is on for the whole text frame. That's what makes the difference. If it's off, it will correctly push the beginning of the word to the next line as in your video.
Still, that looks like a bug to me, not a feature… ;)

On 3/3/2021 at 11:24 AM, Gabe said:

I'm still not sure what you're trying to demonstrate with the second video though. 

Essentially I was trying to work around my issue #1 where "it is impossible to apply Text Wrap on inline pinned objects".
But I couldn't get the result I needed if I pinned the object floating at the beginning of the "Praesent …" paragraph either. Hence I tried to pin it to an empty paragraph inbetween, and it got even weirder.

The main difference in behavior:

  • If the pinned object has text wrap applied, InDesign ignores text wrap for the line of the paragraph that contains the anchor, and for all lines above. Text wrap only affects lines below the anchor.
  • Publisher pushes away the pin mark itself if the pinned object has text wrap applied. While that might be "mathematically correct", it is virtually impossible to get consistent results for the pinned object placement with the pinning setting I've been using.

In my video #2, look for example at 0:27 where I'm selecting "Vertical align: Inside bottom, Of: Line, Offset: 0 pt": the object is being placed 2 lines above the pin. That's where the pin would be if I'd set text wrap to none, but at the same time it's being pushed elsewhere. That's what I mean by "erratic".
In other words, Publisher tries to do it all mathematically correct but as a "real world experience" it doesn't add up

Here's how ID CS5.5 handles similar situations. The pin/anchor postition always remains as specified, relative to the pinned object, even though the whole text line may be hidden by the object. While that's not what I'd always want either (hence my usage of blank paragraphs), at least the behavior is logically consistent and comprehensible:

 

 Ideally, APu should have an option in the Pinning panel like "☑︎ Text wrap ignores line containing pin mark".
That would make situations like pinning an object to a blank paragraph totally predictable and consistent. Either that, or implemeting "apply Text Wrap on inline pinned objects" would likely give the same result. Edited by loukash
compacted *.mov to to *.mp4

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

13 minutes ago, loukash said:

Ideally, APu should have an option in the Pinning panel like "☑︎ Text wrap ignores line containing pin mark".
That would make situations like pinning an object to a blank paragraph totally predictable and consistent. Either that, or implemeting "apply Text Wrap on inline pinned objects" would likely give the same result.

Thinking of it some more, the best solution would be if the pin mark alone would optionally ignore text wrap altogether, pushing all text before the pin mark above the object, and all text after the pin mark below the object, leaving just the pin mark alone hidden behind the floating object. If possible. But I guess apparently it's not that easy, hence Adobe likely opted for the compromise by ignoring text wrap for all text above the anchor.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

@Gabe, I wonder whether "by design" at all…

1. an object pinned "Inline" is expected to wrap text across more than 1 column within a text frame?

103313789_pinnedinline1.jpg.c35695ed78c4ffa6385aede4858d79dd.jpg

225185657_pinnedinline2.jpg.e94bd037a984fb8ae746636cecd19a9b.jpg


2. an object pinned as "Float" and set to "Inside" is expected to cause text wrapping (…like pinning "Inline" does automatically according to its "border" settings)?
Or whether a Float object would require by default an additional text wrap setting if "Float" is set to any of the 3 "Inside" options?
In case of the latter:
• Why doesn't it stick to its pin-position?
• What is an use case of pin float inside but without text wrap?

1457401666_pinnedfloat1.thumb.jpg.e94b57aac53d7ff815d3471c24a6e191.jpg

405559815_pinnedfloat2.thumb.jpg.dfc609d6a9ecb782ca0450a9a4f6b490.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

2 hours ago, thomaso said:

What is an use case of pin float inside but without text wrap?

Actually, I don't think this is relevant here: you and I may not necessarily see any imminent use for this scenario right now by using simple rectangles as an example. But keep in mind that a pinned object can be virtually anything, and that you can apply blend modes and effects to it at your discretion, creatively affecting anything underneath.
(And as long as you'd export as PDF/X-4 and not X-3, you'd even might get pretty good print results without overly excessive rasterization… :P)

Other than that…

2 hours ago, thomaso said:

• Why doesn't it stick to its pin-position?

… yep, that's exactly my point. Thanks for additional explanation and example screenshots.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

1 hour ago, loukash said:

Actually, I don't think this is relevant here: you and I may not necessarily see any imminent use

That's why I specifically asked Gabe ;-), I am interested in the developers view.
According to your arguments also "Inline" pinned objects wouldn't got by default their built-in text-wrap feature (one may want to use blend modes...).

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

27 minutes ago, thomaso said:

According to your arguments also "Inline" pinned objects wouldn't got by default their built-in text-wrap feature (one may want to use blend modes...).

Huh?
Inline objects are being "wrapped" by the sheer nature of the concept.
But in Publisher it only affects the current column, not the other columns, if any. If the objects exceeds the current column bounds, no other text is being wrapped. But it should.

Unlike InDesign, again:
An inline object can have wrapping applied, and it will also push out any other text if the object exceeds the current column bounds.
That said, ID's inline object behavior is also somewhat weird. For instance, the text wrap rectangle becomes a separate object and doesn't scale with the inline object anymore. So I'm not sure where the feature stops and the bug begins, haha…

But my point in this case actually being that in APu you can apply text wrap to an inline object but it doesn't do anything.
So:

  • either text wrap should do "something"
  • or text wrap should be grayed out for inline objects

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

5 minutes ago, loukash said:

Inline objects are being "wrapped" by the sheer nature of the concept.

Sure? Your or any user's idea doesn't have to be congruent to Serif's. That's why it's useless if you try to answer my question, instead of a Serif team member.
(if "inline" has wrapping 'by nature': what's the nature of "inside"?)

For me, your comparisons with InDesign make the discussion unnecessarily complicated and confusing. ID is not the mother of APub, Serif works completely independently of Adobe. Saying "I'm used to it like this from Adobe..." sounds strange, considering that APub obviously is not interested in copying the UI/UX of InDesign. From this point of view, ID doesn't matter at all. What counts is the concept of Affinity (which might meet ID's but doesn't have to). That's what I was/am asking for.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

3 minutes ago, thomaso said:

Sure?

Sure. That's what "inline object" means. It's becoming part of the text and behaves as a character.

2 minutes ago, thomaso said:

your comparisons with InDesign make the discussion unnecessarily complicated and confusing.

Are you the type of guy who is going to reinvent the wheel "just because"? ;)

6 minutes ago, thomaso said:

Saying "I'm used to it like this from Adobe..." sounds strange, considering that APub obviously is not interested in copying the UI/UX of InDesign. From this point of view, ID doesn't matter at all.

And I hear you.
I'm one of the guys who's been posting quite a lot of "you've got to rid of your Adobe mindset to fully understand Affinity" all over the forums in the past few weeks.

That doesn't mean I won't take the freedom to point out similar existing concepts and both their strengths and their flaws.
In other words, I will type the A**** or the I*D***** words whenever I deem it appropriate. No taboos! :P

13 minutes ago, thomaso said:

What counts is the concept of Affinity (which might meet ID's but doesn't have to). That's what I was/am asking for.

Fair enough.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

2 hours ago, loukash said:

Are you the type of guy who is going to reinvent the wheel "just because"? ;)

No. But I experienced Affinity try such reinventions, sometimes for no or hardly lucid reason.
There's no taboo for ID comparisons but they can fit or can be a helpful idea – or maybe useless & confusing. For instance in case of unknown concepts or especially if "ID's inline object behavior is also somewhat weird".

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

16 minutes ago, thomaso said:

There's no taboo for ID comparisons but they can fit or can be a helpful idea – or maybe useless & confusing.

One important factor to keep in mind here:
Serif wants Affinity to be at least partially compatible with *.idml (and *.ai and *.psd).
This is a key Affinity feature for the majority of pro designers like my puny self, having worked with the Schmadobe suite for the past 18 years. Serif wants our money so they better keep us happy by making the transition as smooth as only possible. (Luckily, IDML is a human readable XML format so there's likely not much reverse engineering necessary.)

My comparisons here are not about workflows; hey, InDesign's modal window for pinned objects (and other functions) always sucked!
They are about existing functions.

So… if APu wants to be able to import IDML while keeping the layout usable out of the box, it must also understand how many ID's less common functions work. And if such functions appear in a layout, it should interpret them correctly. That's why a comparison to ID's anchored objects is pretty useful in this case, as far as I'm concerned. After all, I may have hundreds of idml layouts to import, eventually.

But we're getting off topic. Let's focus on the actual issue at hand in this thread.

MacBookAir 15": MacOS Ventura > Affinity v1, v2, v2 beta // MacBookPro 15" mid-2012: MacOS El Capitan > Affinity v1 / MacOS Catalina > Affinity v1, v2, v2 beta // iPad 8th: iPadOS 16 > Affinity v2

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.