Publisher: Export Selection to JPEG or PNG without background issue

[SeeJaneB]

This is making me nutty. I just used this feature without problems before the last update but now I'm having issues with this and have wasted way too much time messing with it in the past 24 hours.

If I select just one object or text box or a group of items, and go to export either a jpeg or png and select "selection without background" from the dropdown menu, the image that is exported has extra space to the top and left that seems to be directly related to its placement on the page. In order to get rid of it, I had to slide the group of objects all the way up to the top left corner. I'll include a screenshot of my publisher layout, and then what I get when just trying to export the two text boxes that make up the logo and also the white rectangular area and objects inside of it.

What is going on? I have been working from this file for a while and have exported pieces previously without issue. Is it an issue with the latest update?

[thomaso]

I can't replicate the issue, I get 3 selected text frames exported as expected, clipped to their dimension in PDF, JPG and PNG (+ transp) sucessfully.

Do you experience this with all your documents? If not, what if you copy/paste the affected frames to a different or new document? If it still resists, can you upload an .afpub with affected items for a test?

[SeeJaneB]

I had already tried previously copying the two text boxes into a new document and that definitely did not work, even when I just tried them individually and not together

I just tried creating a new doc and roughly re-creating the two text boxes. For some reason the "Creative Solutions" part I had originally formatted the typography to be all uppercase and also small caps, so on trial number 1 (page #1 of the test doc), I set it up that same way and got the extra spacing issue, then I went back and just typed it with CAPS lock and adjusted the sizes, without clicking on the character formatting, and it exported ok on trial #2 (page #2 of the test doc).

Going back to my original document, I tried switching the small caps off and just clicking on the all caps in the character settings and still couldn't get it to export correctly, even when removing the "Creative Solutions" from that particular page and just trying to export the SeeJaneB part. Then I realized that I had the return pressed at the end of SeeJaneB and deleted that, and was able to get just that part to work once, but still no luck with the group of both elements, even when recreating the "Creative Solutions" just using my caps lock and not any of the character toggles.

I don't know. All I know is that it worked fine once before and now I'm having issues even beyond this original doc. Here is my original and very messy design file I've done a lot of playing around in, and also the file I was using for test purposes. 

Thank you to anyone willing to look into this.

 

 

facebook cover.afpub Publisher Problem.afpub

[thomaso]

I am sorry I can't help here. The issue of a too large area when exporting this two text frames as selection without background occurs in various situations but doesn't in others, I can't see a system, rather various odd symptoms. Maybe a developer can take a look inside, there seem to be hidden aspects relevant which don't have an UI.

For instance in the facebook cover.afpub:
– The text frame 'Creative solution' seems to be affected on all pages (I tried ~5 pg) not to become clipped correctly on export as selection. Instead the export area always starts at page position 0 / 0 and ends at the bottom right corner of the selection. If the selection gets moved to the right then the exported area will increase, and vice versa. Sacling the object doesn't avoid the issue. But the export works correct for some items, for instance:
– the portrait image group from various pages
– the embedded color bar resource on pg. 5
– the text frame 'SeeJaneB' on pg. 1
– the upper text frame on pg.14 but only if I set the text stroke colour to none (left the stroke width untouched)

When I copy/paste affected frames to another document they transfer the issue (while a text frame copy/pasted from the other document doesn't).
A new frame created within this document shows the issue, too. So the issue appears to be in both the document and its objects.

In the Publisher Problem.afpub it exports the frames as selection in correctly clipped size from page 2 + 3. The bottom frame on page 1 doesn't export with correct clipped size. An this frame behaves quite strange: it gets selected if I click in an area above and left of the frame. I colored the area where a click does select the bottom frame (had to move it slightly to make the entire pink area fit on the page). So, the top frame can get selected only with a click on its letter 'B' (other positions select the bottom frame).

This selection area issue appears related to this recently reported and logged issue:

 

[lacerto]

(...)

 

[thomaso]

2 hours ago, Lagarto said:

The problem is caused by a bug in Affinity apps: if there are empty lines at the start of a text frame

Does removing the empty line avoid the export clipping issue for you? To me it has no influence, tried for page 1:

Furthermore, if I do NOT remove the empty line but remove the stroke COLOUR (quite odd but true) of both selected frames on page 14 the clipping appears to work correctly. (while it does not work if I remove the stroke colour for only 1 of the two frames.)

 

[lacerto]

(...)

[lacerto]

(...)

[thomaso]

27 minutes ago, Lagarto said:

I cannot reproduce this error on Windows version,

Aha, it gets more complicated.
@SeeJaneB, does it export clipping correctly when you removed the empty, first line of the frames? – Or with another font?, as for Lagarto in Windows:

Just now, Lagarto said:

problem with clipping is NOT related to empty line but to specific font, Martel Sans, and using all small caps OpenType feature!

Again a mac thing? – I don't have Martel installed, instead the default Lucida Grande is used:

But even with Arial + the empty line the clipping issue occurs:

... and also with Andale Mono and without the empty line:

 

[lacerto]

(...)

[thomaso]

> "Yes, as mentioned above":  

Unfortunately since a couple of days the browser's beep & macOS's popup message when a new replay gets posted while I am typing a post myself became unreliable. So I do see those posts only after submitting my post (which may take a while, depending on the content).

[lacerto]

(...)

[lacerto]

(...)

[SeeJaneB]

Wow, I can't thank you both enough for taking on my problem!

I did notice that there was an issue with a paragraph return, but was still getting inconsistent results.

Question: I can remove the paragraph return at the end of the line, I still can't figure out why it looks like there is a return on the "a" in SeeJaneB? What is that? (Update: Aha! I discovered it was at the beginning of the Creative Solutions field! But unfortunately, everything I have below still applies...)

Martel Sans is just a free Google Font, but I downloaded it from fontsquirrel.com to get the otf version. Same thing with Playfair Display.

I'm working on a Mac. What @Lagarto mentioned about the Seravek font was interesting, since I liked that font, but was puzzled as to why it didn't show up in Font Book or in the Mac programs like Pages, for example. So I tried to find one that was similar and landed on Martel Sans.

The bug that @thomaso mentioned regarding the clickable area may apply as well, since I notice in some instances, I can't select the SeeJaneB part unless I click on it in the layers panel. This happens on page 3 of the updated design file I will attach.

On Page 2, the "creative solutions" part is formatted with all caps and small caps in the character panel, which doesn't show when just selecting the text frame until you double click to edit.

On Page 3, the "creative solutions" part is just made by typing in all caps and not using the formatting buttons in the character panel.

On both pages 2 and 3, the group only clips correctly if the outline is set to no line style on the "creative solutions" part. The SeeJaneB part doesn't seem to matter. Checking no line style to remove the outline on the SeeJaneB still didn't have an effect, until I also removed the outline from the creative solutions part. Then it appeared to clip as could be seen with the dimensions changing to the 600 x 200 pixel range. I added the outline back to both fields and it went back to 1142x450px with the extra space.

So if I'm understanding everything correctly, line breaks may have had some effect, but this is boiling down to an issue with the outline stroke applied.

One last thing I checked is that I changed the font from Martel Sans to Lucinda Sans and still had the issue as long as there was an outline. This is what the screenshot shows.

So how do we get this reported?

 

facebook cover.afpub

[SeeJaneB]

@Lagarto I tried playing around with clicking on the frame, removing the stroke, and then double clicking on the frame to edit, highlighting each word and applying the stroke separately, but still found that when switching back to the selector and just selecting the frame, it still showed up as having a stroke applied overall, and of course the clipping issue still existed. (I also checked and made sure I didn't have an outline applied to the space between the words creative and solutions.)

[lacerto]

(...)

[SeeJaneB]

@Lagarto, please see my last comment about this. I have only applied the stoke to the words "creative" and "solutions" and not to the space in between. I have also removed all line breaks, and I'm still getting an issue. Here's the latest save of my file. I was working on page 2. 

facebook cover.afpub

[SeeJaneB]

@Lagarto Just read your last comment one. more. time. slowly. and tried just placing my cursor before the "creative" and then after the "solutions" and selecting no line style each time, and then magically it appears that it will clip upon export (see screenshot).

So we officially have a workaround, but this is just crazy! Am I right that this needs to be submitted as a bug, since ideally a user should be able to just select the frame and apply the stroke without having to touch every single piece of the text inside? If so, how do we proceed?

 

[lacerto]

(...)

[lacerto]

(...)

[MikeW]

@SeeJaneB, @Lagarto, @thomaso,

Thread is moved to Publisher Bugs found on MacOS section...

[thomaso]

1 hour ago, Lagarto said:

This is a pretty complex problem and there are multiple workarounds so it is difficult to describe this shortly.

I might have missed some news in the recent posts of both of you. Meanwhile to me it appears less complex and seems to need exactly these 3 conditions:

1. Artistic Text Frame
2. In first line only a line break
3. Stroke applied to all text

In the attached.afpub there is only 1 frame which causes both of the two issues. It is on pg 3 the one with the pink background.
All other frames, pg 1/2 incl., don't cause either of the issues. Neither Caps nor "normal" text frames seem to be affected.

– it doesn't get clipped correctly if exported as selection in a PNG
– it has an increased area which reacts on clicks (compare pink rectangle)

v184 export selection clipping.afpub

p.s.: if someone does notice any reason for my .afpub beeing 1.8 MB I'd appreciate to hear.
Since all my afpubs are affected with a minimum of 1.8 MB it starts to disturb me.

[thomaso]

37 minutes ago, thomaso said:

Neither Caps nor "normal" text frames seem to be affected.

On 8/14/2020 at 7:31 PM, SeeJaneB said:

I had originally formatted the typography to be all uppercase and also small caps

Sorry, I hadn't the "small Caps" in mind in my previous test and post. – I tried now with Caps + smallCaps and experience both issues get caused by small Caps + text stroke. The combination of Caps + smallCaps doesn't seem to be necessary.

Here's an update with an additional page:   v184 export selection clipping.afpub

[lacerto]

(...)

[thomaso]

22 minutes ago, Lagarto said:

The text frame does not need to contain a line break and it does not need to be an artistic text frame. The crucial thing seems to be a stroke that is applied on a non-printing character preceding or trailing the actual text.

I just tested again in my most recent document the "normal" frame text (page 1 + 2) and noticed now that page 1 still is not affected (stroke on non-printing characters), while page 2 is affected now for some objects but not for all. I am sure before none on page 2 was affected. – Does additionally the document get corrupted while working? Didn't @SeeJaneB say the issue of wrongly clipped export started to occur in the document at any later time and worked correctly before?

Maybe the developers know already, just by the currently confusing symptoms, a/the reasons or at least where to look for them in the code.

So, I give up at this point.