im_a_roc Posted July 3, 2021 Posted July 3, 2021 Hello! I'm new to the Affinity suite and still learning the basics. I'm putting some final touches on some sheet music in Publisher but I'm having a persistent issue that vector curves I create are rasterized when exported, causing the curves and the area around them to appear pixelated. Most of the curves in the file were produced in a music notation program and they all export correctly as vector graphics. But the arrows in the screenshots below I created, and they always appear pixelated when exported to pdf. I've tried to create the arrows several different ways to resolve the issue, including creating them in Designer and copy/pasting the curves, creating them in Designer and exporting as various different file types and placing them as images in the Publisher file, and creating the curves directly in the Designer Persona in Publisher. All of these approaches look good in Publisher but export with the same issue. I've read about issues with layers with transparency causing issues like this in pdfs, but I don't think I have any transparency, just vector curves and text. The finished pdf will be used both as a print document on 9x11 inch paper, and read digitally on tablets as a .pdf, so it needs to look good both digitally and in print. Currently the pixillation is visible in both. I've copied and pasted some instances of this problem into a separate .afpub file so you can see the problem, as well as a .pdf exported from that file. I can't share the original file I'm working with because the music is under copyright. I'm on a 2019 Macbook Pro running MacOS 11.4, using Publisher 1.9.3. Happy to provide more info as needed. Thanks for your help! publisher arrows sample.pdf publisher arrows sample.afpub Quote
Old Bruce Posted July 3, 2021 Posted July 3, 2021 Sorry to say that I think you'll have to expand the strokes that are the arrows. Don't know why, vector is vector. Quote Mac Pro (Late 2013) Mac OS 12.7.6 Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0 | Beta versions as they appear. I have never mastered color management, period, so I cannot help with that.
R C-R Posted July 3, 2021 Posted July 3, 2021 I am reasonably sure the problem is Affinity does not know how to convert arrow start or end shapes added to curves into vector paths on export (like where you have a 150% scaled end arrow shape on your arrow lines), so it rasterizes the whole shape. I know of 2 simple workarounds for this: Replace the arrows with 'old school' ones made with 7 nodes (which I think is what Affinity should do on export), like this: Or use the Arrow Shape Tool to make arrows with only one end set to an arrow shape. arrows for export.afpub is a tiny little file with examples of all three types of arrows in it. A quick check in the File > Export window set to PDF shows "Some areas will be rasterized" unless the single line curve is either deleted or hidden. Do that & it says "Nothing will be rasterized." Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
thomaso Posted July 4, 2021 Posted July 4, 2021 7 hours ago, Lagarto said: Just remove the fill attribute from the arrow objects and they will stay as vectors: This could perhaps be reported as a bug, I do not think that fill attribute itself has any functionality in these kinds of objects so it is strange that it causes this behavior. Oddly, the vector object causes a transparency group on PDF export if it has an arrow tip + fill … … whereas it exports fine with "Rasterize: Nothing": im_a_roc 1 Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
thomaso Posted July 4, 2021 Posted July 4, 2021 4 hours ago, Lagarto said: in a sense, a feature. One would e.g. lose a gradient fill when an arrowed stroke would be forced to stay as a vector, but not a solid fill. In what situation is this a feature? Why does a vector object with a gradient fill needs to get rasterised whereas a solid fill does not – if an arrow (vector, too?) is applied? For what advantage (feature) should the objects below get rasterized by default – though they can be exported as vector, and actually do get exported as vector with preset-for-print * / different to my trial above with the object in OP's .afpub. * Edit: in fact they don't, unless rasterize: nothing is set. v193 arrow&gradientfill.pdf This also makes me wonder: • How about the stroke alignment limitation to center (different from the UI), respectively in closed shapes (with arrows)? • How about the clipped stroke in the attached PDF on export as selection of both selected objects? What causes the offset here (the blueish isn't clipped / is exported with a right margin) ? Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
im_a_roc Posted July 4, 2021 Author Posted July 4, 2021 11 hours ago, Lagarto said: Just remove the fill attribute from the arrow objects and they will stay as vectors: This could perhaps be reported as a bug, I do not think that fill attribute itself has any functionality in these kinds of objects so it is strange that it causes this behavior. publisher arrows sample.afpub publisher arrows sample.pdf 490.65 kB · 0 downloads Thanks so much for the simple fix, I can honestly say I would never have thought to try that... Good to know that quirk for future projects. The score looks great now, thanks to everyone for the help! lacerto 1 Quote
thomaso Posted July 4, 2021 Posted July 4, 2021 42 minutes ago, Lagarto said: But in this sense: it does not appear to be a bug, but a "feature". Well, I still need to learn the various versions of classifications. While "by design" to me (German) feels like "on purpose" + "intentionally" + "according to the concept" + "as commissioned to the programmers" it actually appears to mean in English "just as it is", regardless of being on purpose or a missing, not yet implemented feature or even a behavior which isn't expected nor wanted by users. So your, Lagarto's use of "feature" sounds to me as synonym for "by design" – whereas in my understanding a feature always needs an advantage or certain use case to make sense to be a "feature" instead of being "by design" or a bug. Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
Old Bruce Posted July 4, 2021 Posted July 4, 2021 I used a piece of typesetting equipment which used the shift key as a toggle. Press it and you typed upper case until you pressed it again. Think of it as having only a CAPS LOCK key. This was because the equipment could only read one key at a time, so it was by design, but also a feature which allowed each alphanumeric key function as 2 keys. A better feature was changing the entire system of entering text. Your German definition and your English definition co-exist in my brain. Design can be good or bad, like quality. In Vancouver I would see many stores' signage which stated they sold Quality Products, there was only one place which said they sold Good Quality Products, and they did too. Quote Mac Pro (Late 2013) Mac OS 12.7.6 Affinity Designer 2.6.0 | Affinity Photo 2.6.0 | Affinity Publisher 2.6.0 | Beta versions as they appear. I have never mastered color management, period, so I cannot help with that.
R C-R Posted July 4, 2021 Posted July 4, 2021 1 hour ago, Lagarto said: I mean that if it gets rasterized in a closed shape, then I do not wonder that it gets rasterized in a non-closed shape. It does not need to be anything complex, like the top shape. If I understand this correctly, it is the combination of a filled curve and one that has a start and/or an end shape (arrow, triangle, circle, whatever) that causes the rasterization on export. This makes sense, at least to the extent that I cannot see how a curve with a start or end shape can be converted to a simple vector unless its start & end nodes are coincident (whether merged into a closed curve or not), so any fill applied to it cannot fill just the path of the curve. I don't think I have explained this very well but I hope it makes sense. EDIT: maybe the attached rasterized or not.afdesign file will make what I mean slightly clearer. Old Bruce 1 Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
thomaso Posted July 4, 2021 Posted July 4, 2021 12 minutes ago, Lagarto said: ) https://simplicable.com/new/bug-vs-feature "A feature is something that hasn't been requested." … that's were marketing meets reason. "Professionals only …" 9 minutes ago, Old Bruce said: A better feature was changing the entire system of entering text. (...) Good quality Whereas both methods can be useful. That's why we can choose in macOS' system prefs between both ways. When adjectives are involved I get lost – they mostly get used to make the audience believe (~ understand) what they ideally would prefer. The "tech specs" are full of those undefined words feelings … Compared with the forum concerns (bugs'n'feature requests) I wonder whether involved people at Serif do have a common understanding at all – or whether marketing/text lives in a world separate from the moderators which use language also different than developers. That might explain why there still exists bugs since years which get nudged occasionally by moderators, nudged into an unkown univers? Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
thomaso Posted July 4, 2021 Posted July 4, 2021 13 minutes ago, R C-R said: I don't think I have explained this very well but I hope it makes sense. Currently my understanding gets confused by a differing experience: This can be exported as pure vector – just not by default but on certain request only. must - not really - be rasterized.pdf That means all required info to describe the shape of the fill mathematically does exist / is no issue. Wouldn't such a fill shape otherwise be unable to get displayed in the layout, or at least get displayed in any chaotic way? Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
R C-R Posted July 4, 2021 Posted July 4, 2021 4 minutes ago, thomaso said: That means all required info to describe the shape of the fill mathematically does exist / is no issue. Your pdf consists of three different groups, each of which is made up of three separate shapes. My point is there is no way to do this using only three shapes, each with all 3 pieces in one vector object. Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
R C-R Posted July 4, 2021 Posted July 4, 2021 23 minutes ago, thomaso said: "A feature is something that hasn't been requested." Nonsense! A feature is just a distinctive attribute or aspect of something. It may well have been specified in the initial planing stages of the design. A feature may be buggy, not buggy, or simply missing (unimplemented). It may be perfectly implemented but simply not work the way one might expect; thus, "by design" & not buggy. Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
thomaso Posted July 4, 2021 Posted July 4, 2021 27 minutes ago, R C-R said: My point is there is no way to do this using only three shapes, each with all 3 pieces in one vector object. Ok, I understand. But that isn't actually necessary. Several objects (not only vector objects) result in a different number of objects after PDF export. Back to the topic: it IS possible to export the arrows with fill as vector. My question is rather why the app requires a literally request to do so. Usually if unsupported properties cause rasterization but get switched off on export parts of the layout don't get exported / are missing in the PDF (e.g. effects, blend modes etc). But not so with the OP's arrows … or your sample .afdesign. Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
thomaso Posted July 4, 2021 Posted July 4, 2021 3 minutes ago, R C-R said: 44 minutes ago, thomaso said: "A feature is something that hasn't been requested." Nonsense! Note, this was a quote in response to a linked article in a previous post. It seems to be partially ironical but also explains this thought: https://simplicable.com/new/bug-vs-feature Quote • MacBookPro Retina 15" | macOS 10.14.6 | Eizo 27" | Affinity V1 • iPad 10.Gen. | iOS 18.5. | Affinity V2.6
iconoclast Posted July 4, 2021 Posted July 4, 2021 Sorry, I haven't read the whole thread, so I don't know if anyone already had a solution. But as I tested it, it seemed to work as I created an arrow by just drawing a simple stroke with the "Pen" tool, adding an arrowhead to it with the Start/End-feature in the "Stroke" panel, then changing to the Designer Persona and "Expand Stroke" ("Layers" menu) and add the two objects the arrow consists of now to each other ("Geometry"). Then I went back to the Publisher Persona and exported the document as a PDF. To compare the result I also created arrows without the steps in the Designer Persona. The difference is obvious. The important point seems to be the "Expand Stroke" step. You can also use the doublearrow from the tool panel. It will also create a clean edged arrow. Seems that it is important that the vector lies on the outline of the arrow, not in the center. If in center, the arrow will consist mainly of pixels that are aligned to the vector, I think. Quote
R C-R Posted July 4, 2021 Posted July 4, 2021 49 minutes ago, thomaso said: Back to the topic: it IS possible to export the arrows with fill as vector. My question is rather why the app requires a literally request to do so. I'm confused. How do you make that request during export to PDF & avoid creating groups? For example, with my "rasterized or not.afdesign" file, I choose "must be rasterized" for area & in "More" set it to rasterize nothing. What I get in the Export dialog is "Some areas will be approximated" but the export ends up just like your 'not really' version with 3 groups of 3 objects. I get the same thing with the OP's file -- every arrow shape is a group of two curve objects. IOW, yes, it is all vectors but none of the arrows consist of just one vector shape. Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
R C-R Posted July 4, 2021 Posted July 4, 2021 37 minutes ago, Lagarto said: I am not sure if I got your point... As simply as I can put it, there is no way to do this using just one vector shape if both an arrow shape and a separate end-to-end fill are what is desired on export to PDF. It doesn't matter if the fill is a gradient or not; it still ends up requiring two (or more) vector objects to make this. Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
R C-R Posted July 4, 2021 Posted July 4, 2021 When I say it doesn't matter, what I mean is it does not matter if the fill is a gradient or a solid color -- either way, the combination of a filled curve with an arrow end-shape will not export as a single vector curve object, nor do I see any way that can be done. If you can, please post an example because every example posted so far requires more than one object to create a filled curve with an arrow end-shape, regardless of the fill type. Quote All 3 1.10.8, & all 3 V2.6 Mac apps; 2020 iMac 27"; 3.8GHz i7, Radeon Pro 5700, 32GB RAM; macOS 10.15.7 All 3 V2 apps for iPad; 6th Generation iPad 32 GB; Apple Pencil; iPadOS 15.7
Recommended Posts
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.