GarryP

Thanks carl123, I'll give that a try this afternoon.

You're welcome, and I hope it works (I don't have access to a laser cutter myself so I can't check). I'm sure people will be interested to read more about how you get on with this.

I'm trying to upload an image to a new forum post and am getting the following error message: "There was a problem processing the uploaded file. -200" The file is a JPG and is just under 3MB in size. Is there anything I can do?

That answers the first question but not the second (effect shown in the video after 0:17), which I have also seen quite often lately. The bounding box - as can be seen on the right of the picture frame in the video - seems to 'slip' away from where it should be. I've seen this happen on picture frames, text frames and shapes.

Windows 10 Home 1809, Publisher 1.7.0.257. I have a simple 8-page A4 facing-spread document. I have 4 small images - total size on disk 136kB - to add as page backgrounds (the same image on the first and last page, different images across the other spreads). When I add the images as Image layers to the document and export as PDF I get a PDF that is 98.8kB in size. That looks fine and dandy. However, when I add the images as Picture Frame layers, and export with exactly the same options, I get a PDF that is 2.1MB in size. That's way bigger. Does anyone know what's happening and why? Am I doing something wrong? I can attach the documents and/or PDFs if necessary. P.S. Both of the afpub files are 1.85MB in size, which also seems a little large, considering, but I guess that's a different issue.

The "Share Your Work" section is, as I see it, more like a 'clubhouse notice board' than any kind of curated art gallery. Like Pattou said, it's more of a place for people to bounce ideas around than a formal showcase of finished works. If you do want to see a curated selection of great images then Affinity Spotlight https://affinityspotlight.com/ is probably the best place to go. Having said that though, dipping in to random threads in "Share Your Work" can give some very nice surprises.

On a related note, should the "Align Stroke to..." buttons also be disabled for non-closed curves? At the moment they don't change anything visible - and that's what I would expect - but they can still be pressed. For example, you can: * create a rectangle; * set "Align Stroke to Outside"; * convert the rectangle to curves; * break the curve. The visible alignment goes back to Centre, as I would expect, but the "...Outside" button is still pressed and I can set different alignments that have no meaning for a non-closed curve. Re-closing the curve re-asserts the selected alignment, which is nice, but should I be able to set an alignment without it making a visible difference? Maybe, instead of disabling the buttons, a little 'info tool-tip icon' could be shown next to the alignment buttons - only when a non-closed curve or a curve with arrowheads is selected - to tell the user that those effects are not visible on non-closed curves (or curves that have arrowheads).

Old Bruce, I agree that it looks like a bug (see also below). Your 'fix' sounds interesting. I'll have to try it. Thanks. carl123, going round setting all of the corners in the document to not Absolute Sizes, then changing the DPI, then going back and changing the corners back again - assuming that I don't miss something along the way - sounds like it would be a bit of a pain. I want to set an absolute value and keep it as I set it. Changing the "Scale with Object" on the decoration works so that's a fix, thanks. (There's still an inconsistency, see below, but it's a temporary fix none-the-less.) There's a chance that I haven't explained myself well enough so please consider the following - more simplistic - set-up: * Create a new document: UOM = Points, Page Width = 144pt, Page Height = 144pt, DPI = 144, Margins = 36pt; * Create a rounded rectangle that has dimensions equal to the extents of the margins, e.g. X & Y = 36pt, W & H = 72pt; * Set the stroke width of the rectangle to 4pt, and set to Scale with Object (which doesn't seem to make a difference, which I think is correct since the rectangle is not being resized); * Set the corners to be Absolute Sizes; * Set the corners to NOT be Single Radius (so the change is easier to see); * Set the top-left and bottom-right corners to be 9pt (leaving top-right and bottom-left at 18pt); * Set the grid to be visible with a Spacing of 72 with 18 Divisions. This gives you the document attached as dpi-change-before.afpub (first image) which is all well and good. No problems there. However, now change the DPI of the document to 72, attached as dpi-change-after.afpub (second image). * The document still has the dimensions of 144pt - that's good and as expected. * The margins have all been reduced to 18pt - why the change? I wanted 36pt so isn't that what I should still have, even if this means - in this particular case - that the area within the margins should be effectively of zero size? * The X,Y,W and H of the rectangle are all as before - that's good and as expected. * The width of the stoke is still 4pt - that's also good and as expected. * The sizes of the corners of the rectangle have changed to be 18pt and 36pt - why the change? I set them to absolute values. The size of the rectangle - set by absolute values - has not changed so why do the sizes of the corners - also set by absolute values - change? Or, to put this the other way round, if the corner sizes change, why doesn't the size of the rectangle also change? To be clear, I don't think the the corner sizes should change. * The grid has also changed to a Spacing of 144 with 18 Divisions. Why the change? I set it to 72 with 18. So, I have to ask the question again, why do some things change and others do not? Some things seem to change to 'accommodate' the difference in DPI but others don't. There are inconsistencies there that I don't understand. dpi-change-before.afpub dpi-change-after.afpub

Windows 10 Home 1809, Publisher 1.7.0.257. When I change the document DPI, some things change but others don't. Consider the attached document. The first image shows the document at 300DPI. The second image shows the same document at 144DPI. The visible size of the corners of the rectangle increase - the absolute sizes in the context bar have also increased - and so has the visible width of the paragraph decoration - but the sizes in the Paragraph panel are as before. However, the thickness of the rectangle stroke is the same, as is the size of the text and also the height of the text decoration. Why do some things change and some others don't? Is this expected behaviour? DPI-change.afpub

Depending on how your icons are drawn, you could convert them to font glyphs and use the resultant font for the bullet points. See the attached GIF which shows both bullet points and in-line graphics being used. (The rating labels and stars were created in Designer very quickly.) It's a bit of a tricky process to get this right and there are quite a few steps but I've used it myself a few times.

My two-penneth, to put things into some kind of perspective: According to Serif press information: "Serif has around 70 employees." According to a recent 10-K Annual Report from Adobe: "As of November 30, 2018, we employed 21,357 people." Need I say more?

Yeah, that's weird. My tests on your document show the same issues that you get. I can't see any problems with the shapes other than changing the alignment doesn't do anything on the ones you specified. I drew another trapezoid in the same document and the issue persists there too. I drew a trapezoid in a new document - with the original document open - but that one worked as normal. I went back to the original document and the issue still persists in your shapes. I selected my trapezoid, reverted it to default, and the stroke now works as would be expected on that particular shape but still doesn't on any of the others that had the issue. A copy of one of your problem shapes also has the same issue. Changing the stroke to "No Line Style" and then back to "Solid Line Style" doesn't make any difference to the fact that the alignment still doesn't work. So, after all that, I now have multiple shapes of the same type in the same document which work differently. I think that's one for the big brains at Affinity Towers to work out.

Windows 10 Home 1809, Publisher 1.7.0.257. I've just tried adding a few custom shapes - Trapezoid, Square Star, Donut - to a new document and the "Align Stroke To..." buttons in the Stroke panel work as expected. The same goes for Rectangles, Rounded Rectangles and Ellipses, they all seem to be working fine for me. However, I have experienced some rare occasions where the Stroke, Swatches and Colour panels have had no effect on Text Frame contents. When you convert a shape to a text frame, the Stroke, Swatches and Colour panels move their focus to the text rather than the frame - with those functions instead being taken up by the relevant controls in the Text Frame panel - but every now and again they stop having any effect at all. Could this be a related symptom? In the original post, maxen didn't say what kind of object they were having problems with. I have not been able to come up with a reproducible work-flow to pass on to the developers. (My work-around has been to delete the object and try again, which isn't ideal.) Note: Another way of looking at this is that if maxen was working on a text frame with no text in it then it would look like the Stroke panel had no effect on the frame stroke because the Stroke panel for a text frame relates to the text in the frame and not the frame itself. No text so no visible effect.

I've always found this https://inspirationhut.net/ to be a good source of inspiration when I'm looking for something to try.

You're welcome Danny. My guess about the "MEN" thing was that the publications might have been designed to be displayed, overlapped, on a shelf with the left-hand side showing so it was easy for people browsing to see which sex each publication was for. But that was a complete guess. Sometimes these things are simply hang-overs from something that isn't relevant anymore, but it's better to ask.

Nice. I have a few, very minor, issues that might be worth thinking about: * Are the white glows on the "Inkhore" spread really necessary? I think they spoil it a bit, but that's just a personal thing; * On the "Frank La Natra" spread, I think some of the text comes too close to the shapes, especially the bottom paragraph on page 52; * On the same spread, the shape at the bottom-right has the start of a curve at its bottom-left, which is a tiny bit irksome (to me at least); * The logotype next to the page number on the left-hand pages is further away from the page number than the same logotype is from the page number on the right-hand pages; * On the cover, does it really need to say "MEN" on the left and "For Men" on the right of the logotype? (Maybe it does and I just don't know why.) Anyway, like I said they're very minor issues, mere niggles if you will.

You can: * click on the first rectangle in the group; * then shift-click on the last rectangle (remember to scroll down to the bottom first); * then use menu "Layer -> Geometry -> Add" to put all of the shapes into one layer. Does this help?

Check to see if you have set the Opacity of any layer - or the Artboard itself - to anything other than 100%. I found out a while ago that an Opacity of less than 100% can - under certain circumstances, at least - make Designer export as a raster. My original thread can be found here: https://forum.affinity.serif.com/index.php?/topic/63393-is-it-expected-designer-behaviour-to-get-a-raster-output-when-exporting-to-an-svg-with-an-opacity-of-less-than-100/

Either way - goof or bug - it certainly looks wrong to me. Moderators: Can you shed any light on this?

You would need someone from Serif to answer that. I'm sure they have very good reasons.

That's certainly what it looks like to me, see attached GIF. If I've got this all wrong then someone please tell me.

It was mentioned in another thread somewhere that the Text Frame button in Designer - the one on the context bar - is there by mistake and will be removed in future versions.

Oh dear, well that explains it. As long as it's been reported then I guess that's all we can do. Hopefully it will be fixed soon.

Maybe we will start to see how things will be when all three applications are nearer their 1.7 commercial release. (Or maybe Serif are waiting for a 'big reveal' upon release.) I'm hoping that all three Affinity applications will share a set of 'application persona' buttons that will allow us to seamlessly switch between the those that are installed. That would offer a really neat way of working. I think it would be a shame if only Publisher had the ability to switch. I guess it's a case of "watch this space..."

That seems to work nicely for rows - like you say, it's not perfect but it does the job as well as can be expected - but I can't get it working nicely for columns. Sometimes the column just 'collapses', see the attached GIF where column B 'collapses' but column D doesn't.